Contención de locks en bases de datos: arregla tablas calientes y esperas de locks rápido

Cómo se ve la contención de locks en términos sencillos

Un lock de base de datos es como un cartel de reservado sobre una fila o tabla. Mientras una solicitud cambia datos, la base de datos puede bloquear a otras solicitudes para que no cambien los mismos datos al mismo tiempo. Algunas operaciones aún pueden leer; otras deben esperar, dependiendo de la base de datos y del tipo de lock.

La contención de locks sucede cuando esa fila de espera se alarga. La base de datos no está “caída”. Está obligando a las solicitudes a turnarse.

Esto suele centrarse en una tabla caliente: una tabla que recibe escrituras constantemente. Ejemplos comunes son una tabla de orders durante el checkout, una tabla de sesiones que se actualiza en cada vista de página, o una tabla de contadores usada para generar números secuenciales.

Lo que sienten los usuarios es frustración e inconsistencia. Páginas que normalmente cargan en 200 ms de pronto tardan 10 a 30 segundos y luego se recuperan. Los jobs en segundo plano parecen atascados. Ves timeouts, reintentos y a veces una oleada de errores que desaparece antes de que alguien pueda reproducirla.

Puede parecer lentitud aleatoria porque los servidores pueden parecer bien. La CPU no está al máximo, la memoria es estable y el tiempo medio de consulta puede incluso parecer normal. Pero durante los picos, unas pocas escrituras bloqueadas pueden causar un embotellamiento, y todo lo que necesita las mismas filas o tabla termina esperando.

Por qué las tablas calientes se vuelven cuellos de botella

Una tabla caliente es una tabla que muchas solicitudes tocan al mismo tiempo, a menudo en las mismas filas. Cuando muchas sesiones intentan actualizar los mismos datos, la base de datos tiene que encolarlas. Esa cola es lo que la gente experimenta como contención: las páginas cargan, se quedan colgadas y luego terminan de golpe.

El disparador más común es un volumen alto de escrituras concentrado en un punto. Una tabla enorme puede estar bien si las escrituras se distribuyen. Una tabla pequeña puede ser peor si cada petición la alcanza, como una sola fila que almacena un contador global, el “último número de factura” o un flag de estado compartido.

Los puntos calientes suelen venir de los mismos patrones:

• Una fila que todos actualizan (contadores, ajustes globales)
• Bucles de leer-modificar-escribir sobre los mismos registros
• Diseños “upsert para todo” donde se esperan conflictos
• Jobs en segundo plano que tocan las mismas filas que los usuarios
• Trabajo extra dentro de una transacción (llamadas a APIs, subidas de archivos, cálculos largos)

Las transacciones largas son especialmente dañinas porque mantienen locks mientras realizan trabajo no relacionado. Aunque la actualización en sí sea rápida, mantener la transacción abierta impide que otras sesiones avancen.

El momento también importa. Un job nocturno que recalcula totales puede ser inocuo a las 3 a. m., pero doloroso si se solapa con el tráfico pico. Los deployments también pueden empeorar esto: un cambio de esquema, un índice añadido o un nuevo trigger pueden aumentar el tiempo de cada escritura, alargando el tiempo de lock.

Ejemplo: un flujo de checkout actualiza una fila de inventario y luego llama a un proveedor de pagos antes de commitear. Si esa llamada tarda 10 segundos, todos los demás checkouts que necesitan la misma fila esperan detrás, y todo el sistema se siente atascado.

Señales rápidas de que son locks y no solo una BD lenta

Los problemas de locks se sienten como “todo está lento”, pero las señales difieren de una base de datos simplemente sobrecargada.

Separa los síntomas:

Si la CPU está al máximo y las consultas hacen mucho cómputo, probablemente estás ante consultas caras, índices faltantes o demasiado trabajo por petición. Si la CPU está normal pero las conexiones activas siguen subiendo, las solicitudes se están acumulando. Cuando además ves muchas consultas en estado de espera (no ejecutándose), la contención por locks es un sospechoso fuerte.

Un patrón clásico es un salto repentino en las latencias p95 y p99 mientras p50 se mantiene casi normal. Una solicitud golpea una fila o tabla bloqueada y espera, luego se forma una cola detrás. También puedes ver una caída del throughput aunque la CPU no esté ocupada.

Los logs suelen dar pistas tempranas: errores de timeout que aparecen en racimos, mensajes de deadlock y un número creciente de reintentos (desde tu app, workers o ORM). Si aumentaste el conteo de workers y empeoró, es otra señal de que los escritores concurrentes se están chocando.

Durante un incidente, captura un pequeño paquete de hechos para poder relacionar el pico con un lock wait específico más tarde:

• Timestamps exactos (inicio, pico, recuperación)
• Muestras de consultas lentas y sus parámetros (o equivalentes anonimizados)
• Endpoints o jobs en segundo plano más activos en ese momento
• Instantáneas de la BD: número de conexiones activas y consultas en espera
• Conteos de workers y colas (web, jobs, cron)

Ejemplo: la latencia del checkout sube de 300 ms a 20 s, la CPU se mantiene plana y las conexiones se duplican. Esa combinación suele significar “esperando”, no “trabajando”.

Cómo identificar lock waits paso a paso

Los lock waits son una forma fácil en la que la contención se oculta a simple vista. La base de datos está arriba, la CPU parece bien, pero las solicitudes se acumulan porque una transacción mantiene un lock que otros necesitan.

Paso 1: encuentra quién está bloqueado y quién está bloqueando

Arranca en las vistas de sesión y locks que trae tu base de datos (sesiones activas, tablas de locks, eventos de espera). Buscas una cadena: muchas sesiones esperando y una sesión al frente que mantiene el lock.

Un flujo de trabajo práctico:

• Lista las sesiones activas y filtra las que están esperando por locks
• Para cada sesión en espera, obtiene el id de la sesión que la bloquea
• Revisa la edad de la transacción del bloqueador (cuánto tiempo lleva abierta)
• Extrae el texto SQL de las consultas bloqueadas y las bloqueadoras
• Anota el tipo de espera y el objeto involucrado (tabla, índice, clave de fila si está disponible)

Paso 2: conecta el SQL con una acción real del usuario

El texto SQL por sí solo no es suficiente. Vincúlalo a lo que la app estaba haciendo: el nombre de un endpoint, un job en segundo plano, un worker o una tarea administrativa. Las etiquetas de consulta, el nombre de la aplicación en la conexión y los logs de peticiones/jobs ayudan.

Una comprobación útil: si la misma tabla aparece siempre y se repite el mismo rango de claves o índice, probablemente tengas un punto caliente real (por ejemplo, todos actualizan la misma fila de estado).

Paso 3: decide matar la sesión solo tras valorar el riesgo

Matar al bloqueador puede restaurar el servicio rápido, pero también puede hacer rollback de trabajo y disparar reintentos. Antes de hacerlo, confirma:

• Que realmente está atascado o muy por encima del tiempo normal de ejecución
• Que revertirlo no dejará efectos externos (emails enviados, pagos capturados)
• Que sabes qué reintentará la operación y si eso causará otro atasco

Localiza la tabla exacta, la consulta y la ruta en el código

Las ganancias más rápidas vienen de nombrar la tabla exacta, la sentencia exacta y el lugar exacto en tu app que la ejecuta. Si no, acabarás adivinando y cambiando lo equivocado.

Empieza listando cada escritura que pueda tocar la tabla sospechosa: INSERTs, UPDATEs, DELETEs y UPSERTs. No confíes en lo que la funcionalidad “debería” hacer. Extrae la información de logs, salida del ORM o estadísticas de sentencias de la BD. Las tablas calientes suelen recibir escrituras de jobs en background, peticiones web y reintentos al mismo tiempo.

Luego valida la suposición de “una fila cambiada”. Una sorpresa común es un UPDATE con una cláusula WHERE amplia (o sin índice usable) que escanea muchas filas y bloquea mucho más de lo esperado. Si los waits suben durante una actualización pequeña, verifica índices cuanto antes. Índices faltantes o equivocados pueden convertir una búsqueda rápida en un escaneo que bloquea muchas filas.

También busca locks tomados durante lecturas. Si ves SELECT ... FOR UPDATE u patrones similares, confirma que el lock es realmente necesario. Muchas apps lo añaden “por seguridad” y terminan bloqueando trabajo no relacionado.

Una forma rápida de conectar la evidencia DB con el código de la app:

• Captura el texto de la consulta bloqueadora y su edad de transacción
• Empata eso con un endpoint, nombre de job o worker en tus logs
• Confirma cuántas filas toca (estimado vs real)
• Revisa si la app reintenta en timeouts y está añadiendo más escritores
• Identifica la función o método del servicio que construye la consulta

Ejemplo: un job nocturno de limpieza ejecuta un UPDATE sin índice, tarda minutos y el checkout empieza a fallar por timeout. La BD te da la consulta y los logs te dicen qué worker la ejecutó. Arreglar el índice o acotar el WHERE suele detener el atasco rápidamente.

Reduce transacciones largas que bloquean a todos

Las transacciones largas son una de las formas más rápidas de crear contención. Mientras una transacción esté abierta, puede mantener locks en filas (y a veces más) que otras solicitudes necesitan. Si la transacción incluye trabajo lento, todos los demás esperan.

Una buena regla: dentro de la transacción solo mantén lecturas y escrituras de la base de datos. Todo lo demás debe ocurrir antes de empezar o después de commitear.

Arreglos que suelen marcar la diferencia inmediatamente incluyen mover pasos lentos fuera de la transacción (llamadas a APIs, subidas de archivos, envío de emails, generar PDFs, cálculos pesados), commitear antes cuando sea seguro y dividir actualizaciones grandes en lotes más pequeños.

Los reintentos también pueden multiplicar el problema. Si los timeouts disparan una avalancha de replays, estás añadiendo más escritores al mismo cuello de botella. Las claves de idempotencia (por ejemplo, un request id) ayudan a re-ejecutar de forma segura sin crear filas duplicadas.

Ejemplo concreto: un flujo de checkout inicia una transacción, inserta una orden, luego llama a una API de pago y envía un email de confirmación antes de commitear. Si la API de pago se queda 30 segundos, las filas de la orden permanecen bloqueadas 30 segundos. Inserta la orden rápido, commitea y luego procesa pago y email fuera de la transacción, con reglas claras de reintento.

Rediseña patrones de escritura para tablas calientes

Las tablas calientes se vuelven así porque muchas solicitudes compiten por las mismas pocas filas. A menudo puedes arreglar la contención sin cambiar hardware, modificando qué escribes, dónde lo escribes y con qué frecuencia actualizas exactamente la misma fila.

Un ejemplo común es un contador compartido (next_invoice_number o daily_signups). Cada escritura hace fila detrás del mismo lock de fila. Un patrón más seguro es mantener contadores por tenant, por usuario o por shard, y luego agregar cuando necesites un número global. La mayoría de los productos no necesita un contador global perfectamente en tiempo real.

Otra causa frecuente es actualizar la misma fila de estado repetidamente (actualizaciones de progreso, timestamps last_seen, contadores de reintentos). Si esa fila se toca en cada solicitud, terminará bloqueándose. Prefiere filas append-only (audit_log, events, status_history) y calcula el estado actual a partir del último evento, o haz rollups en background.

Algunos patrones que reducen consistentemente los waits de locks:

• Reemplazar contadores únicos por contadores por-tenant (o por-cuenta) más agregación periódica
• Usar eventos append-only en lugar de actualizar una fila una y otra vez
• Mover escrituras no críticas a una cola y actualizarlas de forma asíncrona
• Partir datos calientes por una clave estable (tenant_id, account_id) para distribuir las escrituras

Escenario concreto: el checkout escribe en una fila de inventario y además actualiza user_last_purchase, daily_sales_total y marketing_attribution dentro de la misma transacción. Bajo carga, la fila de totales compartida se vuelve el cuello de botella y bloquea también las actualizaciones de inventario. Si mantienes el cambio de inventario dentro de la transacción pero empujas totales y marketing a un job en background, el checkout sigue rápido y la fila caliente deja de bloquear a todos.

Niveles de aislamiento y alcance de locks: pequeñas elecciones, gran impacto

Los niveles de aislamiento deciden qué tan estricta es la base de datos cuando una transacción lee datos que otra está escribiendo. Niveles más estrictos pueden evitar lecturas confusas, pero suelen mantener locks más tiempo o tomar más locks para mantener la consistencia. Por eso un pequeño cambio de configuración puede transformar una pequeña cola en un incidente real.

La mayoría piensa en términos de locks por fila: “solo una fila está bloqueada”. En la práctica, algunos motores también bloquean huecos entre filas o rangos para impedir que otras transacciones inserten en ese rango mientras lees o actualizas. Un “update todo desde la fecha X hasta la Y” puede terminar bloqueando inserts para ese rango, incluso si aún no tocaste esas nuevas filas.

Patrones más seguros que suelen reducir el alcance del lock sin cambiar la lógica de negocio:

• Prefiere updates puntuales por clave primaria en lugar de updates de rango amplio
• Añade WHERE estrictas y procesa por lotes cuando debas actualizar muchas filas
• Mantén un orden consistente de acceso (por ejemplo, bloquear siempre el padre antes del hijo) para evitar deadlocks
• Vigila claves foráneas y cascadas: un delete o update puede bloquear varias tablas por más tiempo del esperado
• Evita flujos de “seleccionar y luego actualizar” que mantienen transacciones abiertas mientras la app hace trabajo extra

Los timeouts te ayudan a fallar rápido en lugar de construir un atasco. Configura timeouts de lock y de sentencias razonables para que una consulta atascada devuelva error pronto y tu app pueda reintentar o mostrar un mensaje claro.

Ejemplo: un job en background corre con un nivel de aislamiento estricto y actualiza todas las facturas impagas del mes anterior. Mantiene locks de rango mientras escanea. Al mismo tiempo, el checkout intenta insertar una nueva factura en ese rango y espera. Lotes más pequeños y un aislamiento menos estricto suelen solucionarlo.

Escenario de ejemplo: un job bloquea checkout durante 20 minutos

Una startup tiene una configuración simple: una tabla orders (caliente), un endpoint de checkout y un job en background que “mantiene los datos limpios”. En una tarde ocupada, el checkout se vuelve lentísimo. Algunos usuarios reciben timeouts, otros ven mensajes de “intenta de nuevo”.

El desencadenante es una consulta de reporte de larga ejecución que alguien corrió dentro de una transacción. Empieza con BEGIN, luego lee un gran fragmento de orders para calcular métricas. El desarrollador pensó: “es de solo lectura, así que es seguro”. Pero la transacción permanece abierta mucho tiempo, manteniendo locks más de lo esperado con el aislamiento actual.

Al mismo tiempo, un job en background empieza a actualizar miles de filas en orders (por ejemplo, para rellenar una columna nueva) durante tráfico pico. Esas actualizaciones también necesitan locks. Ahora la cola de espera crece: checkout intenta escribir una orden nueva y espera, los reintentos añaden más presión, las conexiones se amontonan y todo se siente lento.

Un giro más lo empeora: el endpoint de checkout usa un upsert tipo “insert or update”, pero la tabla no tiene el índice único correcto. La base de datos hace un escaneo para encontrar coincidencias, tocando más filas de las necesarias, así que cada escritura mantiene locks por más tiempo.

La solución cambia el comportamiento del sistema rápidamente. El reporte deja de usar una transacción larga (o se mueve a un réplica de solo lectura). El job en background pasa a lotes pequeños (por ejemplo, 500–1.000 filas) con commit tras cada lote. Y se añade el índice único faltante para que el upsert encuentre filas rápido.

Lista rápida antes de cambiar código

Antes de reescribir nada, tómate 15 minutos para confirmar que tratas con contención (no una ralentización aleatoria). Estas comprobaciones suelen señalar la causa y evitan que “arregles” lo equivocado.

Empieza por la edad de las transacciones durante el tráfico pico. Si ves transacciones abiertas más de unos pocos segundos, es una bandera roja. Las transacciones largas mantienen locks más tiempo y una sola puede hacer que consultas rápidas se formen en fila detrás.

Luego encuentra al principal bloqueador. La mayoría de las bases de datos puede mostrar qué sesión está bloqueando a otras. El mayor bloqueador suele ser algo cotidiano: un script admin, un job en background o un worker que reintenta.

Checklist para ejecutar en orden:

• Encuentra la transacción más antigua abierta en el pico y anota qué está haciendo
• Identifica la consulta bloqueadora principal y captura su SQL más la acción de la app que la desencadenó
• Verifica que los updates y deletes usen el índice esperado (la clave correcta, no un escaneo completo)
• Revisa tormentas de reintentos y timeouts faltantes
• Revisa cambios de esquema recientes (migraciones suelen disparar esto)

Ejemplo: un worker actualiza filas sin usar el índice previsto, escanea muchas filas y mantiene una transacción abierta mientras llama a una API externa. Los checkouts esperan los locks, reintentan y empeoran el amontonamiento.

Trampas comunes que hacen que la contención vuelva

La contención suele regresar porque la primera solución trata el síntoma (timeouts, deadlocks) en lugar de la causa (cómo y cuándo mantienes locks).

El error más grande es mantener una transacción abierta mientras haces algo que puede pausar. Una llamada a una API de pago, un webhook, envío de email, subida de archivos o incluso una petición lenta al cache puede congelar la transacción y mantener locks todo ese tiempo. Haz el trabajo de base de datos, commitea y luego haz el trabajo externo.

Otra trampa común son consultas de escritura grandes que tocan demasiadas filas a la vez. Un UPDATE por lotes sin limit, sin WHERE selectivo o sin el índice correcto puede bloquear un rango grande y bloquear peticiones no relacionadas.

Los deadlocks a menudo se “arreglan” añadiendo más reintentos. Los reintentos pueden ocultar el problema, pero también añaden carga y aumentan la presión de locks. Si dos rutas de código siempre pelean por las mismas filas, los reintentos solo repiten la pelea.

También vigila una fila global única usada como contador o flag de estado (por ejemplo, una fila en una tabla de settings). Bajo carga, esa fila se convierte en un cuello de botella compartido.

Finalmente, código rápido o generado por IA a menudo gestiona mal los límites de transacción. Puede envolver demasiado trabajo en una transacción o mezclar lecturas y escrituras de forma inesperada. Si heredaste un prototipo, revisar el alcance de las transacciones suele ser la ganancia más rápida.

Preguntas para hacerse si el problema sigue regresando:

• ¿Alguna transacción incluye llamadas de red o bucles largos?
• ¿Las escrituras por lotes están divididas y son amigas de índices?
• ¿Las actualizaciones conflictivas tocan las filas en un orden consistente?
• ¿Existe una única fila que todos actualicen?
• ¿Las transacciones son explícitas y mínimas, no accidentales?

Próximos pasos: estabiliza ahora y prevén repeticiones

Las victorias rápidas suelen venir de acortar las transacciones más ocupadas, no de servidores más grandes. Estabiliza primero y luego rediseña las escrituras para que el problema no vuelva la semana siguiente.

Prioriza las correcciones en este orden: acortar transacciones, reducir presión sobre la tabla caliente y luego refactorizaciones más profundas.

Orden práctico de operaciones:

• Encuentra las 1–3 consultas que más tiempo mantienen locks y reduce trabajo dentro de la transacción
• Añade o ajusta timeouts para que una petición atascada no bloquee todo
• Divide actualizaciones grandes en lotes o mueve trabajo no crítico a jobs asíncronos
• Rediseña escrituras calientes (logs append-only, contadores shardados, tablas de cola) una vez que el sistema esté estable
• Vuelve a probar los flujos peores bajo carga (checkout, login, backfills, cron jobs)

La monitorización no tiene que ser sofisticada. Unos pocos indicadores te dirán rápido cuando los locks vuelven a formarse: tiempo de espera por locks, edad de transacciones, deadlocks y cuántas sentencias alcanzan timeouts. Alerta sobre tendencias, no sobre picos aislados.

Si estás lidiando con un código heredado generado por IA y los bugs de locks son difíciles de trazar, FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar problemas como transacciones largas, patrones de escritura inseguros y brechas de seguridad en apps generadas por IA. Una auditoría rápida suele ser suficiente para identificar la consulta bloqueadora y la ruta exacta en el código que necesita cambiar.