Wait Stats no SQL Server: como interpretar os principais tipos

Toda vez que uma sessão do SQL Server não está usando CPU ativamente, ela está esperando por alguma coisa — disco, memória, outro lock, rede. O SQL Server registra o tempo total gasto em cada tipo de espera desde o último restart (ou reset manual) em sys.dm_os_wait_stats. Isso é o dado mais valioso pra entender por que o servidor está lento, porque mostra a causa agregada, não só o sintoma pontual.

Como ler a tabela sem se perder

SELECT TOP 15
  wait_type, wait_time_ms, waiting_tasks_count,
  wait_time_ms * 1.0 / NULLIF(waiting_tasks_count, 0) AS media_ms
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('SLEEP_TASK','BROKER_TASK_STOP','CLR_SEMAPHORE','LAZYWRITER_SLEEP','XE_TIMER_EVENT')
ORDER BY wait_time_ms DESC;

A lista de exclusão importa: boa parte dos wait types com maior tempo acumulado são internos do SQL Server (threads dormindo esperando trabalho) e não indicam problema nenhum. Filtrar esses de saída é o primeiro passo pra não perseguir fantasma.

Os tipos que mais aparecem em produção

• PAGEIOLATCH_SH / PAGEIOLATCH_EX — esperando ler ou escrever uma página de dados no disco. Alto e constante indica gargalo de I/O.
• CXPACKET / CXCONSUMER — coordenação entre threads paralelos de uma mesma query. Não é ruim por padrão; vira sintoma quando junto de estatística desatualizada ou MAXDOP mal ajustado.
• RESOURCE_SEMAPHORE — fila esperando memory grant pra sort/hash. Sinal direto de pressão de memória.
• LCK_M_* — esperando lock de outra sessão. É blocking, não wait de recurso físico.
• WRITELOG — esperando o log de transação confirmar no disco. Alto costuma apontar pro storage do log, não pro banco em si.
• ASYNC_NETWORK_IO — o SQL Server terminou de gerar o resultado e está esperando a aplicação consumir. Raramente é o servidor; geralmente é rede lenta ou aplicação processando devagar linha a linha.

Wait alto não é sempre problema

O número absoluto isolado não diz muito — um servidor rodando há 60 dias acumula muito mais wait_time_ms que um que reiniciou ontem. O que importa é a proporção entre os tipos (qual domina o total) e a tendência ao longo do tempo, não o valor absoluto de um snapshot único.

O codeDB acompanha os wait stats de cada instância ao longo do tempo automaticamente, então dá pra ver a tendência (crescendo, estável, pico isolado) sem precisar guardar snapshot manual toda vez que alguém pergunta "isso é normal?".