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 за вторник разъехался с дашбордом».
Каждый файл:
- вопрос;
- определение метрики;
- SQL;
- как проверяли;
- ограничение данных.
Так же выглядит тестовое аналитика. Жанр тестовых: тестовое задание. Вопросы на интервью: вопросы по SQL.
Пример хода на вопрос «сколько уникальных покупателей за неделю». Сначала определение: покупатель — пользователь с заказом в статусе paid, не с событием click_pay. Неделя — понедельники в таймзоне продукта, не UTC «как получилось». Затем JOIN заказов к пользователям, фильтр статуса, дата. Затем проверка: дубли user_id, заказы без пользователя, тестовые аккаунты. В комментарии к файлу — что будет, если статус paid пишут с опозданием на сутки.
Второй пример: воронка просмотр → корзина → оплата. Если JOIN к событиям размножил пользователей, цифра «конверсия 180%» — сигнал, не победа. Окна или дедуп по пользователю+шагу спасают. Напишите в README, какой ключ считали уникальным. Это и есть навык, который нанимают, а не знание синтаксиса OVER.
Генерация грязи: вставьте двух пользователей с одним email, заказ без позиций, позицию без заказа, события из будущего, 10k одинаковых кликов бота. Ваш запрос должен либо отфильтровать это явно, либо показать, как цифра прыгает. Чистый учебный датасет без грязи учит только зелёный SELECT.
Пример 1. 90 дней под аналитика
- Дни 1–20. Схема, проверки качества, выручка без дубля из позиций.
- Дни 21–50. Воронка, когорта D7, срез по каналу. Три README-разбора.
- Дни 51–70. Окна: ранг заказов пользователя, интервал между покупками.
- Дни 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.