Deadlock no SQL Server: o que é, como detectar e prevenir

Deadlock acontece quando duas (ou mais) sessões travam recursos em ordem cruzada: a sessão A tem o recurso X e quer o Y; a sessão B tem o Y e quer o X. Nenhuma consegue avançar. O SQL Server detecta o ciclo automaticamente (Lock Monitor, a cada ~5 segundos) e mata uma das duas sessões — a "vítima" — pra destravar a outra.

Capturando o gráfico de deadlock

A forma mais simples de capturar deadlocks sem configurar nada é o system_health, uma Extended Events session que já roda por padrão em toda instância:

SELECT
  xed.value('@timestamp', 'datetime2') AS quando,
  xed.query('.') AS deadlock_graph
FROM (
  SELECT CAST(target_data AS xml) AS target_data
  FROM sys.dm_xe_session_targets st
  JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address
  WHERE s.name = 'system_health' AND st.target_name = 'ring_buffer'
) AS data
CROSS APPLY target_data.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS x(xed);

O resultado é um XML — abrindo no SSMS ele vira o gráfico visual clássico, com cada processo, o recurso que segura e o que espera.

O que geralmente causa deadlock

• Duas transações acessando as mesmas tabelas em ordem diferente (transação A: tabela X depois Y; transação B: Y depois X).
• Índices ausentes forçando table/index scan em vez de seek — a transação segura muito mais linhas do que precisaria, aumentando a chance de colisão.
• Transações longas demais, aumentando a janela de tempo em que os locks ficam ativos.
• Nível de isolamento mais restritivo que o necessário (SERIALIZABLE onde READ COMMITTED bastaria).

Como prevenir

• Padronize a ordem de acesso às tabelas em transações que mexem em mais de uma (sempre a mesma ordem, em todo o código).
• Adicione os índices que faltam — isso sozinho resolve boa parte dos deadlocks porque reduz o número de linhas bloqueadas.
• Mantenha transações curtas: comece o BEGIN TRAN o mais tarde possível e dê COMMIT o mais cedo possível.
• Considere READ COMMITTED SNAPSHOT (RCSI) pra leitura não bloquear escrita, se o padrão de acesso permitir.

Deadlock esporádico é normal em qualquer sistema com concorrência — o problema é quando vira padrão recorrente e ninguém percebe até o usuário reclamar. O codeDB captura o gráfico de deadlock automaticamente e mantém o histórico, então dá pra ver se é um caso isolado ou a mesma dupla de queries brigando toda hora.