Este nivel de aislamiento permite lecturas sucias. Una transacción puede ver cambios no confirmados realizados por otra transacción.
Para mantener el más alto nivel de aislamiento, un DBMS generalmente adquiere bloqueos en los datos, lo que puede resultar en una pérdida de concurrencia y una alta sobrecarga de bloqueo. Este nivel de aislamiento relaja esta propiedad.
Es posible que desee consultar el artículo de Wikipedia sobre READ UNCOMMITTED para ver algunos ejemplos y lecturas adicionales.
También puede interesarle consultar el artículo del blog de Jeff Atwood sobre cómo él y su equipo abordaron un problema de interbloqueo en los primeros días de Stack Overflow. Según Jeff:
Pero es nolock peligroso? ¿Podría terminar leyendo datos no válidos con read uncommitted? ¿sobre? Sí, en teoría. Encontrará una gran cantidad de astronautas de la arquitectura de la base de datos que comienzan a arrojarle ciencia ACID y todo, pero activan la alarma contra incendios del edificio cuando les dice que desea probar nolock .Es verdad:la teoría da miedo. Pero esto es lo que pienso:"En teoría no hay diferencia entre la teoría y la práctica. En la práctica sí la hay".
Nunca recomendaría usar nolock como una solución general de aceite de serpiente "bueno para lo que le aqueja" para cualquier problema de bloqueo de base de datos que pueda tener. Primero debe intentar diagnosticar el origen del problema.
Pero en la práctica agregando nolock a las consultas que absolutamente sabe que son simples, los asuntos directos de solo lectura nunca parecen generar problemas... Siempre y cuando sepa lo que está haciendo.
Una alternativa a READ UNCOMMITTED el nivel que quizás desee considerar es el READ COMMITTED SNAPSHOT . Citando a Jeff de nuevo:
Las instantáneas se basan en un método de seguimiento de cambios de datos completamente nuevo... más que un ligero cambio lógico, requiere que el servidor maneje los datos físicamente de manera diferente. Una vez que este nuevo método de seguimiento de cambios de datos está habilitado, crea una copia o instantánea de cada cambio de datos. Al leer estas instantáneas en lugar de datos en vivo en momentos de conflicto, los bloqueos compartidos ya no son necesarios en las lecturas y el rendimiento general de la base de datos puede aumentar.
