Большинство новичков думают, что SQL — это язык, который учат один раз: SELECT, JOIN, WHERE, GROUP BY — и готово. Потом они открывают реальную базу с несколькими миллионами строк, пишут тот же запрос, который отрабатывали на игрушечной таблице, и смотрят, как он висит сорок секунд. Этот разрыв — между синтаксисом, который вы знаете, и поведением, которое можете предсказать, — и есть весь предмет «SQL и базы данных», и именно здесь живёт интересная работа.
Реляционная база данных — это не картотека, которая хранит то, что вы положили. Это планировщик запросов, который решает, как извлекать ваши данные, и это решение зависит от статистики, индексов, размеров таблиц и формы вашего условия WHERE. Вы пишете декларативное утверждение; движок компилирует его в план. Понимание этого перевода — то, что отличает человека, который «знает SQL», от человека, который умеет работать с базами данных.
Ниже — разбор того, как практики на самом деле решают реальную задачу, где ломается сама схема и какие существуют учебные маршруты — с честными затратами.
Один запрос, три плана: пошаговый разбор
Допустим, у вас есть таблица orders с 2 000 000 строк и таблица customers с 50 000 строк. Задача: вывести суммарные траты каждого клиента за последние 90 дней, только для клиентов из заданной страны, отсортированные по сумме трат.
Новичок пишет так:
SELECT c.name, SUM(o.amount) AS total
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.country = 'DE'
AND o.created_at > NOW() - INTERVAL '90 days'
GROUP BY c.name
ORDER BY total DESC;
Это работает. На тестовой базе с 500 строками возвращается мгновенно. На продакшене занимает 40 секунд. Вот порядок, в котором практик исследует проблему.
Шаг 1 — читайте план, а не запрос. EXPLAIN ANALYZE показывает, что произошло на самом деле: какая таблица сканировалась, сколько строк планировщик ожидал и сколько получил, и куда ушло время. Seq Scan по 2 000 000 строк — обычный вердикт. Планировщик выбрал его, потому что либо на orders.created_at нет индекса, либо он есть, но планировщик оценил фильтр как недостаточно селективный, чтобы возиться.
Шаг 2 — проверьте индекс, затем проверьте статистику. Индекс только по created_at помогает, но запрос фильтрует по дате и соединяет по customer_id. Составной индекс по (customer_id, created_at) позволяет движку извлекать только нужный срез для каждого клиента. Это неочевидная часть: порядок столбцов в индексе имеет значение. (customer_id, created_at) и (created_at, customer_id) — разные инструменты. Первый обслуживает поиск по клиенту в пределах диапазона дат; второй обслуживает сканирование по всем клиентам в диапазоне дат. Если оценки строк планировщиком сильно расходятся, ANALYZE обновляет статистику и может полностью перевернуть план.
Шаг 3 — усомнитесь в форме. Группировка по c.name — тихий баг: два клиента с одинаковым именем сливаются в одну строку. Группируйте по c.id и выбирайте имя рядом. Это именно та ошибка, которая даёт правдоподобно выглядящие числа, что хуже ошибки.
Что сломается, если пропустить эти шаги? Вы добавите индексы повсюду, записи замедлятся, потому что каждый INSERT теперь поддерживает пять индексов, а исходный запрос всё равно выполняет последовательное сканирование, потому что планировщик никогда не использует индекс, который считает бесполезным. Индексы — это компромисс: вы платите за записи и хранение, чтобы выиграть на чтении, и небрежный индекс — это налог без выгоды.
Где ломается сам механизм
Это не ошибки новичков. Это случаи, когда эмпирические правила перестают работать.
1. Индекс есть, но планировщик его игнорирует
Что идёт не так: вы добавили индекс, но запрос всё равно сканирует. Частые причины: функция оборачивает столбец (WHERE DATE(created_at) = ... не может использовать индекс по created_at), неявное приведение типов меняет сравнение, или статистика устарела, и планировщик считает, что фильтр соответствует большей части таблицы — в этом случае сканирование действительно дешевле.
Как заметить это рано: EXPLAIN до и после любого изменения индекса. Если план не изменился, индекс не используется, и вам следует выяснить почему, прежде чем добавлять ещё один.
Если уже слишком поздно: перепишите предикат так, чтобы столбец стоял отдельно (created_at >= ... AND created_at < ... вместо функции над ним), затем повторно запустите ANALYZE. Удаление неиспользуемых индексов — законное исправление, а не признание поражения.
2. Запрос быстрый, но данные неверны
Что идёт не так: LEFT JOIN с фильтром по правой таблице в предложении WHERE молча превращается во внутреннее соединение, отбрасывая строки, которые вы ожидали сохранить. Агрегаты по соединённым строкам считают дважды, когда у одного заказа несколько позиций.
Как заметить это рано: сравнивайте количество строк на каждом этапе — до соединения, после соединения, после группировки. Если количество неожиданно подскакивает, соединение размножает строки.
Если уже слишком поздно: ущерб тихий и живёт в отчётах. Исправление — сверочный запрос: сумма из исходной таблицы против суммы из агрегированного запроса, запущенные бок о бок.
3. Транзакции, которые держат блокировки дольше, чем вы думаете
Что идёт не так: длительная транзакция — миграция, пакетное обновление, забытая открытая сессия — держит блокировки и блокирует записи. Под нагрузкой запросы встают в очередь, и очередь растёт быстрее, чем рассасывается.
Как заметить это рано: отслеживайте ожидания блокировок и возраст транзакций. Транзакция, открытая минутами в OLTP-системе, — это сигнал, а не курьёз.
Если уже слишком поздно: разбивайте крупные обновления на порции, держите транзакции короткими и знайте свой уровень изоляции — по умолчанию в PostgreSQL это Read Committed, который ведёт себя не так, как многие предполагают, когда рассуждают о конкурентных обновлениях.
4. Схема, которая была хороша при 10 000 строк
Что идёт не так: денормализованные данные, которые упрощали ранние запросы, выходят из синхронизации. Столбец, дублированный в таблицах, обновляется в одном месте и не обновляется в другом. Нормализация — это не академическая аккуратность, это механизм, который заставляет один факт жить в одном месте.
Как заметить это рано: если вы когда-либо вручную записываете одно и то же значение в две таблицы, у вас есть будущая несогласованность.
Если уже слишком поздно: миграции для исправления дороги, но механистичны — извлеките факт, заполните обратно, добавьте ограничение, чтобы старый путь не мог повториться.
Учебные маршруты и их стоимость
Есть три реалистичных пути, и они различаются не столько содержанием, сколько обратной связью.
| Путь | Время | Деньги | Что вы реально получаете |
|---|---|---|---|
| Самостоятельное изучение по документации и туториалам | Месяцы, неравномерно | Почти ноль | Синтаксис и рецепты; никто не скажет, что ваш запрос неверен или ваша схема не масштабируется |
| Практика на реальных проектах | Месяцы, привязано к работе | Бесплатно, но медленно | Реальные режимы отказа — но ошибки дороги, и вы учитесь реактивно |
| Структурированный курс | Недели — несколько месяцев | Умеренно | Последовательность, упражнения с мгновенной проверкой и кто-то, к кому можно обратиться, когда план удивляет |
Честный компромисс: самообразование дешевле всего и работает, если у вас уже есть проект с реальными данными и кто-то, кто проверяет ваши решения. Практика — лучший учитель, но редко приходит по расписанию. Курс покупает структуру и обратную связь — две вещи, которые самообразование не может обеспечить само по себе, потому что вы не можете исправить заблуждение, о котором не знаете.
Структурированный маршрут также заставляет вас пройти через скучные, но решающие части: транзакции, уровни изоляции, нормализацию, оконные функции. Это темы, которые люди пропускают, пока продакшен не научит их в самый неподходящий момент. Курс SQL и базы данных построен вокруг этой последовательности — PostgreSQL и MySQL, проектирование схем, оптимизация запросов через индексы и оконные функции — и уроки адаптируются к вашему текущему уровню, так что вы не перечитываете синтаксис JOIN, который уже знаете.
Если вы взвешиваете более широкое техническое направление, наша статья о Kotlin на максималках показывает похожий принцип: инструменты ускоряют вас только после того, как вы понимаете, что они делают. То же самое относится к планировщикам запросов.
Кому это подходит, а кому нет
Этот путь подходит аналитикам, бэкенд-разработчикам, QA-инженерам и продакт-менеджерам, которые уже работают с данными и хотят перестать гадать. Если вы можете написать JOIN, но не можете объяснить, почему запрос медленный, вы — точно целевая аудитория.
Он не подходит людям, которые хотят чисто теоретический курс по базам данных на основе реляционной алгебры, или тем, кто надеется, что SQL станет навыком за выходные. Язык занимает дни; суждение о планах, индексах и транзакциях требует недель осознанной практики.
Базы данных вознаграждают того, кто умеет рассуждать о том, что происходит под капотом. Изучите синтаксис, затем изучите планировщик, затем узнайте, где план вам врёт. Курс проходит через эти расчёты с примерами и даёт обратную связь по вашим решениям о запросах — детали и запись на странице SQL и базы данных. Начните с одного медленного запроса из вашей собственной работы и объясните его строка за строкой.
Начать можно здесь: SQL и Базы данных.