Как обнаружить «тяжёлые» SQL-запросы без готовых метрик?

Как обнаружить "тяжёлые" SQL-запросы без готовых метрик?

• анализ журналов СУБД (slow query log, general log)
• исследование плана выполнения с помощью EXPLAIN и EXPLAIN ANALYZE
• выявление запросов с большим временем выполнения или блокировками
• отслеживание блокировок и ожиданий, возникающих во время транзакций
• применение системных представлений (pg_stat_statements, sys.dm_exec_query_stats)
• обнаружение полнотабличных сканирований (Seq Scan) и отсутствующих индексов
• поиск регулярно повторяющихся ресурсоёмких запросов по их тексту и статистике планов

Подробный ответ

Основной ответ

Обнаружение "тяжёлых" SQL-запросов без готовых метрик сводится к анализу доступных журналов и системных средств СУБД. Нужно найти запросы, которые по фактическим наблюдениям заметно расходуют ресурсы — CPU, I/O или время выполнения. На практике для этого используют логирование медленных запросов, изучают планы выполнения и отслеживают блокировки.

Ключевые моменты

• Логирование медленных запросов: большинство СУБД, включая PostgreSQL и MySQL, позволяют записывать запросы, выполнение которых превышает заданный порог, например slow query log с threshold 1с. При отсутствии метрик это наиболее практичный способ определить долго выполняющиеся запросы по их времени выполнения.
• EXPLAIN / EXPLAIN ANALYZE: для подозрительного запроса вручную рассматривают план выполнения и находят узкие места — полное сканирование таблицы, отсутствие индексов или затратные соединения. Такой анализ позволяет оценить, какие операции делают запрос потенциально тяжёлым.
• Вспомогательные системные инструменты: наблюдение за активностью через pg_stat_activity (PostgreSQL) и SHOW PROCESSLIST (MySQL) показывает запросы в реальном времени и помогает сопоставить их по длительности выполнения и нагрузке. Так можно обнаружить текущие "тяжёлые" запросы даже без метрик.
• Анализ блокировок и ожиданий: продолжительные блокировки и ожидание ресурсов сигнализируют о проблемных запросах, способных ухудшать производительность всей системы.

Практический контекст

В рабочих проектах нередко включают slow query log с порогом 500-1000 мс, а затем разбирают журнал с помощью линейных скриптов или автоматизированных средств, например pt-query-digest. Для агрегированного анализа в PostgreSQL администраторы также применяют pg_stat_statements, однако при отсутствии метрик главным источником остаются журналирование и live-снятие состояния.

Итак, даже без заранее собранных метрик стандартные возможности СУБД позволяют регулярно находить и оптимизировать тяжёлые запросы, повышая производительность и стабильность системы.