Niveles de Aislamiento de Transacciones

El nivel de aislamiento de transacciones se comprende como un estado dentro de las bases de datos que especifica la cantidad de datos que es visible 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 de 1 millón de filas que ocupa 10 GB de espacio en disco. A las 9:00 empezamos una consulta “SELECT * FROM Customers”, 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 realizar desde el punto de vista del rendimiento. A las 9:01 UserB actualiza la última fila en la tabla de Clientes y confirma el cambio. Un corto tiempo después nuestra consulta llega a la última fila modificada por UserB. Entonces, ¿qué sucederá? ¿Veremos el valor de fila original o el valor de fila modificado? El nuevo valor de fila es legítimo y confirmado, pero se actualizó después de que empezó nuestra consulta.

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. Leer sin confirmar. Veremos los cambios hechos por UserB. 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 puede que aún no se hayan confirmado. Las “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. Leer confirmado. No veremos los cambios hecho por UserB. Eso 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 se iniciara la consulta. Significa que los cambios realizados por UserB no estaban allí cuando la consulta comenzó, por lo que no se incluirán en el resultado de la consulta.
3. Lectura repetible. No veremos los cambios hechos por UserB. Esto sucede debido a que en el nivel de aislamiento de lectura repetible, las filas recuperadas por una consulta son las filas que se habían confirmado cuando la transacción se inició. Eso significa que los cambios hechos por UserB 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 implica que todas las transacciones de la base de datos ocurren de manera completamente aislada. En este nivel de aislamiento todas las transacciones se ejecutan de forma serial, 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 parecido 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 la lectura repetible, pero InnoDB convierte implícitamente todas las declaraciones de SELECT en “SELECT … LOCK IN SHARE MODE”.