База данных тормозит

Симптом

Замедление всего приложения; запросы выполняются намного дольше обычного, пользователи жалуются.

1. Сначала уточните, что именно медленно

Медленно всё или конкретный запрос/экран? Когда началось и совпадает ли с деплоем/патчем/ростом данных? Проблема на всей системе или в одной БД? Это сужает поиск до одной оси: CPU, I/O, блокировки или смена плана.

2. Посмотрите активные сессии и wait events

Что выполняется и что ожидает прямо сейчас? Доминирующий wait event (I/O, блокировка, журнал) указывает на узкое место.

Oracle

SELECT sid, username, status, event, sql_id FROM v$session WHERE status='ACTIVE' AND type='USER';

PostgreSQL

SELECT pid, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state='active';

MySQL

SELECT id, user, command, time, state, info FROM information_schema.processlist WHERE command<>'Sleep' ORDER BY time DESC;

SQL Server

SELECT session_id, status, wait_type, wait_time, blocking_session_id FROM sys.dm_exec_requests WHERE session_id IN (SELECT session_id FROM sys.dm_exec_sessions WHERE is_user_process = 1);

MongoDB

db.currentOp({ active: true, secs_running: { $gt: 1 } })

Redis

SLOWLOG GET 10

3. Проверьте блокировки

Самая частая причина замедления — одна сессия блокирует другие. Найдите блокирующую сессию и определите голову цепочки.

Oracle

SELECT blocking_session, sid, seconds_in_wait, event FROM v$session WHERE blocking_session IS NOT NULL;

PostgreSQL

SELECT pid, pg_blocking_pids(pid) AS blocked_by, query FROM pg_stat_activity WHERE cardinality(pg_blocking_pids(pid))>0;

MySQL

SELECT * FROM sys.innodb_lock_waits\G

SQL Server

SELECT session_id, blocking_session_id, wait_type FROM sys.dm_exec_requests WHERE blocking_session_id<>0;

4. Найдите самые дорогие запросы

Найдите 10 запросов, потребляющих больше всего ресурсов. Обычно 90% проблемы дают несколько запросов.

Oracle

SELECT sql_id, elapsed_time/1e6 sec, executions, sql_text FROM v$sql ORDER BY elapsed_time DESC FETCH FIRST 10 ROWS ONLY;

PostgreSQL

SELECT calls, total_exec_time, mean_exec_time, query FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

MySQL

SELECT digest_text, count_star, sum_timer_wait/1e12 sec FROM performance_schema.events_statements_summary_by_digest ORDER BY sum_timer_wait DESC LIMIT 10;

SQL Server

SELECT TOP 10 total_elapsed_time/execution_count avg_us, execution_count, SUBSTRING(t.text,1,200) FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) t ORDER BY total_elapsed_time DESC;

5. Изучите план подозрительного запроса

Получите EXPLAIN для медленного запроса. Ищите полные сканирования таблиц, отсутствующие индексы, неудачный порядок соединений или устаревшую статистику. Если план внезапно изменился, рассмотрите сбор статистики.

Oracle

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('&sql_id', NULL, 'ALLSTATS LAST'));

PostgreSQL

EXPLAIN (ANALYZE, BUFFERS) <query>;

MySQL

EXPLAIN ANALYZE <query>;

SQL Server

SET STATISTICS PROFILE ON; <query>; SET STATISTICS PROFILE OFF;

MongoDB

db.my_collection.find({...}).explain('executionStats')  // COLLSCAN or IXSCAN?

6. Проверьте системные ресурсы

На уровне ОС проверьте CPU, ожидание I/O (iowait), память и использование диска. Проверьте cache hit ratio; если он низкий, возможна нехватка памяти. Проблема может быть вне БД (заполненный диск, шумная соседняя VM).

7. Решите: быстрое или постоянное исправление

Для немедленного облегчения: завершите вышедший из-под контроля запрос, добавьте отсутствующий индекс, соберите статистику. Для постоянного решения: переработайте запрос/индекс, исправьте настройки памяти, обеспечьте стабильность плана (baseline/hint).