O banco está lento

Sintoma

Lentidão em toda a aplicação; as consultas demoram muito mais que o normal e os usuários estão reclamando.

1. Primeiro, esclareça o que exatamente está lento

Está tudo lento ou uma consulta/tela específica? Quando começou, e coincide com um deploy/patch/crescimento de dados? Afeta o sistema todo ou um único banco? Isso restringe a busca a um eixo: CPU, I/O, lock ou mudança de plano.

2. Veja as sessões ativas e os wait events

O que está rodando e o que está esperando agora? Um wait event dominante (I/O, lock, log) aponta o gargalo.

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. Verifique bloqueios

A causa mais comum de lentidão é uma sessão bloqueando outras. Encontre a sessão bloqueadora e identifique o início da cadeia.

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. Levante as consultas mais caras

Encontre as 10 consultas que mais consomem recursos. Geralmente 90% do problema vem de um punhado de consultas.

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. Examine o plano da consulta suspeita

Obtenha o EXPLAIN da consulta lenta. Procure full table scans, índices ausentes, ordem de join ruim ou estatísticas desatualizadas. Se o plano mudou de repente, considere coletar estatísticas.

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. Verifique os recursos do sistema

No nível do SO, verifique CPU, espera de I/O (iowait), memória e uso de disco. Verifique o cache hit ratio; se estiver baixo, pode haver um gargalo de memória. O problema pode estar fora do banco (disco cheio, VM vizinha barulhenta).

7. Decida: correção rápida ou definitiva

Para alívio imediato: mate a consulta descontrolada, crie o índice ausente, colete estatísticas. Para uma correção definitiva: redesenhe a consulta/índice, corrija as configurações de memória, garanta a estabilidade do plano (baseline/hint).