Niveles de aislamiento de consultas en bases de datos

Uncommited Read

No ve INSERT/UPDATE/DELETE que no fueron commiteados
No ve UPDATE/DELETE que fueron commiteados
Ve INSERT que fueron commiteados
Un SELECT bloquea la tabla de la que tomó los datos hasta que commitea (no permite hacer UPDATE/DELETE pero si INSERT y SELECT)
Puede generar deadlocks (por ejemplo, si una transacción lee una tabla y después otra transacción lee la misma tabla, la tabla queda bloqueada para las dos transacciones. Si ambas intentan hacer un UPDATE/DELETE sobre esa tabla, van a quedar bloqueadas esperando a que la otra transacción desbloquee la tabla commiteando o rollbackeando)

No ve INSERT/UPDATE/DELETE que no fueron commiteados
No ve INSERT/UPDATE/DELETE que fueron commiteados
Un SELECT bloquea la tabla de la que tomó los datos hasta que commitea (no permite hacer INSERT/UPDATE/DELETE pero si SELECT)
Un INSERT bloquea la tabla de la que tomó los datos hasta que commitea (no permite hacer INSERT/UPDATE/DELETE pero si SELECT, aunque este SELECT va a ser solo el de read uncommited ya que el lockeo de la tabla dura hasta que se commitea y los demás niveles de aislación no pueden leer datos no commiteados)
Dentro de la misma transacción, dos queries igual van a dar el mismo resultado.
Mucho overhead y baja concurrencia
Puede generar deadlocks (por ejemplo, si una transacción lee una tabla y después otra transacción lee la misma tabla, la tabla queda bloqueada para las dos transacciones. Si ambas intentan hacer un INSERT/UPDATE/DELETE sobre esa tabla, van a quedar bloqueadas esperando a que la otra transacción desbloquee la tabla commiteando o rollbackeando)

Lees datos no commiteados, no sabiendo si esos datos van a ser commiteada o rollbackeada.