这个老问题已经有了一个公认的答案，但我喜欢从如何改变SQL Server中的锁定行为的角度来考虑这两个隔离级别。这可能对那些像我一样调试死锁的人有帮助。

READ COMMITTED(默认)

共享锁在SELECT语句中获取，然后在SELECT语句完成时释放。这就是系统如何保证没有未提交数据的脏读。其他事务仍然可以在SELECT完成之后和事务完成之前更改基础行。

可重复读取

在SELECT中获取共享锁，然后仅在事务完成后才释放共享锁。这就是系统如何保证您读取的值在事务期间不会更改(因为它们在事务完成之前保持锁定)。

我对初始接受解的观察。

在RR下(默认mysql) -如果一个tx是打开的，一个SELECT已经被触发，另一个tx不能删除属于前一个READ结果集的任何行，直到前一个tx被提交(事实上，新的tx中的delete语句会挂起)，然而下一个tx可以毫无麻烦地删除表中的所有行。顺便说一下，上一个tx中的下一次READ仍然会看到旧数据，直到它被提交。

“读提交”是一种隔离级别，可确保当前已提交的任何数据都被读取。它只是限制读者看到任何中间的、未提交的、“脏”的读取。它不保证如果事务重新发出读取，会发现相同的数据，数据在读取后可以自由更改。

可重复读取是一种更高的隔离级别，除了保证读取提交级别外，它还保证任何读取的数据都不能更改，如果事务再次读取相同的数据，它将发现先前读取的数据仍在原地，没有变化，并且可以读取。

下一个隔离级别是可序列化的，它提供了更强的保证:除了所有可重复读取的保证之外，它还保证后续读取不能看到任何新数据。

假设你有一个表T，其中有一个列C，其中有一行，它的值是'1'。假设你有一个简单的任务，就像下面这样:

BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;

这是一个简单的任务，从表T中读取两次，两次之间的延迟为1分钟。

under READ COMMITTED, the second SELECT may return any data. A concurrent transaction may update the record, delete it, insert new records. The second select will always see the new data. under REPEATABLE READ the second SELECT is guaranteed to display at least the rows that were returned from the first SELECT unchanged. New rows may be added by a concurrent transaction in that one minute, but the existing rows cannot be deleted nor changed. under SERIALIZABLE reads the second select is guaranteed to see exactly the same rows as the first. No row can change, nor deleted, nor new rows could be inserted by a concurrent transaction.

如果你遵循上面的逻辑，你很快就会意识到SERIALIZABLE事务，虽然它们可能会让你的生活变得更容易，但总是完全阻塞每一个可能的并发操作，因为它们要求任何人都不能修改、删除或插入任何行。. net系统的默认事务隔离级别。事务范围是可序列化的，这通常解释了由此导致的糟糕性能。

最后，还有SNAPSHOT隔离级别。SNAPSHOT隔离级别提供了与可序列化性相同的保证，但不要求任何并发事务都不能修改数据。相反，它迫使每个读者看到自己版本的世界(自己的“快照”)。这使得编程非常容易，也非常可伸缩，因为它不会阻塞并发更新。然而，这种好处是有代价的:额外的服务器资源消耗。

补充阅读:

数据库引擎中的隔离级别 并发性的影响 选择基于行版本的隔离级别

请注意，repeatable read中的repeatable针对的是一个元组，而不是整个表。在ANSC隔离级别中，可能会发生幻象读取异常，这意味着使用相同的where子句读取表两次可能返回不同的返回不同的结果集。从字面上看，这是不可重复的。

这个老问题已经有了一个公认的答案，但我喜欢从如何改变SQL Server中的锁定行为的角度来考虑这两个隔离级别。这可能对那些像我一样调试死锁的人有帮助。

READ COMMITTED(默认)

共享锁在SELECT语句中获取，然后在SELECT语句完成时释放。这就是系统如何保证没有未提交数据的脏读。其他事务仍然可以在SELECT完成之后和事务完成之前更改基础行。

可重复读取

在SELECT中获取共享锁，然后仅在事务完成后才释放共享锁。这就是系统如何保证您读取的值在事务期间不会更改(因为它们在事务完成之前保持锁定)。

试图用简单的图表来解释这种怀疑。

读已提交:在此隔离级别中，事务T1将读取由事务T2提交的X的更新值。

可重复读取:在此隔离级别中，事务T1将不考虑事务T2提交的更改。