SQL Server lento? 7 causas e soluções

“O sistema está lento.” Essa frase chega ao TI todos os dias em muitas empresas. Na maioria das vezes, a culpa recai sobre a rede, o servidor ou o próprio sistema. Mas, quando você investiga com método, uma parte grande desses casos leva ao mesmo lugar: o banco de dados.

Neste artigo, reuni as 7 causas mais comuns de SQL Server lento que encontro em ambientes reais e como diagnosticar cada uma, sem achismo.

Antes de tudo: meça, não adivinhe

O erro mais caro em performance é sair trocando configurações ou comprando hardware sem saber onde está o gargalo. Antes de qualquer mudança, colete evidências:

• Wait statistics (sys.dm_os_wait_stats): mostram em que o SQL Server está esperando.
• Query Store: histórico de consultas, tempos e mudanças de plano de execução.
• DMVs de execução (sys.dm_exec_query_stats): as consultas que mais consomem recursos.
• Sessões ativas e bloqueios (sys.dm_exec_requests): o que está rodando agora e quem está bloqueando quem.

1. Índices ausentes ou mal planejados

Sem o índice adequado, o SQL Server precisa ler a tabela inteira (table scan) para encontrar poucas linhas. Em tabelas pequenas ninguém percebe. Com milhões de registros, a consulta que levava milissegundos passa a levar segundos.

Como resolver: analise os planos de execução das consultas mais pesadas e crie índices com base no uso real. Cuidado com as sugestões automáticas de “missing index”: elas ajudam, mas aplicadas sem critério geram índices duplicados e deixam as gravações mais lentas.

2. Estatísticas desatualizadas

O otimizador do SQL Server decide como executar cada consulta com base em estatísticas sobre a distribuição dos dados. Se elas estão desatualizadas, ele escolhe planos ruins, como fazer um loop sobre milhões de linhas achando que são cem.

Como resolver: mantenha uma rotina de atualização de estatísticas, especialmente em tabelas que recebem cargas grandes.

3. Bloqueios (blocking) e deadlocks

Quando uma transação longa segura um recurso, todas as outras que precisam dele ficam esperando. Para o usuário, a tela simplesmente “congela”.

Como resolver: identifique a sessão que está no topo da cadeia de bloqueio, reduza o tamanho das transações, revise o nível de isolamento e avalie o uso de Read Committed Snapshot Isolation (RCSI) quando fizer sentido para a aplicação.

4. Memória mal configurada

Por padrão, o SQL Server tenta usar toda a memória disponível. Se o max server memory não está configurado, ele pode disputar memória com o sistema operacional e outras aplicações. No outro extremo, servidores com pouca memória obrigam o banco a ler do disco o tempo todo.

Como resolver: configure a memória máxima deixando uma margem para o sistema operacional e acompanhe indicadores como Page Life Expectancy e esperas de memória.

5. Disco lento ou TempDB mal configurado

Esperas como PAGEIOLATCH e WRITELOG indicam que o armazenamento não está acompanhando. O TempDB, usado para ordenações, tabelas temporárias e versionamento, é um ponto clássico de gargalo.

Como resolver: separe dados, log e TempDB quando possível, configure vários arquivos de dados para o TempDB e acompanhe a latência de leitura e gravação por arquivo (sys.dm_io_virtual_file_stats).

6. Consultas mal escritas

Alguns padrões derrubam a performance mesmo com bons índices:

• Funções aplicadas sobre colunas no WHERE (ex.: WHERE YEAR(data) = 2026).
• SELECT * trazendo colunas desnecessárias.
• Conversões implícitas de tipo de dado.
• Cursores e loops onde caberia uma operação em conjunto.
• Consultas geradas por ORM sem revisão.

Como resolver: reescrever as consultas mais pesadas costuma trazer ganhos maiores do que qualquer troca de hardware. Esse é um trabalho conjunto entre DBA e equipe de desenvolvimento.

7. Parallelism e configurações padrão

As configurações de MAXDOP e cost threshold for parallelism, quando ficam no padrão, podem fazer consultas simples usarem paralelismo à toa, gerando esperas do tipo CXPACKET/CXCONSUMER e disputa de CPU.

Como resolver: ajuste essas configurações de acordo com o número de núcleos e o perfil de carga, sempre medindo antes e depois.

Por que comprar mais hardware raramente resolve

Aumentar CPU e memória pode aliviar o sintoma por algum tempo, mas uma consulta sem índice continua lendo a tabela inteira, só que um pouco mais rápido. Em licenciamento do SQL Server, que é cobrado por núcleo, ou na nuvem, onde se paga por recurso, mais hardware significa custo recorrente maior. Otimizar primeiro quase sempre sai mais barato.

Como trabalhamos a performance na FABRIDATA

1. Coleta de evidências (esperas, consultas, planos, configurações).
2. Identificação das poucas consultas e configurações que causam a maior parte do problema.
3. Correções priorizadas, testadas e documentadas.
4. Medição antes e depois, para mostrar o ganho real.
5. Acompanhamento contínuo, para que o problema não volte.

Perguntas frequentes

É possível otimizar sem mexer no sistema?

Em muitos casos, sim. Índices, estatísticas e configurações da instância são ajustes no banco que não exigem alteração no código da aplicação.

Atendem sistemas de terceiros, como ERPs?

Sim. Mesmo quando não é possível alterar o código, há bastante espaço para ganho em índices, manutenção e configuração.