Comprender el bloqueo de filas de base de datos y los problemas de concurrencia en MySQL

Fila de la base de datos En MySQL, el bloqueo controla con precisión qué transacción puede leer o escribir qué filas y cuándo, lo que protege contra la pérdida de actualizaciones y las lecturas sucias. Te mostraré paso a paso cómo funcionan los bloqueos, MVCC y cómo interactúan los niveles de aislamiento, dónde surgen los problemas de concurrencia y cómo puedo diseñar consultas, índices y transacciones para evitar bloqueos.

Puntos centrales

Para que puedas orientarte rápidamente sobre el tema central de este artículo, voy a resumir los puntos clave y compararlos brevemente. De este modo, tendrás una estructura concisa que te servirá de base para los siguientes apartados, más detallados Explicaciones.

• Bloqueos de fila limitar los conflictos a líneas concretas en lugar de a tablas completas.
• MVCC permite una lectura rápida sin bloqueos compartidos permanentes.
• Aislamiento determina qué anomalías pueden producirse.
• Tecla Gap/Next Bloquear las brechas del índice contra los fantasmas.
• Buenas prácticas reducen notablemente los bloqueos y los interbloqueos.

A continuación, traduzco estos puntos en medidas concretas con las que mantengo las instancias productivas de MySQL más seguras y rápidas. Cada recomendación tiene como objetivo reducir Bloqueo, datos coherentes y vías de diagnóstico claras.

Por qué es necesario el control de la concurrencia

Los accesos simultáneos entran en conflicto en cuanto varias sesiones intentan leer o escribir las mismas líneas, por lo que opto por una estructura clara Límites de transacción Ocho. Sin reglas, se corre el riesgo de que se produzcan actualizaciones perdidas, lecturas sucias, lecturas no repetibles y objetos fantasma, lo que al final provoca decisiones erróneas en el código de la aplicación. Yo evito esto garantizando la consistencia de lectura y haciendo visibles los conflictos de escritura desde el principio, en lugar de sobrescribirlos silenciosamente. Cuantos más usuarios paralelos estén activos, más importantes se vuelven los pequeños objetos de bloqueo y los breves Tiempos de parada. Quien ignore esto, se arriesga a sufrir errores en los datos, con largas colas de espera y tiempos de espera agotados.

Fundamentos del bloqueo de filas en MySQL

El bloqueo por filas aplica bloqueos a filas concretas, de modo que las demás filas siguen estando libres y se puede Paralelismo se crea. Un bloqueo exclusivo protege las operaciones de escritura hasta la confirmación, mientras que los accesos de lectura utilizan bloqueos compartidos o instantáneas MVCC, dependiendo del nivel de aislamiento. Los bloqueos de intención sirven como señales de alto nivel para que el motor pueda comprobar más rápidamente la compatibilidad de los bloqueos. Siempre tengo en cuenta que incluso las actualizaciones pequeñas pueden afectar a muchas filas si las condiciones WHERE son imprecisas y no hay Índice conduce a ello. La precisión en el filtrado evita rangos de bloqueo amplios y preserva la concurrencia.

También es importante la interacción con los índices, ya que InnoDB bloquea a través de rutas de índice; la falta de claves o unas claves inadecuadas aumentan considerablemente el número de filas afectadas. Si una instrucción realiza un escaneo completo, el campo de bloqueo crece, lo que aumenta los tiempos de espera y favorece los interbloqueos. Por eso, desde el principio planifico las claves adecuadas para las rutas frecuentes y mantengo las cláusulas WHERE lo más específicas posible. De este modo, mis bloqueos se mantienen reducidos y otras transacciones se completan más rápido. Acceda a. Ese es el ajuste más sencillo para conseguir un bloqueo suave.

Bloqueo pesimista frente a bloqueo optimista

El bloqueo pesimista parte de la base de que habrá conflictos y bloquea las cosas desde el principio, lo que refuerza la integridad, pero lleva tiempo, mientras que optimista Los sistemas en funcionamiento solo comprueban al final si los datos han cambiado. En configuraciones prácticas de MySQL, combino ambas cosas: para cuentas críticas, realizo la escritura con FOR UPDATE; para entidades que rara vez entran en conflicto, utilizo versiones. Una columna de versión o una marca de tiempo me permite determinar, durante la actualización, si alguien ha sido más rápido, sin bloquear la fila de forma permanente. Si se produce un conflicto, repito la transacción de forma selectiva o ejecuto una lógica de negocio adaptada. De este modo, distribuyo la carga de forma más limpia, reduzco los tiempos de espera y mantengo la Corrección alto.

Elijo la estrategia en función de cada caso de uso: las lecturas simultáneas en gran número se benefician de enfoques optimistas, mientras que las transacciones financieras o de inventario altamente críticas se benefician de bloqueos exclusivos breves pero claros. El objetivo sigue siendo siempre bloquear solo lo necesario y detectar los conflictos a tiempo. Con este enfoque evito largas cadenas de sesiones en espera. De este modo, aumenta el rendimiento y Fiabilidad en la vida cotidiana.

Comprender los niveles de aislamiento y el MVCC

El nivel de aislamiento determina cuántas anomalías permito y el grado de bloqueo de MySQL, por lo que elijo el nivel deliberadamente en función del caso de uso. READ COMMITTED evita accesos de lectura sucios, REPEATABLE READ mantiene la coherencia de los valores de una transacción y SERIALIZABLE establece el orden más estricto. InnoDB utiliza MVCC, de modo que los lectores casi siempre puedan prescindir de los bloqueos compartidos y, aun así, vean instantáneas coherentes. Quien trabaje con esto debería comprender cuándo se activan además los bloqueos «gap» y «next-key» para evitar los «fantasmas». Para obtener información más detallada, vale la pena echar un vistazo a Detalles sobre los niveles de aislamiento, para que puedas evaluar correctamente los efectos en cada nivel.

La siguiente tabla clasifica los niveles habituales frente a anomalías típicas y su impacto en los bloqueos, para que pueda tomar la decisión adecuada y evitar Bloqueo evitar.

Nivel de aislamiento	Anomalías permitidas	Comportamiento de bloqueo (simplificado)	Uso típico
LEER NO COMPROMETIDO	Lecturas subidas de tono, Irrepetibles, Fantasmas	Pocas restricciones, alta Riesgos	Rara vez tiene sentido
READ COMMITTED	No repetibles, fantasmas	Los lectores utilizan MVCC, los escritores X-Locks	Informes, API con muchas lecturas
LECTURA REPETIBLE	Phantoms rebajados por Next-Key	Gran consistencia en la lectura, específica Brecha-Bloquear	Por defecto en InnoDB
SERIALIZABLE	No se observan anomalías	Barreras más anchas, menos Paralelismo	Procesos de alta criticidad

Normalmente empiezo con REPEATABLE READ y lo corrijo de forma selectiva cuando las consultas se bloquean demasiado debido a los bloqueos de clave siguiente. Por el contrario, solo utilizo SERIALIZABLE cuando es imprescindible desde el punto de vista técnico, ya que, de lo contrario, se acumulan los tiempos de espera. Con una elección clara para cada carga de trabajo, mantengo la coherencia de los datos y, al mismo tiempo, protejo la Actuación. Este enfoque ahorra tiempo de asistencia técnica, ya que se producen picos de bloqueo inesperados con menos frecuencia. De este modo, el sistema sigue siendo predecible, incluso cuando aumenta el número de usuarios.

La concurrencia en MySQL en la práctica

Una buena concurrencia empieza por consultas bien formuladas, que solo seleccionen las filas realmente necesarias, de modo que InnoDB pueda Fila-puedo establecer bloqueos. Me aseguro de que las condiciones de filtrado sean «sargable», es decir, que se ejecuten a través de índices y no requieran llamadas a funciones en las columnas. Mantengo las actualizaciones bien definidas: cláusula WHERE clara, índice adecuado, sin uniones innecesarias en la misma instrucción. En los casos de reservas, utilizo FOR UPDATE con moderación y solo para los registros realmente afectados. Además, evito interacciones prolongadas del usuario entre BEGIN y COMMIT, ya que cada segundo aumenta la tiempo de espera de otras sesiones.

Al realizar inserciones en espacios de índice densos, tengo en cuenta que pueden activarse bloqueos de clave siguiente (Next-Key-Locks) y que, por lo tanto, más transacciones quedan en espera. Distribuyo los puntos de mayor actividad dispersando los espacios de claves o desviando la ruta de escritura a una pequeña cola independiente. De este modo, reduzco las colisiones en la tabla más solicitada. Este ajuste fino tiene un efecto mayor que el aumento de los tiempos de espera, ya que se producen menos Conflictos se produzcan en absoluto. Precisamente por eso merece la pena medir el acceso a los datos antes de la puesta en marcha.

Problemas típicos de concurrencia: bloqueo, interbloqueos, alcance de los bloqueos

El bloqueo se produce cuando una transacción espera a una fila que ya está bloqueada, por lo que mantengo las transacciones breves y la afectada Cantidad limitar. Los interbloqueos se producen cuando dos transacciones se bloquean mutuamente, lo que MySQL detecta y provoca la interrupción de una de ellas. Yo respondo a esto con reintentos específicos y un orden de acceso coherente en todas las rutas de código. La escalada de bloqueos es menos frecuente en InnoDB, pero los límites internos restringen la capacidad de gestión; los escaneos de gran tamaño acercan al motor a esos límites. Quien observe interbloqueos recurrentes debería Detección y gestión de interbloqueos analizar de forma sistemática y eliminar las fuentes de conflicto, en lugar de limitarse a aumentar los tiempos de espera.

Según mi experiencia, hay tres patrones que provocan especialmente muchos tiempos de espera: filtros sin indexar en tablas muy solicitadas, el uso de «FOR UPDATE» sin una cláusula «WHERE» precisa y una lógica de negocio extensa entre los pasos de lectura y escritura. Los elimino midiendo cada ruta por separado, reduciendo el tiempo de bloqueo y ajustando las sentencias SQL a las rutas de los índices. Pequeños cambios en el filtro o en el orden de las actualizaciones suelen resolver nudos enteros. Estas correcciones son más económicas que... Hardware, porque tienen un efecto duradero. Solo entonces merece la pena plantearse la ampliación vertical u horizontal.

Buenas prácticas para evitar bloqueos y interbloqueos

Cierro las transacciones rápidamente y no dejo ningún formulario de entrada abierto mientras se mantienen los bloqueos, ya que cada segundo supone una pérdida innecesaria Colas de espera provocado. Siempre accedo a las tablas y las filas en el mismo orden para evitar dependencias cíclicas. Para operaciones de solo lectura, suele bastar con READ COMMITTED, mientras que para actualizaciones críticas utilizo REPEATABLE READ o, en casos puntuales, FOR UPDATE. El diseño de índices sigue siendo imprescindible: sin una clave adecuada, una instrucción bloquea rápidamente demasiadas filas. El manejo de errores también forma parte de ello: detecto los errores de interbloqueo, registro todos los detalles e intento una solución breve y limpia Reintentar.

La monitorización completa el paquete: superviso los tiempos de espera, los recuentos de interbloqueos y los planes de consulta, y optimizo primero los picos más llamativos. Las pequeñas mejoras en las rutas críticas dan muy buenos resultados, ya que afectan a todas las consultas. Así consigo menos bloqueos, mayor rendimiento y tiempos de respuesta fiables. Este enfoque resulta mucho más eficaz en el día a día que las grandes remodelaciones. Las rutinas bien diseñadas superan a las soluciones generales Acciones casi siempre.

Consejos específicos de MySQL para aumentar la concurrencia

Utilizo el autocommit de forma deliberada: las sentencias individuales se benefician de ello, mientras que los cambios relacionados se agrupan en una instrucción breve y clara Transacción . Utilizo SELECT … FOR UPDATE con moderación y solo para los registros que realmente necesito reservar. Desvío los informes largos a réplicas o sistemas analíticos para que las cargas de trabajo OLTP no tengan que esperar. Además, compruebo periódicamente qué sentencias mantienen un número inusual de bloqueos y por qué. Quien desee profundizar más, debería consultar la Motor de almacenamiento InnoDB y evaluar de forma crítica los diseños de los índices en el contexto de su propio esquema antes de que se ponga en marcha la próxima versión.

Minimizo los puntos de congestión seleccionando las claves primarias de tal forma que la carga de escritura no se concentre permanentemente al final de un índice que crece de forma monótona. También divido las operaciones por lotes en pequeños fragmentos para no generar bloqueos exclusivos prolongados. Con estas herramientas, los bloqueos duran menos y la contienda se reduce de forma apreciable. De este modo, disminuye la tasa de errores y la aplicación responde con mayor fluidez. Así es como aprovecho las reservas sin tener que crear inmediatamente nuevas Servidor acumularse.

Seguimiento y análisis: lo que mido

Empezaré con métricas sobre tiempos de espera de bloqueo, número de interbloqueos, transacciones largas y las sentencias más ejecutadas por tiempo de ejecución, para poder identificar los principales Palanca identifico. El esquema de rendimiento, la consulta SHOW ENGINE INNODB STATUS y los registros de consultas lentas me proporcionan indicios concretos. A continuación, examino los planes de las consultas más problemáticas y compruebo si faltan índices o si los filtros no son almacenables. Tan pronto como elimino los cuellos de botella, observo el efecto a lo largo de varias fases de carga. Este ciclo de medir, modificar y verificar permite que la calidad aumentar notablemente la concurrencia.

Para obtener resultados fiables, necesito datos de prueba realistas y patrones de acceso reales, no solo pruebas sintéticas de un solo paso. Los perfiles de carga con sesiones simultáneas muestran cómo funcionan realmente los bloqueos. Este tipo de pruebas revelan puntos críticos ocultos que, en el día a día, no se detectan hasta que es demasiado tarde. Quien comprueba las versiones de esta manera evita sorpresas en el entorno de producción. Esto ahorra costes, tiempo y nervios a largo plazo. Ver.

Entorno de alojamiento y rendimiento de la base de datos

Una buena concurrencia depende de un hardware rápido, ya que cualquier retraso en las operaciones de E/S alarga el Duración del bloqueo. Me aseguro de contar con SSD rápidos, suficiente RAM para los búferes y rutas cortas entre la aplicación y la base de datos. Las reservas de CPU ayudan a ejecutar consultas en paralelo sin atascos. Reduzco sistemáticamente las latencias de red para que los tiempos de ida y vuelta no aumenten el tiempo de bloqueo efectivo. Quien tenga en cuenta estas condiciones marco, obtendrá una respuesta ágil Servicios y menos abortos.

También son importantes las estrategias de escalabilidad adecuadas: réplicas de lectura para informes, fragmentación para conjuntos de datos muy grandes y sistemas independientes para cargas de trabajo de análisis. Solo elijo qué opción vale la pena después de realizar mediciones, y evito las decisiones precipitadas. La arquitectura y la disciplina SQL se complementan; sin consultas coherentes, el hardware solo compensa a corto plazo. Con una combinación adecuada, reduzco significativamente los conflictos de bloqueo. El resultado es una experiencia de usuario fiable sin Tiempos de espera.

Tipos de bloqueo en InnoDB en detalle

Para tomar decisiones acertadas sobre las rutas de consulta, conozco a la perfección los tipos de bloqueo más importantes: los bloqueos de registro bloquean entradas de índice individuales, los bloqueos de espacio bloquean el espacio entre dos entradas de índice, y los bloqueos de clave siguiente son una combinación de ambos. Estos últimos evitan los fantasmas en los escaneos de rango. Los bloqueos de intención de inserción (Insert-Intention-Locks) indican la intención de realizar inserciones y permiten inserciones paralelas en diferentes huecos sin obstaculizarse innecesariamente. En búsquedas únicas mediante un índice único, InnoDB reduce el bloqueo a un bloqueo de registro, lo que minimiza los bloqueos. En cuanto entra en juego un predicado de rango (BETWEEN, >, LIKE con prefijo), suele aplicarse un bloqueo de clave siguiente y, con ello, un área de bloqueo más amplia.

Por eso, planifico las consultas de manera que, en la medida de lo posible, utilicen índices únicos o altamente selectivos. No solo el WHERE es determinante: el ORDER BY, el LIMIT y el orden de las uniones (JOIN) también influyen en la ruta de índice elegida y, por lo tanto, en el alcance del bloqueo. Una reescritura específica que utilice un ORDER BY con el índice adecuado puede evitar los bloqueos Next-Key y reducir considerablemente los tiempos de espera.

Utilizar las lecturas con bloqueo de forma selectiva

Las lecturas con bloqueo son útiles cuando necesito reservar filas o coordinar actualizaciones simultáneas. En MySQL utilizo:

• SELECT … FOR UPDATE: bloqueo exclusivo en las filas leídas, adecuado para reservas antes de una actualización.
• SELECT … FOR SHARE (o LOCK IN SHARE MODE en versiones anteriores): bloqueo compartido para garantizar lecturas coherentes con protección contra escritura.
• NOWAIT y SKIP LOCKED: evitan largas esperas; NOWAIT interrumpe inmediatamente la ejecución, mientras que SKIP LOCKED omite las líneas bloqueadas.

Un patrón habitual para las colas de tareas:

START TRANSACTION;
SELECT id, payload
FROM jobs
WHERE status = 'ready'
ORDER BY priority, id
LIMIT 50
FOR UPDATE SKIP LOCKED;
-- marcar como 'processing' y confirmar
UPDATE jobs SET status = 'processing' WHERE id IN (...);
COMMIT;

Así es como gestiono la carga en paralelo sin que las operaciones se bloqueen entre sí. Lo importante es utilizar cláusulas WHERE precisas, un índice adecuado sobre (status, priority, id) y transacciones cortas.

Entender los bloqueos de metadatos (MDL)

Además de los bloqueos de fila, existen los bloqueos de metadatos, que coordinan las operaciones DDL y DML. Cada consulta en ejecución mantiene un bloqueo de lectura MDL sobre las tablas afectadas; las operaciones DDL requieren bloqueos MDL exclusivos. Por lo tanto, un ALTER TABLE iniciado sin la debida precaución puede tener que esperar a que finalicen transacciones o informes largos; a la inversa, un DDL bloquea a su vez nuevos accesos DML. Por ello, planifico los cambios de esquema fuera de las horas punta, reduzco la duración de las transacciones y compruebo antes de las implementaciones si hay sesiones que mantienen las tablas abiertas durante minutos. Las variantes de DDL en línea alivian en gran medida la situación, pero no sustituyen a la disciplina en los tiempos de transacción. En la supervisión, observo específicamente las esperas MDL, ya que indican atascos evitables.

Claves externas, cascadas y obligación de indexación

Las claves externas mejoran la calidad de los datos, pero aumentan la huella de bloqueo. InnoDB comprueba la coherencia a través de índices; si estos faltan en las columnas de clave externa, se corre el riesgo de que se produzcan escaneos extensos y bloqueos prolongados. Por eso me aseguro de que haya índices en cada columna de referencia. Las actualizaciones y eliminaciones en cascada pueden bloquear varias tablas en una sola transacción y, por lo tanto, provocar interbloqueos. Defino un orden de acceso fijo para todas las tablas afectadas y mantengo los cambios al mínimo. Cuando las cascadas son poco frecuentes desde el punto de vista funcional, busco alternativas: pasos explícitos y breves con condiciones WHERE claras, para que la duración del bloqueo sea predecible.

Autoincremento, puntos de acceso e inserciones masivas

Las claves primarias que crecen de forma monótona generan un punto de congestión al final del índice agrupado. Allí se acumulan muchas inserciones paralelas, lo que aumenta los tiempos de espera. Distribuyo las claves (por ejemplo, mediante claves de partición o ID de entidad antepuestas) o utilizo tamaños de lote cortos que se confirman correctamente. Controlo el comportamiento de autoincremento mediante el modo de bloqueo: para OLTP, prefiero configuraciones que permitan inserciones paralelas y bloqueen solo brevemente. En el caso de lotes grandes, compruebo si una ruta similar a COPY o pequeños subconjuntos repetibles son más rápidos. Es importante recordar: crear índices solo después de grandes procesos de carga o descargar los índices secundarios durante los mismos para reducir los puntos críticos de inserción.

Replicación y lecturas consistentes

Al leer réplicas, tengo en cuenta los retrasos: de lo contrario, un informe podría mostrar datos obsoletos. Para obtener instantáneas consistentes, inicio las transacciones deliberadamente con WITH CONSISTENT SNAPSHOT y establezco READ ONLY cuando solo se lee. De este modo, mantengo una visión estable a lo largo de varias sentencias, sin bloqueos innecesarios. Al mismo tiempo, me aseguro de que la aplicación cuente con rutas tolerantes ante retrasos en la replicación o, si es necesario, recurra al servidor primario cuando la actualidad absoluta sea decisiva. Esto reduce las sorpresas y explica las aparentes „anomalías“, que en realidad no son más que latencias de replicación.

Configuración y estrategias de reintento

Ajusto los tiempos de espera de bloqueo y la detección de forma adecuada: un valor moderado de innodb_lock_wait_timeout evita que las sesiones se bloqueen durante minutos. Detecto los interbloqueos de forma proactiva y los distingo claramente: el error 1213 (interbloqueo) lo resuelvo rápidamente con backoff y jitter; el error 1205 (tiempo de espera de bloqueo agotado) lo considero una señal para optimizar la ruta de consulta. innodb_deadlock_detect ayuda en muchas transacciones cortas; en casos de paralelismo extremadamente alto, su relación coste-beneficio puede desequilibrarse; entonces, equilibrar los puntos críticos es casi siempre la mejor respuesta que el mero ajuste de parámetros.

Los reintentos solo son seguros si las operaciones son idempotentes. Diseño las rutas de actualización de tal manera que un reintento alcance el mismo estado final (por ejemplo, con columnas de versión, conjuntos deterministas en lugar de incrementos o eventos de negocio claros). De este modo, evito las duplicaciones y mantengo el código robusto frente a conflictos inevitables.

Ejemplos: lotes sin bloqueos generales

Divido los cambios grandes en pequeños fragmentos indexados según la clave principal:

-- Ejemplo: Eliminación por lotes
SET @last_id = 0;
WHILE 1 DO
  DELETE FROM events
  WHERE id > @last_id
  ORDER BY id
  LIMIT 1000;
  SET @rows = ROW_COUNT();
  IF @rows = 0 THEN LEAVE; END IF;
  SET @last_id = (SELECT MAX(id) FROM events WHERE id <= @last_id + 1000);
END WHILE;

Este patrón mantiene las transacciones breves, reduce los tiempos de bloqueo y deja espacio para otras cargas de trabajo. Hago lo mismo con las actualizaciones masivas: primero selecciono los ID de destino en un conjunto temporal (o mediante una ventana LIMIT), luego escribo de forma selectiva y confirmo rápidamente.

Guía rápida de diagnóstico

Cuando los tiempos de espera se alargan, sigo un orden fijo:

1. Delimitar el síntoma: ¿qué tablas, qué sentencias, a qué hora?
2. Hacer visibles las colas de espera: en Performance Schema, identificar los «data_locks» y «data_lock_waits», así como los PID que provocan bloqueos; además, comprobar el estado actual de InnoDB.
3. Verificar el plan de consulta: ¿Utiliza la consulta el índice esperado? ¿Son los predicados agrupables?
4. Reducir el alcance de los bloqueos: precisar la cláusula WHERE, añadir índices, evitar los escaneos de rango y restringir las lecturas con bloqueo.
5. Reducir la duración de la transacción: eliminar las interacciones y las llamadas externas de la transacción, y reducir el tamaño de los conjuntos de resultados.
6. Repetir y medir: tras el cambio, volver a observar y comparar los picos de consumo.

Este procedimiento evita que se actúe a ciegas. En lugar de aumentar los tiempos de espera, elimino las causas: es una solución más sostenible y, por lo general, más rápida.

Evitar los escollos operativos

Hay tres cosas a las que presto especial atención durante el funcionamiento: en primer lugar, evito desactivar el autocommit a nivel global por error, ya que eso prolonga los bloqueos sin que nos demos cuenta. En segundo lugar, evito que los grupos de conexiones pasen transacciones que ya mantengan bloqueos abiertos. En tercer lugar, utilizo los puntos de guardado de forma específica para reversiones parciales, pero no espero que acorten los tiempos de bloqueo: el bloqueo se mantiene hasta el commit o el rollback. Una disciplina clara en el nivel de la aplicación se traduce directamente en tiempos de espera más cortos.

En pocas palabras: principales conclusiones

El bloqueo de filas garantiza la coherencia de los datos, pero solo si se combina con MVCC, con un nivel de aislamiento adecuado y un diseño de índices bien estructurado, es donde realmente destaca. Mantengo las transacciones breves, filtro de forma selectiva y utilizo FOR UPDATE solo cuando la reserva es realmente necesaria desde el punto de vista funcional. Reduzco los conflictos mediante secuencias de acceso consistentes y reintentos claros en caso de interbloqueos. Elijo los niveles de aislamiento según cada caso de uso y observo cómo afectan los bloqueos Gap y Next-Key. Quien actúe de forma mesurada y afine regularmente, alcanzará un alto Concurrencia sin sorpresas.

Al final, lo que cuenta son tres cosas: objetos de bloqueo pequeños, tiempos de retención cortos y rutas de consulta transparentes. Con estos principios, las cargas de trabajo de MySQL funcionan de forma fiable, incluso cuando hay muchos usuarios activos al mismo tiempo. Apuesto por pruebas repetibles, métricas significativas y optimizaciones específicas en lugar de grandes modificaciones. De este modo, los datos se mantienen correctos, los tiempos de respuesta son bajos y los bloqueos son poco frecuentes. Eso es precisamente lo que espera cualquier equipo de una base de datos ágil Base de datos.