Performance não se resolve com uma lista aleatória de índices. Um diagnóstico confiável conecta impacto para o usuário, comportamento das consultas, pressão sobre recursos e mudanças recentes no ambiente.
Comece delimitando o problema
Registre quando a lentidão começou, quais telas ou rotinas foram afetadas, em que horários ocorre e qual era o tempo esperado. “O banco está lento” é amplo demais; “o fechamento passou de 4 para 18 minutos após a última carga” é uma hipótese investigável.
Compare o período ruim com uma linha de base saudável. Mudanças de volume, versão, infraestrutura, estatísticas ou parâmetros podem explicar regressões que não aparecem olhando apenas o estado atual.
Leia as esperas antes de aumentar recursos
As wait stats ajudam a entender onde o SQL Server passa tempo. Pressão de CPU, leitura física, bloqueios, memória e sincronização produzem sinais diferentes e exigem respostas diferentes.
A análise deve considerar o intervalo do incidente, não apenas acumulados desde a última inicialização. Caso contrário, problemas antigos podem dominar a amostra e levar a conclusões erradas.
- CPU elevada: investigar consultas consumidoras e paralelismo.
- Leitura elevada: revisar planos, índices, volume e memória disponível.
- Bloqueios: localizar sessão bloqueadora e duração das transações.
- TempDB: observar contenção, crescimento e operações de spill.
Priorize consultas pelo custo para o negócio
A consulta mais lenta nem sempre é a mais importante. Uma consulta de dois segundos executada milhares de vezes pode consumir mais recursos do que um relatório de vinte segundos usado uma vez ao dia.
Combine duração, CPU, leituras lógicas, frequência e criticidade. Query Store é especialmente útil para comparar planos, identificar regressões e entender variações ao longo do tempo.
Revise o plano sem tratar índice como resposta automática
Verifique estimativas de cardinalidade, operações mais caras, conversões implícitas, lookups repetitivos, spills e diferenças grandes entre linhas estimadas e reais. Um índice pode ajudar, mas também aumenta custo de escrita e manutenção.
Correções frequentes incluem reescrita da consulta, atualização de estatísticas, ajuste do modelo, redução do conjunto processado e criação criteriosa de índices compostos ou filtrados.
Valide a correção e proteja o ambiente
Toda alteração deve ter métrica de antes e depois. Meça tempo, CPU, leituras e impacto nas rotinas concorrentes. Faça testes com volume representativo e tenha plano de reversão.
Depois do incidente, transforme o aprendizado em monitoramento: consultas críticas, bloqueios prolongados, crescimento de arquivos, falhas de jobs e tendência de capacidade.
O melhor diagnóstico é reproduzível: define o sintoma, coleta evidências, testa uma hipótese e mede o resultado. Esse método evita mudanças arriscadas e cria um histórico útil para capacidade, arquitetura e prevenção.