• Резкое возрастание времени ответа API и загрузки процессоров сервера баз данных.
• Ошибочный выбор плана планировщиком (выбор медленного Sequential Scan вместо Index Scan).
• Существенное расхождение между предполагаемым количеством строк (rows=...) и фактическим (actual rows=...).

1. Получение полного аналитического плана запроса

EXPLAIN (ANALYZE, BUFFERS, SETTINGS, WAL)
SELECT o.id, o.total_amount, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'COMPLETED'
  AND o.created_at >= '2023-11-01';

2. Ключевые маркеры проблем в плане EXPLAIN:

• Seq Scan on table_name: полное сканирование таблицы. Требуется создание B-Tree / BRIN индекса.
• Rows Removed by Filter: 1500000: прочитаны миллионы лишних страниц, индекс отсутствует или не покрывает условия.
• Buffers: shared hit=12 read=45021: read указывает на физическое чтение медленного диска, hit — чтение из RAM.
• Sort Method: external merge Disk: нехватка памяти work_mem для сортировки в памяти.

3. Устранение расхождений статистики планировщика

Если планировщик ошибается в оценке строк из-за устаревшей статистики:

-- Принудительный сбор свежей статистики
ANALYZE orders;

-- Увеличение детализации гистограммы для проблемной колонки
ALTER TABLE orders ALTER COLUMN status SET STATISTICS 500;
ANALYZE orders;

4. Включение расширения pg_stat_statements для профилирования

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- Топ-5 запросов по суммарному времени выполнения
SELECT query, calls, total_exec_time, mean_exec_time, rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC LIMIT 5;