SQL в IT — не «язык аналитиков» и не отдельная профессия для всех. Его требуют аналитики, часть QA, почти весь backend, иногда поддержка с доступом к чтениям. Roadmap под работу поэтому разветвляется: какой уровень для какой роли, а не «выучить SQL целиком».

Ниже — карта практики на живых схемах, без олимпиадных головоломок как единственного пути. Что уметь на junior, как тренироваться 90 дней, как не врать в skills и куда смотреть вакансии, где SQL в тексте: каталог SQL-вакансий.

Коротко:

  • Сначала роль: аналитик, backend, QA. Объём SQL разный, пересечение — грамотный SELECT и понимание JOIN.
  • Тренируйтесь на схеме с заказами/тикетами/событиями, не на двух таблицах «сотрудник-отдел» вечно.
  • Окна, CTE, проверки дублей — ядро продуктового SQL. Иерархии и рекурсия — по необходимости.
  • Диалект (Postgres, MySQL, SQL Server, Oracle, ClickHouse) берите из вакансий, не коллекцию всех.
  • Готовность — папка запросов с вопросом бизнеса и комментарием, где данные врут. Не сертификат.

Какой уровень какой роли

Data Analyst / продуктовый аналитик. JOIN без размножения факта, окна, когорты на SQL, качество данных. Это центр работы. См. что должен знать Data Analyst и как стать аналитиком.

Backend. Схема, индексы «на пальцах», транзакция, N+1, почему ORM соврал. Писать аналитическую воронку не обязаны, понимать свой запрос — обязаны. Связка с Python/Java/Go — в соответствующих картах языка.

QA. Проверить, что заказ записался, что статус не разъехался, простой SELECT/JOIN, иногда обновление на тестовом стенде по регламенту. Не ClickHouse-агрегации, если вакансия про ручной web.

Поддержка / операции. Чтение по id, осторожность с UPDATE. Не «аналитик» в skills из-за одного SELECT.

Не учите всё сразу «чтобы быть универсальным». Пять вакансий одной роли задают глубину.

База, без которой созвон короткий

  • фильтрация, сортировка, NULL, DISTINCT как костыль vs как смысл;
  • INNER/LEFT JOIN и размножение строк;
  • GROUP BY и HAVING, агрегаты;
  • подзапросы vs JOIN, когда что читаемее;
  • типы дат и часовые пояса на уровне «почему сдвинулся день»;
  • транзакция и грязное чтение — хотя бы словами для backend/аналитика витрин.

Индексы: что такое B-tree на пальцах, почему LIKE '%x' не использует индекс, зачем покрывающий индекс в разговоре, не как DBA. Планы: EXPLAIN читать грубо (seq scan vs index) на Postgres — плюс для аналитика и backend, не обязательный цирк для QA.

Следующий слой: окна и качество

Оконные функции закрывают «как на работе»: нумерация, лаг, доля от группы, кумулятив. CTE делают запрос читаемым. Проверки: дубли ключа, заказы без пользователя, суммы шапки ≠ суммы позиций.

Это важнее, чем знать все функции диалекта. ClickHouse и оконные нюансы — если вакансии про него. Иначе Postgres как учебный стандарт в CIS-продуктах часто достаточен.

Как тренироваться не на абстракции

Соберите или возьмите датасет: users, sessions, orders, order_items, events. Сгенерируйте грязь: дубли, дыры в датах, тестовые аккаунты. Пишите запрос от вопроса: «почему GMV за вторник разъехался с дашбордом».

Каждый файл:

  1. вопрос;
  2. определение метрики;
  3. SQL;
  4. как проверяли;
  5. ограничение данных.

Так же выглядит тестовое аналитика. Жанр тестовых: тестовое задание. Вопросы на интервью: вопросы по SQL.

Пример хода на вопрос «сколько уникальных покупателей за неделю». Сначала определение: покупатель — пользователь с заказом в статусе paid, не с событием click_pay. Неделя — понедельники в таймзоне продукта, не UTC «как получилось». Затем JOIN заказов к пользователям, фильтр статуса, дата. Затем проверка: дубли user_id, заказы без пользователя, тестовые аккаунты. В комментарии к файлу — что будет, если статус paid пишут с опозданием на сутки.

Второй пример: воронка просмотр → корзина → оплата. Если JOIN к событиям размножил пользователей, цифра «конверсия 180%» — сигнал, не победа. Окна или дедуп по пользователю+шагу спасают. Напишите в README, какой ключ считали уникальным. Это и есть навык, который нанимают, а не знание синтаксиса OVER.

Генерация грязи: вставьте двух пользователей с одним email, заказ без позиций, позицию без заказа, события из будущего, 10k одинаковых кликов бота. Ваш запрос должен либо отфильтровать это явно, либо показать, как цифра прыгает. Чистый учебный датасет без грязи учит только зелёный SELECT.

Пример 1. 90 дней под аналитика

  1. Дни 1–20. Схема, проверки качества, выручка без дубля из позиций.
  2. Дни 21–50. Воронка, когорта D7, срез по каналу. Три README-разбора.
  3. Дни 51–70. Окна: ранг заказов пользователя, интервал между покупками.
  4. Дни 71–90. Один «сломанный» отчёт и как нашли причину в SQL. Портфель: портфолио аналитика. Резюме и отклики.

Откликаюсь на junior аналитика. В репозитории: схема заказов, проверка дублей, воронка оплаты и когорта D7 — с определениями метрик. Коммерческого стажа нет. Готов разобрать любой запрос на созвоне и сделать SQL-тестовое на этой неделе. Ссылка: [репозиторий].

Пример 2. 90 дней под backend (SQL внутри сервиса)

Не отдельный «курс SQL», а миграции и запросы своего сервиса.

Было. ORM сам пишет. В skills: SQL, PostgreSQL, MySQL, Mongo, Redis. На созвоне не объяснить, почему список заказов сделал 200 запросов.

Стало. Одна БД как в проекте. Миграции. Два своих запроса: список с фильтром без N+1, отчёт «заявки за день». В README — EXPLAIN на медленном запросе до/после индекса (даже учебного).

Для Python/Java/Go это и есть SQL-roadmap внутри языка, не вместо него.

Чего не делать

  • зубрить 200 задач с сайта без схемы продукта;
  • писать в skills пять СУБД с одного курса;
  • считать Mongo «SQL-навыком»;
  • учить администрирование кластера вместо SELECT, если вы аналитик;
  • копировать запрос из чата без понимания JOIN.

Как не раздувать блок навыков: навыки в IT-резюме. Проверка файла: cv-review.

Индексы, EXPLAIN и честность на созвоне

Вас не просят стать DBA. Просят не написать фильтр по неиндексируемой колонке на миллионе строк и потом удивляться таймауту. На учебной таблице в 50 строк EXPLAIN почти всегда «и так быстро». Имеет смысл сгенерировать десятки тысяч заказов и один раз сравнить seq scan с индексом по (user_id, created_at). В README — два плана до и после. Это артефакт, который можно разобрать голосом.

Что говорить, если не знаете: «на этой выборке смотрел seq scan, индекс по user_id сменил картину, селективность фильтра по статусу низкая — индекс может не взять». Честная гипотеза сильнее заученного «индекс всегда ускоряет». LIKE '%текст%' и функции на колонке в WHERE — типовые ловушки, их стоит один раз пощупать.

Для QA достаточно: найти заказ по id, проверить статус после действия в UI, не сломать стенд UPDATE без WHERE. Для backend — свой запрос списка без N+1 и понимание, что делает транзакция сервиса. Не тащите в skills «оптимизация запросов», если максимум — SELECT с JOIN.

Резюме и как не смешать роли

Аналитик: SQL в центре, три разбора, BI по факту. Backend: SQL внутри проекта, не отдельная профессия. QA: «проверки данных заказа в Postgres», не «SQL developer». Универсальная строка «SQL, MySQL, Postgres, Oracle, Mongo» без запросов — красный флаг. Как чистить блок: навыки в IT-резюме, файл аналитика: резюме Data Analyst.

Письмо аналитика указывает на один запрос и определение метрики. Письмо backend — на миграцию и список без N+1. Шаблон: сопроводительное без опыта. Тестовое SQL часто ограничено по времени: сначала определение, потом JOIN, потом фильтр ботов. Жанр: тестовое задание.

Искать роли с SQL в тексте удобно в каталоге, аналитика — отдельно в вакансиях Data Analyst. Не откликайтесь на DBA и ClickHouse-инженера с папкой из трёх SELECT. Если целитесь в первую работу без стажа — поиск без опыта.

Частые вопросы

Postgres или MySQL для учёбы?

То, что в ваших вакансиях. Если молчат — Postgres. Не оба равноправно без практики. Учебный акцент на Postgres оправдан в CIS-продуктах; MySQL доучивается синтаксисом дат и LIMIT, не новой профессией.

Нужен ли PL/pgSQL?

На junior аналитика обычно нет. На backend — функции точечно, если команда так живёт. Не как центр карты. Триггер «чтобы было» в учебном проекте чаще мешает, чем помогает на созвоне.

Excel заменяет SQL?

Для маленьких выгрузок иногда да. Для вакансий с SQL в обязательных — нет. Сводная не учит JOIN и не показывает размножение строк. Можно сверять Excel с SQL — это плюс качества, не замена навыка.

Стоит ли сертификат?

Не вместо папки запросов. Как личная структура — можно, если не съедает 90 дней. В отборе CIS junior открытый разбор с определением метрики сильнее бейджа.

Как готовиться к live SQL на созвоне?

Пишите вслух определение, затем JOIN, затем фильтр. Озвучьте риск дублей. Тишина и сразу SELECT * хуже медленного, но внятного хода. Тренировка — подготовка к интервью. Держите под рукой свой файл воронки как шпаргалку структуры, не как текст для копирования.

ClickHouse сразу?

Если вакансии аналитика/данных на нём — да, после базы SQL. Если нет — не ради моды. Движок с другой моделью, не «ещё один диалект в skills». Сначала окна и качество в Postgres.

Что сделать сейчас

Выберите роль и пять вакансий. Поднимите Postgres с грязной схемой заказов. Напишите три запроса с вопросом и проверкой. Положите ссылку в резюме и короткое письмо — генератор письма только как каркас.

Дальше ищите совпадение в вакансиях с SQL под свою роль, не «SQL-разработчик» как абстрактная должность, если рынок у вас ищет аналитика или backend. Roadmap без схемы продукта — задачник, не работа.

Ближайшие семь дней: поднимите Postgres, налейте грязную схему заказов, напишите один запрос выручки без дубля из позиций и один запрос дублей ключа. Положите оба файла с вопросом в шапке. Это уже больше, чем сертификат. На второй неделе — воронка и одно окно. На третьей — когорта или интервал между покупками, как требует ваша роль.

Не переключайтесь на ClickHouse, Spark и «аналитические витрины», пока эти три файла нельзя защитить вслух за десять минут. Если роль backend — те же две недели внутри миграций сервиса, не в отдельном курсе. Проверка резюме перед рассылкой: cv-review. Если откликаетесь на QA с SQL в плюсах — хватит проверок заказа по id, не выдавайте себя за аналитика витрин. Для штатной аналитики без открытого разбора отклик почти всегда пустой. Сначала файлы, потом фильтр вакансий, не наоборот.

Откликаюсь на junior аналитика. В репозитории схема заказов: выручка без дубля из позиций, проверка ключей, воронка оплаты с определением шага. Коммерческого стажа нет. Готов разобрать любой файл на созвоне и сделать SQL-тестовое на этой неделе. Ссылка: [репозиторий]. Письмо короткое, резюме — вокруг этих трёх файлов, не вокруг курса.