SQL Server e CPU alta: como investigar

CPU alta no SQL Server quase sempre tem uma causa concentrada — uma query específica, um job, ou um conjunto pequeno de sessões — não é "o servidor está sobrecarregado" de forma difusa. Achar o concentrador é o primeiro passo, antes de pensar em adicionar core.

Quem está consumindo CPU agora

SELECT TOP 10
  qs.total_worker_time / qs.execution_count AS avg_cpu_us,
  qs.execution_count, qs.total_worker_time,
  SUBSTRING(qt.text, qs.statement_start_offset/2 + 1,
    (CASE WHEN qs.statement_end_offset = -1
      THEN LEN(CONVERT(nvarchar(max), qt.text)) * 2
      ELSE qs.statement_end_offset END - qs.statement_start_offset)/2 + 1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY qs.total_worker_time DESC;

total_worker_time é o tempo de CPU acumulado (não elapsed time, que inclui espera). Ordenar por ele isola quem realmente consome processador, diferente da query anterior focada em tempo total percebido.

Se não for uma query específica

• SQL Agent Jobs — index rebuild, estatística, ETL agendado coincidindo com horário de pico da aplicação.
• CXPACKET/CXCONSUMER alto junto com CPU alta — paralelismo excessivo, geralmente MAXDOP sem limite numa instância com muitos cores.
• Compilação de plano repetida — queries ad-hoc sem parametrização geram compile a cada execução, o que consome CPU sem aparecer como "execução lenta".
• Antivírus ou backup de terceiros escaneando os arquivos do SQL Server durante a operação normal do banco.

O codeDB acompanha o consumo de CPU por instância e por query ao longo do tempo, então um job que passou a rodar mais devagar ou uma query que começou a consumir mais CPU depois de um deploy aparece como anomalia, não como reclamação de usuário três dias depois.