Все материалы
Продуктовая аналитикагайдстарт

Как выучить SQL с нуля: маршрут на шесть недель для аналитика

План изучения SQL с нуля для будущего аналитика: что учить по неделям, какой запрос вы должны уметь написать к концу каждой, где практиковаться и когда идти на собеседование.

КПКейсПрактика23 сентября 2026 г.17 мин

Типичный план «SQL с нуля» выглядит как список тем: SELECT, WHERE, GROUP BY, JOIN, подзапросы, оконные функции. Через месяц человек узнаёт каждое слово, но на тестовом задании не может посчитать, сколько людей из рекламы вернулось на следующий день. Проблема не в темах, а в том, что у списка нет проверки: непонятно, выучена неделя или нет. Ниже маршрут на шесть недель, у которого проверка есть. Каждая неделя заканчивается вопросом к одной и той же учебной базе продукта и числом, которое должно получиться. Совпало — можно идти дальше. Не совпало — ошибка покажет, что повторить. Маршрут рассчитан на будущего аналитика данных или продуктового аналитика, а не на разработчика или администратора базы.

Коротко

Для аналитика «знать SQL» значит уметь самостоятельно превратить вопрос менеджера в запрос на чтение и проверить, что число верное. Администрирование, проектирование схем и хранимые процедуры в этот объём не входят. Такой уровень набирается за шесть-восемь недель при 4–6 часах практики в неделю. Это ориентир, а не обещание: у кого-то уйдёт больше, и это нормально.

  • Неделя 1: как устроена база — таблицы, строки, ключи. Проверка: 4 613 пользователей.
  • Неделя 2: SELECT, WHERE, ORDER BY. Проверка: 356 мобильных регистраций из paid_search в августе.
  • Неделя 3: агрегаты и GROUP BY. Проверка: 1 251 платёж, но 912 платящих.
  • Неделя 4: JOIN и зерно результата. Проверка: активация organic — 66,7%.
  • Неделя 5: CASE, NULL и CTE. Проверка: 152 человека принесли $50 и больше.
  • Неделя 6: даты, окна и продуктовые метрики. Проверка: D1 retention — 53,42%.

Сколько времени нужно и что значит «знать SQL» для аналитика

На вопрос «за сколько можно выучить SQL» есть два честных ответа. Синтаксис первого запроса — SELECT, FROM, WHERE — осваивается за вечер. Уровень, с которым берут младшим аналитиком, — за полтора-два месяца регулярной практики. Разница между ними не в новых командах, а в навыке, который приходит только с задачами: замечать, что запрос вернул правдоподобное, но неверное число.

Аналитик почти всегда пишет запросы на чтение. Ему не нужно создавать таблицы, настраивать права и индексы, писать триггеры. Ему нужно уметь пять вещей: отобрать строки по условию, посчитать по группам, соединить таблицы так, чтобы строки не размножились, работать с датами и периодами и собрать длинный расчёт из понятных шагов. Шестая, самая важная, — проверить результат: сверить с контрольной суммой, посмотреть на крайние значения, спросить, нет ли в периоде неполного дня.

Отсюда и устройство маршрута. Каждая неделя добавляет одну из этих способностей, а контрольный вопрос проверяет именно её. Числа в вопросах взяты из учебной базы SQL-курса: это SaaS-продукт с пятью таблицами и 45 185 строками. Её можно открыть в песочнице без регистрации и проверить любой ответ из этой статьи.

Что входит в SQL аналитика и что можно отложить
Нужно с первого месяцаМожно отложить
SELECT, WHERE, ORDER BY, LIMITCREATE TABLE, ALTER, права доступа
COUNT, SUM, AVG, GROUP BY, HAVINGINSERT, UPDATE, DELETE (нужен минимум)
INNER и LEFT JOIN, контроль числа строкиндексы и планы выполнения
CASE, COALESCE, NULL, CTE, подзапросыхранимые процедуры и триггеры
функции дат, оконные функциинормализация сверх третьей формы

Какой SQL учить: PostgreSQL, MySQL или что-то ещё

Начинающие часто застревают на выборе диалекта. Для первых шести недель он почти не важен: SELECT, WHERE, GROUP BY, JOIN, CASE, CTE и оконные функции пишутся одинаково в PostgreSQL, DuckDB, MySQL 8 и большинстве аналитических баз. Различия начинаются в функциях дат, строк и в мелочах вроде деления: в PostgreSQL 7 / 2 даёт 3, а в DuckDB — 3,5.

Практичный выбор — учиться на PostgreSQL-подобном синтаксисе. Он близок к стандарту, у него подробная документация на русском, и переход на ClickHouse, BigQuery или Greenplum на работе сводится к изучению функций, а не языка заново. Учебная база курса работает на DuckDB, диалект которого почти совпадает с PostgreSQL. Где они расходятся, это отмечено в статье с примерами запросов.

Неделя 1. Таблица, строка, ключ: как устроена база

Первая неделя почти без запросов, и это правильно. Большинство ошибок новичка — не в синтаксисе, а в непонимании того, что описывает одна строка таблицы. В users строка — человек. В payments — платёж, и у одного человека их может быть три. В events — событие. Это называется зерном таблицы, и о нём стоит спрашивать перед каждым запросом.

Вторая тема недели — ключи. user_id в users — первичный ключ: он уникален и однозначно указывает на человека. В payments и events тот же user_id — внешний ключ, ссылка на пользователя. Именно по нему таблицы потом соединяются. Если понять связь ключей сейчас, неделя 4 пройдёт вдвое быстрее.

Практика недели — открыть песочницу, посмотреть по пять строк каждой таблицы и выполнить первый подсчёт. Этим же начинается бесплатная нулевая глава SQL-курса.

Контрольный запрос недели 1
SELECT count(*) AS users
FROM users;

-- 4613

Неделя 2. SELECT, WHERE и сортировка: первые ответы

Вторая неделя — выборка и фильтрация. Выбрать нужные колонки, ограничить число строк, задать порядок, отфильтровать по одному условию, по нескольким, по списку и по диапазону дат. К концу недели запрос с тремя условиями через AND должен писаться без подсказки.

Две вещи стоит отработать отдельно, потому что на них спотыкаются и через год. Первая — приоритет AND над OR: без скобок условие «organic из России или Казахстана» вернёт 1 927 человек вместо 1 365. Вторая — NULL: country = NULL не находит ничего, нужен IS NULL. В учебной базе у 55 человек нет страны, и на них удобно проверить себя.

Главы 1 и 2 курса покрывают эту неделю и открыты бесплатно.

Контрольный вопрос недели 2: сколько человек пришли из paid_search с телефона в августе
SELECT count(*) AS users
FROM users
WHERE channel = 'paid_search'
  AND device = 'mobile'
  AND signup_date >= DATE '2026-08-01';

-- 356

Неделя 3. Агрегаты и GROUP BY: первые метрики

С третьей недели запросы начинают отвечать на вопросы бизнеса: сколько, какая сумма, какое среднее, в какой группе больше. COUNT, SUM, AVG, MIN, MAX, GROUP BY и HAVING — это почти все метрики из первых отчётов аналитика.

Ключевой навык недели — различать, что именно считает count. Строки, заполненные значения и уникальные значения — три разных числа. Платежей в базе 1 251, а платящих людей 912, потому что 290 человек продлевали тариф. Если в отчёте написано «пользователи», а в запросе стоит count(*) по платежам, отчёт завышен на треть.

Вторая тема — доля от общего: какой процент регистраций даёт каждый канал. Это первая задача, где нужно подумать о знаменателе, и хорошая подготовка к метрикам шестой недели.

Контрольный вопрос недели 3: платежи и платящие
SELECT count(*) AS payments,
       count(DISTINCT user_id) AS payers
FROM payments;

-- 1251 | 912

Неделя 4. JOIN и зерно результата

Соединение таблиц — место, где новички теряют больше всего времени, и место, где ошибки дороже всего. Запрос с JOIN почти всегда выполняется и почти всегда возвращает правдоподобное число. Проверить его можно только одним способом: знать, сколько строк должно получиться, и сравнить.

Пример из учебной базы. Если соединить пользователей с платежами и посчитать строки по каналу, organic покажет 566 «плательщиков». Людей на самом деле 410: остальные строки — продления. Из этого вырастает правило недели: после каждого JOIN спросите, что теперь описывает одна строка, и посчитайте строки и уникальные ключи.

Второе правило — LEFT JOIN для вопросов «у кого нет». Он сохраняет строки без пары, и это единственный способ посчитать долю, где в знаменателе все пользователи, а в числителе только сделавшие действие. Так считается активация по каналам — вопрос седьмой главы курса и контрольный вопрос этой недели.

Контрольный вопрос недели 4: доля создавших рабочее пространство по каналам
SELECT u.channel,
       count(*) AS users,
       count(a.user_id) AS activated,
       round(100.0 * count(a.user_id) / count(*), 1) AS activation_pct
FROM users u
LEFT JOIN (SELECT DISTINCT user_id FROM events
           WHERE event_name = 'workspace_created') a
  ON a.user_id = u.user_id
GROUP BY u.channel
ORDER BY activation_pct DESC;

-- referral 74.7 | organic 66.7 | partner 53.2 | paid_search 37.0

Неделя 5. CASE, NULL и CTE: запросы, которые можно читать

К пятой неделе запросы становятся длинными, и появляется новая проблема: через день автор сам не может их прочитать. Три инструмента недели решают её с разных сторон. CASE WHEN превращает значения в понятные сегменты. COALESCE решает, что делать с пропуском. CTE через WITH разбивает расчёт на именованные шаги, каждый из которых можно выполнить и проверить отдельно.

Контрольный вопрос недели собирает всё вместе. Сначала CTE считает выручку каждого пользователя, и у не плативших она через COALESCE становится нулём, а не NULL. Потом CASE раскладывает людей на три сегмента. Если забыть COALESCE, 3 701 не плативший не попадёт в сегмент «не платил»: их сумма останется NULL, условие revenue = 0 для NULL не выполнится, и они уйдут в ветку ELSE. Сегмент «$50 и больше» раздуется со 152 до 3 853 человек.

На этой же неделе полезно разобрать подзапросы: IN, EXISTS и подзапрос в FROM. Им посвящена одиннадцатая глава курса, но базовые приёмы понадобятся уже в шестой неделе.

Контрольный вопрос недели 5: сегменты по выручке
WITH user_revenue AS (
  SELECT u.user_id, coalesce(sum(p.amount), 0) AS revenue
  FROM users u
  LEFT JOIN payments p ON p.user_id = u.user_id
  GROUP BY u.user_id
)
SELECT CASE
         WHEN revenue = 0  THEN 'не платил'
         WHEN revenue < 50 THEN 'до $50'
         ELSE '$50 и больше'
       END AS segment,
       count(*) AS users,
       sum(revenue) AS revenue
FROM user_revenue
GROUP BY 1
ORDER BY users DESC;

-- не платил 3701 | 0
-- до $50 760 | 20482
-- $50 и больше 152 | 10157

Неделя 6. Даты, окна и продуктовые метрики: DAU, воронка, retention

Последняя неделя соединяет SQL с работой аналитика. DAU — число людей, открывших продукт за день, — требует привести время события к дате и считать людей, а не события. Воронка требует посчитать, сколько людей дошли до каждого шага. Retention требует сравнить дату события с датой регистрации и отбросить тех, у кого окно ещё не закрылось.

Воронка учебной базы выглядит так: приложение открыли все 4 613 человек, рабочее пространство создали 2 750, отчёт — 1 775. Самый большой провал между первым и вторым шагом, но и между вторым и третьим теряется 975 человек. Такие числа уже можно нести на встречу с продуктом.

Контрольный вопрос — D1 retention: какая доля людей открыла приложение на следующий календарный день после регистрации. В знаменателе только регистрации по 28 августа: выгрузка закрыта 30-го в 13:00, и у зарегистрированных 29-го следующий день ещё не прожит целиком. Ответ — 2 444 из 4 575, или 53,42%, ровно как в девятой главе курса. По каналам разброс вдвое: referral 66,08%, paid_search 34,46%.

Оконные функции — row_number(), lag(), накопительная сумма — логично добавить в конце недели или сразу после неё. Они нужны для первой покупки, прироста к прошлому месяцу и скользящего среднего.

Продуктовая воронка учебной базы: люди на каждом шаге

count(DISTINCT user_id) по событиям app_open, workspace_created и report_created. Учебная база SQL-курса.

Открыли приложение100% от входа
Создали пространство60% от входа
Создали отчёт38% от входа
Контрольный вопрос недели 6: D1 retention зрелых регистраций
SELECT count(*) AS eligible,
       count(*) FILTER (WHERE EXISTS (
         SELECT 1 FROM events e
         WHERE e.user_id = u.user_id
           AND e.event_name = 'app_open'
           AND CAST(e.event_time AS DATE) = u.signup_date + 1
       )) AS returned
FROM users u
WHERE u.signup_date <= DATE '2026-08-28';

-- 4575 | 2444  → 53,42%

Маршрут одной таблицей: неделя, глава курса, статья и проверка

Таблица собирает маршрут в одном месте. Главы — это главы SQL-курса КейсПрактики на той же учебной базе, статьи — разборы в блоге. Проходить можно по любому из двух столбцов или по обоим: в статьях объяснение подробнее, в главах те же вопросы решаются с автоматической проверкой.

Шесть недель, главы курса и контрольные числа
НеделяТемаГлавы курсаКонтрольный вопросОтвет
1как устроена база, ключи0сколько пользователей в базе4 613
2SELECT, WHERE, ORDER BY1–2мобильные регистрации paid_search в августе356
3агрегаты, GROUP BY, HAVING3платежи и платящие1 251 и 912
4JOIN, зерно результата4, 7активация organic66,7%
5CASE, NULL, CTE, подзапросы5, 11сколько принесли $50 и больше152
6даты, окна, DAU, воронка, retention6, 8, 9, 10, 12D1 retention зрелых регистраций53,42%
D1 retention по каналам: что вы посчитаете к концу шестой недели

Регистрации по 28 августа, возврат — app_open на следующий календарный день. Учебная база SQL-курса, 9-я глава.

D1 retention, %

Как практиковаться: задачи, песочница и чужие запросы

Смотреть видео про JOIN и понимать JOIN — разные состояния. Навык появляется, когда вы пишете запрос сами, получаете неверное число и находите причину. Поэтому на каждую неделю маршрута нужно в два-три раза больше времени на задачи, чем на теорию.

Полезная привычка с первой недели — до запуска запроса предсказать результат. «Строк будет примерно столько же, сколько пользователей», «выручка не может быть больше $30 639». Если результат разошёлся с ожиданием, это повод разобраться, а не переписать запрос до совпадения.

Второй источник практики — чужой SQL. Возьмите готовый запрос, найдите в нём самый глубокий подзапрос, выполните его отдельно и назовите зерно каждого шага. Четырнадцатая глава курса построена именно так: в чужом запросе нужно найти раздутую выручку, сломанный LEFT JOIN и дубли событий. Это ближе всего к тому, что происходит на работе в первые месяцы.

  • Задачи с решениями — чтобы тренировать перевод вопроса в запрос.
  • Песочница на реальной базе — чтобы проверять свои гипотезы без готового ответа.
  • Чужие запросы — чтобы учиться находить ошибки, которые не видны по результату.
  • Объяснение вслух — чтобы подготовиться к собеседованию, где решение нужно проговорить.

Книги, курсы и тренажёры: что выбрать под свою цель

Формат выбирается не по тому, что «лучше», а по тому, чего не хватает. Книга даёт систему и справочник, к которому возвращаются годами. Тренажёр даёт количество задач и быструю обратную связь. Курс даёт последовательность и проверку. У каждого формата есть слабое место, и его стоит знать заранее.

Из книг на русском полезны две. «Изучаем SQL. Генерация, выборка и обработка данных» Алана Болье (3-е издание, «Диалектика») идёт от устройства базы к запросам и подзапросам, примеры в ней для MySQL, Oracle Database и SQL Server. «SQL. Сборник рецептов» Энтони Молинаро и Роберта де Граафа (2-е издание, «БХВ-Петербург») — справочник готовых приёмов для Oracle, DB2, SQL Server, MySQL и PostgreSQL. Её удобнее открывать на конкретной задаче, чем читать подряд. Бесплатно — учебное пособие в русской документации PostgreSQL на postgrespro.ru: разделы «Язык SQL» и «Расширенные возможности» дают основу и оконные функции.

Тренажёры хороши для объёма: сотни коротких задач с автоматической проверкой. Их слабость — учебные предметные области вроде интернет-магазина или приёма абитуриентов, где не отработать продуктовые вопросы: retention, воронку, разбор A/B-теста. Подробное сравнение тренажёров и песочниц с проверенными фактами — в отдельной статье.

SQL-курс КейсПрактики — 18 глав и 54 задания на одной учебной базе продукта: от первого SELECT до когорт, аудита чужого SQL и сегментного разбора A/B-теста. Запрос проверяется выполнением: он запускается на базе и сверяется с эталонным результатом, а не с текстом решения. Главы 0–2 открыты без регистрации, за полный доступ платят один раз, условия — на странице стоимости.

Какой формат закрывает какую потребность
ЦельФорматСлабое место
понять систему и иметь справочниккниганет проверки: легко решить, что понял
набить руку на синтаксисетренажёр с задачамиабстрактные схемы, мало продуктовых вопросов
проверить свою гипотезу на данныхпесочницанет готового ответа и последовательности
пройти путь от нуля до метриккурс на одной базенужно время подряд, а не урывками
подготовиться к собеседованиюзадачи с решениями и разбор вопросовне заменяет практику на реальных данных

Как понять, что пора на собеседование

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

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

  • Какая доля выручки приходится на канал organic? → 46,1%.
  • Сколько пользователей создали рабочее пространство, но не создали ни одного отчёта? → 975.
  • Какая выручка на платящего пользователя в paid_search? → $28,69.
  • Сколько регистраций было в среднем за 7 дней на 29 августа? → 72,0.
  • На сколько процентов выросли регистрации в августе к июлю? → 13,1%.
  • Какой тариф выбрали в первом платеже чаще всего и сколько раз? → basic, 514.
  • Сколько людей зарегистрировались меньше чем за 14 дней до 30 августа? → 952.
  • Какая конверсия у варианта checklist на мобильных? → 19,9% против 20,1% в контроле.

Частые ошибки тех, кто учит SQL с нуля

Большинство этих ошибок не связаны с синтаксисом. Запрос выполняется, число выглядит разумно, и ошибка всплывает, только когда кто-то сверит его с другим источником.

  • Учить темы по списку без задач: через месяц всё знакомо, но ничего не пишется.
  • Считать строки вместо людей: 1 251 платёж вместо 912 платящих.
  • Не проверять число строк после JOIN: выручка вырастает в разы, и это не видно по форме результата.
  • Сравнивать неполный период с полным: последний день выгрузки выглядит как падение DAU.
  • Включать незрелые когорты в retention: у вчерашних регистраций «следующий день» ещё не наступил.
  • Прыгать между диалектами в первый месяц: синтаксис основ один, а различия в функциях только путают.
  • Переписывать запрос до совпадения с ответом вместо того, чтобы понять, откуда разница.

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

За сколько можно выучить SQL с нуля? Синтаксис основ — за одну-две недели. Уровень, достаточный для работы младшим аналитиком, — за шесть-восемь недель при 4–6 часах практики в неделю. Быстрее получается у тех, кто уже работал с Excel и сводными таблицами.

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

Нужны ли математика и английский? Для SQL аналитика хватает школьной арифметики: доли, проценты, среднее. Английский нужен на уровне чтения ключевых слов и сообщений об ошибках, документация PostgreSQL есть на русском.

С чего начать изучение SQL: с SQL или с Python? Аналитику обычно — с SQL. Данные в компаниях лежат в базах, и первые рабочие задачи — выгрузки и метрики — решаются запросом. Python нужен для статистики, автоматизации и графиков, и учить его проще, когда вы уже понимаете таблицы и группировки.

Нужно ли устанавливать базу данных на компьютер? Для первых недель нет. Достаточно онлайн-песочницы, где уже загружены таблицы. Ставить PostgreSQL или DuckDB локально имеет смысл, когда захочется работать со своими файлами.

С чего начать сегодня

Откройте песочницу, выполните SELECT * FROM users LIMIT 5 и SELECT count(*) FROM users. Если получили пять строк и 4 613 — первая неделя началась. Дальше можно идти по главам курса, по статьям из таблицы маршрута или по обоим сразу. Главное — не переходить к следующей неделе, пока контрольный вопрос текущей не решён без подсказки.

Продолжить чтение
Вся библиотека