CXPACKET e paralelismo: quando é normal e quando é sintoma

CXPACKET (e o mais recente CXCONSUMER, que substitui parte dos casos em versões novas) é o wait que aparece quando o SQL Server divide uma query entre vários threads em paralelo e alguns terminam antes dos outros — o thread mais rápido espera o mais lento. Ver esse wait no topo da lista não é, por si só, sinal de problema: é o preço normal de usar paralelismo.

Quando é só o paralelismo funcionando

Query de relatório grande, agregação pesada, index rebuild — tudo isso se beneficia de paralelismo e vai gerar CXPACKET proporcional ao tempo que a query roda. Alto em queries que são naturalmente pesadas não é o alvo de investigação.

Quando vira sintoma de outra coisa

• CXPACKET alto em queries pequenas/simples que não deveriam paralelizar → geralmente estatística desatualizada fazendo o otimizador superestimar o custo e decidir paralelizar sem necessidade.
• MAXDOP não configurado (usando todos os cores disponíveis) numa instância com muita concorrência → mais queries brigando por mais threads do que o servidor tem.
• Cost Threshold for Parallelism no padrão de fábrica (5) — baixo demais pra hardware moderno, faz até query barata qualificar pra paralelismo.

SELECT name, value, value_in_use
FROM sys.configurations
WHERE name IN ('max degree of parallelism', 'cost threshold for parallelism');

Não existe valor universal de MAXDOP correto — depende do número de cores, NUMA e do padrão de carga (OLTP se beneficia de MAXDOP mais restrito; data warehouse se beneficia de mais paralelismo). O ponto é revisar se o valor atual foi uma decisão deliberada ou só o padrão que ninguém mexeu.