Один вопрос про базы данных, который отличает мидла от сеньора за 2 минуты

Запрос, который ломает собесы

Представь: тебе показывают таблицу orders на 12 миллионов строк и запрос:

SELECT * FROM orders
WHERE user_id = 42 AND status = 'completed'
ORDER BY created_at DESC
LIMIT 20;

«Запрос выполняется 8 секунд. Почему? Как ускоришь?»

По данным анализа 9 247 технических интервью за 2025–2026 год, вопросы по базам данных и SQL встречаются примерно в 11% бэкенд-собесов. И именно на вопросах про оптимизацию запросов отсеиваются те, кто знает SQL, но не понимает, как работает база.

Ответ мидла: «Добавлю индекс»

Типичный ответ мидла звучит так: «Нужно добавить индекс на user_id». Иногда — «составной индекс на user_id и status». Это не неправильно. Но это ответ вслепую.

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

Вот что мидл обычно не учитывает:

• Индекс уже может быть. Может, проблема не в его отсутствии, а в том, что оптимизатор выбрал Seq Scan, потому что user_id = 42 возвращает 40% таблицы.
• Порядок колонок в составном индексе имеет значение. (user_id, status) и (status, user_id) — это два разных индекса с разной эффективностью.
• ORDER BY без покрывающего индекса = filesort. Даже если WHERE отработал по индексу, сортировка 50 тысяч строк в памяти убьёт производительность.

Ответ сеньора: «Покажи EXPLAIN»

Сеньор не гадает. Первое, что он говорит:

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = 42 AND status = 'completed'
ORDER BY created_at DESC
LIMIT 20;

И дальше читает результат как рентгеновский снимок:

• Seq Scan vs Index Scan — база вообще использует индекс?
• Rows estimated vs actual — оптимизатор правильно оценивает кардинальность?
• Sort Method: external merge — сортировка ушла на диск?
• Filter vs Index Cond — фильтрация по индексу или постфактум?

Только после этого сеньор предлагает решение. И оно конкретное:

CREATE INDEX idx_orders_user_status_created
ON orders (user_id, status, created_at DESC);

Почему именно такой? Потому что:

1. user_id и status — в WHERE, они идут первыми
2. created_at DESC — покрывает ORDER BY, избавляя от filesort
3. Это покрывающий индекс для сортировки — база достаёт уже отсортированные данные

Почему это важно интервьюеру

Интервьюер проверяет не знание синтаксиса CREATE INDEX. Он проверяет мышление.

Мидл-мышление: «Есть проблема → знаю инструмент → применяю». Это работает в 60% случаев. В остальных 40% ты добавишь индекс, который база проигнорирует, или создашь пятый индекс на таблицу, где проблема была в SELECT *.

Сеньор-мышление: «Есть проблема → измеряю → понимаю причину → применяю точечно». EXPLAIN — это не просто команда. Это подход: сначала данные, потом решение.

На реальных собесах этот подход раскрывается в follow-up вопросах:

• «А если user_id = 42 возвращает миллион строк?» — сеньор скажет про селективность и почему оптимизатор может выбрать Seq Scan
• «А что с записью?» — сеньор упомянет, что каждый индекс замедляет INSERT/UPDATE, и предложит мониторить pg_stat_user_indexes для неиспользуемых индексов
• «А если нужны только id и created_at?» — сеньор предложит покрывающий индекс с INCLUDE, чтобы избежать обращения к таблице

Три вещи, которые стоит запомнить

1. EXPLAIN перед любым изменением. Не добавляй индекс, пока не прочитал план выполнения. Это как чинить машину, не открыв капот.

2. Составной индекс — не просто «два поля вместе». Порядок колонок определяет, какие запросы он покрывает. Правило: сначала колонки из WHERE (с равенством), потом из ORDER BY, потом из SELECT для покрытия.

3. Индексы — это trade-off. Каждый индекс ускоряет чтение и замедляет запись. На таблице с 80% записей и 20% чтений лишний индекс — это проблема, а не решение.

Если ты готовишься к собесу и хочешь перейти от «знаю SQL» к «понимаю базы» — попробуй Sobes AI. Он задаёт именно такие вопросы с follow-up'ами и разбирает твои ответы, чтобы ты пришёл на собес с мышлением сеньора, а не с заученными определениями.

Кстати, если хочешь подтянуть SQL в целом — у нас есть разбор вопросов по SQL для мидлов с конкретными задачами и объяснениями.