Сталкивались ли вы с проблемами оптимизации запросов

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

Умеете ли вы искать причину, а не угадывать. Вопрос открытый, и от ответа ждут конкретики: как нашли медленный запрос, что показал план, что изменилось после правки.

Как отвечать

Держите структуру «как нашёл, что понял, что сделал, что получил».

• нашёл: медленные запросы видны в мониторинге приложения, в логе долгих запросов базы, в pg_stat_statements. Важно смотреть не только на самый медленный, но и на самый частый: запрос по 20 мс, вызываемый тысячу раз на страницу, дороже одного на секунду;
• понял: EXPLAIN (ANALYZE, BUFFERS) показывает фактический план, а не догадки. Ищем последовательное сканирование большой таблицы, ошибку оценки числа строк, соединение вложенными циклами там, где нужен хеш, сортировку с уходом на диск;
• сделал: подходящий индекс (составной в правильном порядке колонок, частичный по where, покрывающий с INCLUDE), переписывание запроса (убрать функцию с индексируемой колонки, заменить OFFSET на пагинацию по ключу, вынести подзапрос), уменьшение выборки (только нужные колонки, фильтрация до соединения), актуальная статистика через ANALYZE;
• на стороне приложения: чинится проблема N+1 запросов (в Django это select_related и prefetch_related, в SQLAlchemy joinedload), добавляется пакетная вставка, включается пул соединений, ставится кеш на неизменные справочники;
• получил: цифры до и после, на том же объёме данных.

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

Добавляют индекс на каждую колонку из WHERE и получают замедление записи без выигрыша на чтении.

Меряют на пустой тестовой базе, где план другой и любое решение выглядит быстрым.

Кешируют вместо исправления запроса. Кеш прячет проблему до первого промаха и создаёт вторую, про инвалидацию.

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