Fundamentos de la Unidad Mínima de Operación

En el contexto de las bases de datos relacionales, una transacción representa un conjunto de una o más sentencias SQL que se ejecutan como una unidad lógica de trabajo. El obejtivo principle es garantizar que los datos permanezcan en un estado consistente, incluso ante fallos de hardware o concurrencia de usuarios. InnoDB, el motor de almacenamiento predeterminado de MySQL, implementa este concepto basándose en el estándar ACID.

Para asegurar la integridad, una transacción debe cumplir con cuatro propiedades críticas:

• Atomicidad (Atomicity): Todas las operaciones se completan con éxito o ninguna se aplica. No existen estados intermedios.
• Consistencia (Consistency): La transacción transforma la base de datos de un estado válido a otro, respetando todas las reglas y restricciones (constraints).
• Aislamiento (Isolation): Las operaciones concurrentes no deben interferir entre sí. Los cambios de una transacción no confirmada no son visibles para otras.
• Durabilidad (Durability): Una vez confirmada (commit), la información persiste de forma permanente, incluso si el sistema falla inmediatamente después.

Mecanismos de Registro: Redo Log y Undo Log

InnoDB utiliza dos tipos de archivos de registro (logs) fundamentales para implementar las propiedades ACID. Mientras que el Redo Log garantiza la durabilidad, el Undo Log se encarga de la atomicidad y el control de versiones.

Undo Log: Garantía de Retroceso

El Undo Log registra la información necesaria para revertir los cambios realizados por una transacción. Si una operación falla o se ejecuta un comando ROLLBACK, InnoDB utiliza estos registros para restaurar los datos a su estado original.

Funciona mediante registros lógicos inversos: si la transacción insertó una fila, el Undo Log guarda una instrucción de eliminación; si actualizó un campo, guarda el valor previo. Además, es una pieza clave para el control de concurrencia multiversión (MVCC), permitiendo que otros procesos lean versiones anteriores de una fila que está siendo modificada.

Redo Log: Persistencia Ante Fallos

A diferencia del binlog de MySQL (que es lógico y a nivel de servidor), el Redo Log es físico y específico de InnoDB. Registra las modificaciones realizadas directamente en las páginas de datos. Este registro permite la capacidad de crash-safe: si el servidor se apaga inesperadamente, al reiniciar, InnoDB lee el Redo Log para aplicar los cambios que estaban en memoria (Buffer Pool) pero que no llegaron al disco.

El proceso de escritura sigue un protocolo de Compromiso en Dos Fases (2PC) para mantener la sincronía entre el Redo Log y el Binlog:

1. Fase de Preparación: InnoDB escribe el cambio en el Redo Log y lo marca como PREPARE.
2. Escritura de Binlog: El servidor MySQL escribe la transacción en su log binario.
3. Fase de Confirmación: InnoDB cambia el estado del Redo Log a COMMIT.

Niveles de Aislamiento y Problemas de Concurrencia

Cuando múltiples usuarios acceden simultáneamente a los mismos datos, pueden surgir fenómenos no deseados:

• Lectura sucia (Dirty Read): Leer datos que otra transacción ha modificado pero aún no ha confirmado.
• Lectura no repetible (Non-repeatable Read): Leer la misma fila dos veces en una transacción y obtener valores diferentes porque otra transacción la actualizó.
• Lectura fantasma (Phantom Read): Una consulta devuelve una serie de filas que cumplen una condición, pero al repetir la consulta aparecen filas nuevas insertadas por otra transacción.

InnoDB ofrece cuatro niveles de aislamiento para gestionar estos problemas:

Control de Concurrencia Multiversión (MVCC)

MVCC permite que las operaciones de lectura no bloqueen a las de escritura y viceversa. InnoDB logra esto añadiendo campos ocultos a cada fila:

• DB_TRX_ID: ID de la última transacción que modificó la fila.
• DB_ROLL_PTR: Puntero al registro en el Undo Log para reconstruir versiones anteriores.

Cuando se inicia una consulta en nivel REPEATABLE READ, se genera una Read View (Vista de Lectura). Esta vista actúa como una captura instantánea de los IDs de transacciones activas en ese momento. Si una fila tiene un DB_TRX_ID que pertenece a una transacción que aún no se había confirmado cuando se creó la Read View, InnoDB sigue el DB_ROLL_PTR hasta encontrar una versión del dato que sea visible para la transacción actual.

Mecanismos de Bloqueo en InnoDB

Para asegurar la integridad durante las modificaciones, InnoDB emplea diversos tipos de bloqueos a nivel de fila:

-- Bloqueo compartido (S): Permite leer, pero impide que otros modifiquen.
SELECT * FROM inventario WHERE producto_id = 500 LOCK IN SHARE MODE;

-- Bloqueo exclusivo (X): Impide cualquier lectura (S) o modificación externa.
SELECT * FROM inventario WHERE producto_id = 500 FOR UPDATE;

Además de bloquear filas individuales (Record Locks), InnoDB utiliza técnicas avanzadas para evitar lecturas fantasma en el nivel de aislamiento predeterminado:

• Record Lock: Bloquea específicamente el registro del índice.
• Gap Lock: Bloquea el espacio (hueco) entre registros del índice, impidiendo que otras transacciones inserten datos en ese rango.
• Next-Key Lock: Una combinación de Record Lock y Gap Lock que bloquea tanto el registro como el intervalo anterior a él.

Considere el siguiente ejemplo de gestión manual de transacciones:

-- Deshabilitar confirmación automática para control total
SET autocommit = 0;

START TRANSACTION;

-- Intentar actualizar el saldo de una cuenta
UPDATE cuentas_usuario 
SET saldo = saldo - 150.00 
WHERE id_usuario = 101;

-- Registrar el movimiento en una tabla de auditoría
INSERT INTO historial_pagos (id_usuario, monto, fecha) 
VALUES (101, 150.00, NOW());

-- Si ambas operaciones son correctas, persistir cambios
COMMIT;

-- En caso de error, revertir todo el bloque
-- ROLLBACK;

InnoDB optimiza el rendimiento permitiendo que la mayoría de las lecturas sean "lecturas no bloqueantes consistentes", utilizando los datos del Undo Log para proporcionar una visión coherente de la base de datos sin necesidad de adquirir bloqueos pesados.