Как определить, что запрос в базе тормозит

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

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

Как отвечать

Идите от симптома к причине, по слоям:

• метрики приложения: Spring Boot Actuator с Micrometer даёт время запросов и метрики пула HikariCP. Рост hikaricp.connections.pending значит, что потоки ждут соединение, а не выполнение SQL;
• трассировка: OpenTelemetry Java agent показывает спаны JDBC внутри запроса пользователя, и видно, какой SQL съел время;
• логирование со стороны Java: datasource-proxy или p6spy пишут SQL с длительностью, у Hibernate есть логирование запросов медленнее заданного порога. Здесь же ловится N+1, когда медленный не один запрос, а сотня быстрых;
• база, PostgreSQL: log_min_duration_statement пишет в лог всё, что дольше порога, pg_stat_statements даёт суммарное и среднее время по нормализованным запросам, pg_stat_activity показывает текущие запросы, их wait_event и сессии idle in transaction. Для MySQL это slow query log и performance_schema;
• план: EXPLAIN (ANALYZE, BUFFERS) на реальных параметрах. Смотрите на Seq Scan по большой таблице, расхождение оценки строк с фактом, Nested Loop по тысячам строк, сортировку на диск.

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

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

Сразу предлагают «добавить индекс», не посмотрев план. Часто проблема в N+1 или в блокировке, и индекс ничего не изменит.

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

Не отделяют время в базе от времени в приложении. Запрос в базе выполняется за 5 мс, а в Java занимает секунду, потому что поток полсекунды ждёт свободное соединение.