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

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

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

Как отвечать

Разложите на три слоя.

• как находят: pg_stat_statements в PostgreSQL (сортировка по total_exec_time и calls), log_min_duration_statement для медленных запросов, slow query log и Performance Schema в MySQL, APM и трассировка через OpenTelemetry, метрики пула в Micrometer с графиками в Grafana;
• как разбирают: EXPLAIN (ANALYZE, BUFFERS) и сравнение оценки с фактом. Сигналы это Seq Scan по большой таблице, Nested Loop с плохой оценкой строк, сортировка с уходом на диск, огромный Rows Removed by Filter. Для чтения плана удобен pev2 или explain.dalibo.com, в MySQL 8 есть EXPLAIN ANALYZE;
• со стороны Java: p6spy или datasource-proxy показывают реальный SQL с параметрами, статистика Hibernate считает запросы за транзакцию. Главный источник бед это N+1 от ленивых коллекций, лечится JOIN FETCH, @EntityGraph и @BatchSize, пакетная запись включается hibernate.jdbc.batch_size.

Дальше про решения: индекс под условие и сортировку, покрывающий индекс с INCLUDE, переписанный запрос вместо подзапроса в SELECT, свежая статистика (ANALYZE, default_statistics_target), пагинация по ключу вместо больших OFFSET, материализованное представление под тяжёлый отчёт.

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

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

Называют EXPLAIN без ANALYZE и не различают предполагаемое число строк и фактическое. Именно расхождение этих двух чисел обычно и объясняет плохой план.

Вешают индексы на каждую колонку из WHERE. Индексы замедляют запись, раздуваются, и половина из них не используется, потому что колонка обёрнута функцией или типы в сравнении не совпали.

Не видят N+1, потому что в коде это одна строка обхода коллекции, а в логах пятьсот запросов. Без включённого логирования SQL такое просто не заметно.