¿Cómo investigas un deadlock de base de datos?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Un deadlock son dos o más transacciones esperando cada una un lock que la otra tiene, y el motor lo rompe matando una, lo que aparece como error en la aplicación. La investigación parte del grafo de deadlock que registra el motor: nombra las transacciones, las sentencias que ejecutaban, los recursos bloqueados y deseados y cuál fue elegida como víctima. A partir de ahí se identifican las rutas de código en conflicto y se compara el orden de adquisición. Los arreglos son estructurales: adquirir recursos en el mismo orden en todas partes, acortar transacciones para retener locks poco tiempo, añadir índices para que las actualizaciones bloqueen solo las filas previstas, o bajar el aislamiento donde el invariante lo permite. Reintentar la víctima es un parche que solo ayuda si los deadlocks son raros y la transacción es idempotente.

Ejemplo

El log de deadlock mostró la transacción A actualizando orders y luego order_items, y la transacción B, una actualización masiva de precios, tocando order_items y luego orders. El job masivo se cambió para bloquear orders primero en el mismo orden que la ruta de checkout, su tamaño de lote se redujo de 50.000 a 1.000 filas y los deadlocks pasaron de decenas al día a cero. Un reintento con backoff se mantuvo en la ruta de checkout para el caso raro.

Errores frecuentes

• Envolver todo en bucles de reintento en lugar de leer el grafo de deadlock.
• Subir el timeout de lock, lo que convierte deadlocks en esperas largas.
• Suponer que la transacción víctima era la culpable.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.