Перейти на PRO

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

Тип вопроса: Базы данных Вероятность: 10% Категория: Golang Разработчик

Ответ

Анализ медленных запросов — это итеративный процесс, состоящий из поиска "кандидатов" и их детального изучения.

Общий подход:

  1. Включить логирование/мониторинг: Настроить БД на отслеживание запросов, превышающих определенный порог времени.
  2. Найти медленные запросы: Изучить логи или статистику, чтобы определить самые ресурсоемкие запросы.
  3. Проанализировать план выполнения: Для найденного запроса использовать команду EXPLAIN ANALYZE, чтобы понять, как именно БД его выполняет и где узкое место.

Инструменты для конкретных БД:

PostgreSQL

  1. Логирование медленных запросов: В postgresql.conf установите log_min_duration_statement = '200ms'. Все запросы дольше 200 мс будут попадать в лог.

  2. Расширение pg_stat_statements: Это мощный инструмент для сбора агрегированной статистики по всем запросам. Идеально для поиска самых "дорогих" запросов в целом.

    -- Необходимо один раз включить расширение
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- Посмотреть топ-5 запросов по среднему времени выполнения
SELECT
    (total_exec_time / 1000) as total_time_ms, -- Общее время в мс
    calls, -- Количество вызовов
    (mean_exec_time / 1000) as mean_time_ms, -- Среднее время в мс
    query -- Текст запроса
FROM pg_stat_statements
ORDER BY mean_time_ms DESC
LIMIT 5;
  3. Анализ плана (EXPLAIN ANALYZE): Это главный инструмент для анализа конкретного запроса. Он выполняет запрос и показывает реальный план с фактическим временем и количеством строк. 
    EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';

    На что смотреть: Seq Scan (полный перебор таблицы) вместо Index Scan, неверные оценки количества строк (rows).

MySQL

  1. Slow Query Log: Аналог логгирования в PostgreSQL. Включается в конфигурации или командой: 
    -- Включить лог медленных запросов
SET GLOBAL slow_query_log = 'ON';
-- Установить порог в 1 секунду
SET GLOBAL long_query_time = 1;
  2. Команда EXPLAIN: Показывает план выполнения запроса. В отличие от EXPLAIN ANALYZE в PostgreSQL, она не выполняет запрос, а только строит предполагаемый план.

Внешние утилиты:

  • pgBadger: Генератор отчетов для логов PostgreSQL.
  • pt-query-digest: Инструмент из Percona Toolkit для анализа логов MySQL.
  • Системы мониторинга: Datadog, New Relic, Prometheus+Grafana часто имеют встроенные инструменты для анализа производительности БД.

Ответ 18+ 🔞

Да ты посмотри, что творят с базами данных, блядь! Анализ медленных запросов — это как разбор полётов после того, как сервак накрылся медным тазом. Процесс итеративный, сука, то есть по кругу ходишь, пока не найдёшь того самого пидораса-запрос, который всё тормозит.

Как обычно действуют:

  1. Включить слежку, блядь: Настраиваешь базу, чтобы она стучала на все запросы, которые дольше какого-то порога болтаются. Типа, «всё, что дольше 200 мс — в журнал, падла!».
  2. Найти виновных: Копаешься в этих логах или статистике, выискивая самых прожорливых уёбков.
  3. Устроить допрос с пристрастием: Берёшь найденного кандидата и применяешь EXPLAIN ANALYZE, чтобы понять, на каком именно этапе он, сука, бутылочное горлышко создаёт.

Инструменты для разных баз:

PostgreSQL

  1. Логирование, как в КГБ: Лезешь в postgresql.conf, ставишь log_min_duration_statement = '200ms'. И всё, блядь — любой запрос, который дольше 200 мс тупит, теперь у тебя на карандаше.

  2. Расширение pg_stat_statements: Вот это, ёпта, настоящая палочка-выручалочка! Оно собирает статистику по всем запросам, чтобы ты мог найти главных пожирателей ресурсов.

    -- Включаешь один раз и забываешь
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- А потом смотришь топ-5 самых тормозных ублюдков
SELECT
    (total_exec_time / 1000) as total_time_ms, -- Общее время в мс
    calls, -- Сколько раз вызывали
    (mean_exec_time / 1000) as mean_time_ms, -- Среднее время в мс
    query -- Сам текст запроса, этот шедевр
FROM pg_stat_statements
ORDER BY mean_time_ms DESC
LIMIT 5;
  3. Разбор полётов (EXPLAIN ANALYZE): Это, блядь, священный грааль! Берёшь конкретный запрос и заставляешь его рассказать всю подноготную. 
    EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';

    На что глазеть: если видишь Seq Scan (это полный перебор таблицы, ёбта!) вместо Index Scan, или цифры по строкам (rows) вообще с потолка взяты — вот тебе и корень зла.

MySQL

  1. Slow Query Log: Почти то же самое. Включаешь и говоришь: «Всё, что дольше секунды — пиши, сволочь!». 
    SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
  2. Команда EXPLAIN: Показывает план, но, в отличие от Постгреса, запрос не выполняет. Так, предварительный просмотр, блядь.

Внешние штуки, которые помогут:

  • pgBadger: Генератор отчётов из логов Постгреса. Красиво, наглядно, пиздато.
  • pt-query-digest: Из перконовского набора, для разбора логов MySQL.
  • Системы мониторинга: Datadog, New Relic и прочая хуйня — у них часто свои встроенные костыли для этого есть.
© ХакСобесов, 2026
support@hacksobesov.com