Какие есть способы оптимизации тяжелых запросов к базе данных

Что проверяют

Для аналитика это вопрос о том, умеете ли вы сами написать отчётный запрос, который не кладёт базу, и сможете ли внятно поставить задачу разработчикам, если без индекса или витрины не обойтись. Следом часто просят объяснить, что показывает EXPLAIN.

Как отвечать

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

• план выполнения: EXPLAIN ANALYZE в PostgreSQL показывает, где база читает таблицу целиком (Seq Scan), где сортирует и сколько строк реально прошло через каждый шаг;
• условия, дружелюбные к индексу: WHERE created_at >= '2026-01-01' может использовать индекс, а WHERE date_trunc('month', created_at) = ... или приведение типа над колонкой обычно нет;
• фильтровать раньше: сначала сужаем выборку по периоду и сегменту, потом соединяем и агрегируем;
• EXISTS вместо JOIN с DISTINCT: когда нужны «клиенты, у которых был заказ», соединение размножает строки, а DISTINCT потом тратит время на их схлопывание;
• оконные функции: ROW_NUMBER() и LAG() для последнего события или разницы между периодами вместо коррелированных подзапросов;
• только нужные колонки и LIMIT, пока вы исследуете данные;
• витрины и материализованные представления: если отчёт смотрят каждый день, его считают заранее по расписанию, а не при каждом открытии дашборда;
• правильное место: тяжёлые запросы идут в реплику или аналитическое хранилище, а не в боевую базу приложения.

Если ускорение требует индекса или партиционирования, аналитик формулирует это как требование: какой запрос, как часто, с какими фильтрами и какое время ответа допустимо.

Где спотыкаются

Лечат дубли после соединения через DISTINCT и не ищут причину. Результат выглядит правильно, но запрос тяжелее в разы, а в агрегатах вроде SUM размноженные строки всё равно завышают итог.

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

Проверяют скорость на маленькой тестовой базе. План на тысяче строк и на ста миллионах может быть совершенно разным.