Decisión: ¿qué nivel de aislamiento?
El nivel de aislamiento de las transacciones determina el equilibrio entre concurrencia y consistencia. Un aislamiento mayor implica menos anomalías, pero más bloqueos/conflictos y reintentos. Este árbol le ayuda a elegir entre Read Committed, Repeatable Read/Snapshot y Serializable según las anomalías de lectura (dirty, non-repeatable, phantom) que pueda tolerar.
¿Puede tolerar lecturas sucias (dirty reads)?
Empiece por la anomalía más básica: ¿debe una transacción poder leer datos que aún no se han confirmado (y que pueden revertirse)? Casi ninguna aplicación seria lo quiere; en la mayoría de los motores modernos el valor por defecto ya impide las lecturas sucias. Solo se relaja para recuentos aproximados/analíticos y máxima velocidad.
- No, solo debo leer datos confirmados
- Sí, basta una lectura aproximada (poco frecuente)
¿Debe ver el mismo resultado al volver a leer dentro de la misma transacción?
Descartadas las lecturas sucias, la siguiente pregunta: si lee la misma fila dos veces dentro de una transacción, ¿es un problema ver un valor distinto porque alguien confirmó entre medias (non-repeatable read), o que aparezcan filas nuevas (phantom)? La lógica que exige consistencia en informes/cálculos suele necesitar una instantánea consistente.
- No, está bien que cada sentencia vea los últimos datos confirmados
- Sí, se necesita una instantánea consistente para toda la transacción
¿Deben las transacciones concurrentes estar lógicamente ordenadas por completo?
Quiere lecturas consistentes; ¿es suficiente, o las transacciones concurrentes deben producir un resultado como si se hubieran ejecutado una a una, en secuencia (serializable)? Si puede tolerar anomalías sutiles como el write skew (p. ej. dos transacciones que leen filas distintas y escriben de forma que se invalidan mutuamente), Snapshot es suficiente; de lo contrario, se requiere serialización completa.
- No, basta con una instantánea consistente
- Sí, no es aceptable ninguna anomalía de concurrencia
Recomendación: Read Uncommitted (solo casos especiales)
El aislamiento más bajo; permite lecturas sucias. Lee casi sin esperar a los bloqueos, pero puede ver datos que pueden revertirse. No se recomienda para aplicaciones de propósito general.
Recomendación: Read Committed (OLTP por defecto)
Cada sentencia ve los últimos datos confirmados en ese momento; se impiden las lecturas sucias. Es el valor por defecto en la mayoría de los motores y ofrece el mejor equilibrio entre concurrencia y consistencia para cargas OLTP típicas.
Recomendación: Repeatable Read / Snapshot (lecturas consistentes)
La transacción trabaja sobre una instantánea consistente fijada al inicio (o en su primera lectura); las lecturas no cambian durante la transacción. Con MVCC, los lectores no bloquean a los escritores y los escritores no bloquean a los lectores.
Recomendación: Serializable (aislamiento completo)
El aislamiento más alto: las transacciones concurrentes producen un resultado como si se hubieran ejecutado en serie (una a una, en secuencia). Impide todas las anomalías de lectura y el write skew; el precio son más conflictos y la necesidad de reintentos.