Niveles de Aislamiento de Transacción

El nivel de aislamiento de la transacción se entiende como un estado dentro de las bases de datos que especifica la cantidad de datos que son visibles para una declaración en una transacción, especialmente cuando los mismos datos son accedidos por muchas transacciones al mismo tiempo. Imaginemos una situación en la que tenemos una tabla de Clientes con 1 millón de filas que ocupa 10 GB de espacio en disco. A las 9 en punto comenzamos una consulta “SELECT * FROM Clientes”, que consulta todas las filas de la tabla. En nuestro caso, esta consulta tarda aproximadamente 5 minutos en completarse. Este tiempo es necesario para escanear completamente nuestra tabla hasta el final y recuperar las filas. Este tipo de consulta realiza un escaneo completo de la tabla y no se recomienda desde el punto de vista del rendimiento. A las 9:01, UsuarioB actualiza la última fila en la tabla de Clientes y confirma el cambio. Poco tiempo después, nuestra consulta llega a la última fila modificada por UsuarioB. Entonces, ¿qué pasará? ¿Veremos el valor original de la fila o el valor modificado? El nuevo valor de la fila es legítimo y ha sido confirmado, pero se actualizó después de que nuestra consulta comenzara.

El resultado de nuestra consulta depende del nivel de aislamiento de la transacción. Básicamente, hay 4 niveles de aislamiento explicados a continuación:

1. Read uncommitted. Veremos los cambios realizados por UsuarioB. Este nivel de aislamiento también se llama “lecturas sucias”, lo que significa que los datos leídos no son consistentes con otras partes de la tabla o la consulta y pueden no haber sido aún confirmados. “Lecturas sucias” aseguran el rendimiento más rápido, ya que los datos se leen directamente de los bloques de la tabla sin validación.
2. Read committed. No veremos los cambios realizados por UsuarioB. Esto sucede porque con este nivel de aislamiento de consulta, las filas recuperadas por una consulta son las filas que se habían confirmado antes de que la consulta comenzara. Esto significa que los cambios realizados por UsuarioB no estaban allí cuando la consulta comenzó, por lo que los cambios no se incluirán en el resultado de la consulta.
3. Repeatable read. No veremos los cambios realizados por UsuarioB. Esto se debe al hecho de que en el nivel de aislamiento de lectura repetible, las filas recuperadas por una consulta son las filas que se confirmaron cuando comenzó la transacción. Esto significa que los cambios realizados por UsuarioB no estaban allí cuando la transacción comenzó, y por lo tanto no se incluirán en el resultado de la consulta. “Todas las lecturas consistentes dentro de la misma transacción leen la instantánea establecida por la primera lectura” (de la documentación de MySQL)
4. Serializable. Este nivel de aislamiento significa que todas las transacciones de la base de datos se producen de una manera completamente aislada. En este nivel de aislamiento, todas las transacciones se ejecutan en serie, una tras otra. El DBMS puede ejecutar dos o más transacciones al mismo tiempo solo si se puede mantener la ilusión de ejecución en serie. En la práctica, serializable es muy similar a lectura repetible pero utiliza una técnica de implementación diferente para cada motor de base de datos. Por ejemplo, en Oracle, el nivel de aislamiento de lectura repetible no es compatible y Serializable proporciona el nivel de aislamiento más alto. Este nivel de aislamiento es como lectura repetible, pero InnoDB implícitamente convierte todas las declaraciones SELECT simples en “SELECT … LOCK IN SHARE MODE”.