我们有A表, 包含两条数据。

假设我们有两个事务 Trans1， Trans2. 它们的操作如下：

Trans 1: 更新A1 -> A11, 然后更新A2 -> A22.

Trans 2: 读取A表中的第一条数据.

 

当trans1执行完第一步但还没开始第二部的时候，trans2开始读取A表中的第一条数据，这时trans2读到的值是A11. 但是这样带来的风险就是如果trans2在执行第二步的时候出错，那A11会回滚变成A1. 也就是说trans2 读到是trans1还没有提交事务的数据（脏数据）。

在Read Committed Level下， 我们能避免 read uncommitted提到脏数据的问题。

还是两个事务 Trans 1, Trans 2. 它们的操作如下：

Trans 1: 更新A1 -> A11, 读取A2.

Trans 2: 读取A表中第一条数据。

 

当trans1执行完第一步更新A1->A11还没开始第二步的时候， trans2开始读取A表中的第一条数据， 这时trans2是读取不到数据的. 因为Trans1已经对A1施加了write锁，write锁是贯穿整个事务的。别的事务要想访问A1, 必须等到trans1执行完把锁释放掉才可以。那样trans2会等到trans1事务执行完读取到值A11。

 

但是在read committed模式下Read 锁是会在读完后马上释放掉的

Trans1: 读取A2，更新A2 -> A22。

Trans2: 更改A2->A22。

 

当trans1读完A2还没开始第二步的时候， trans2开始修改A2->A22. 因为在Read committed模式下， 读取锁会在读完后立马释放掉，所以trans2是可以修改A2的。

 

Repeatable reads模式很好的解决掉了Read committed多次读取数据不一致的问题，因为在这种level下， read 锁跟 write锁一样是要贯穿整个transaction, 而不是使用完就释放掉。 但是它不能解决新插入的数据，新插入的数据没有进行锁限制。 也就是所Repeatable read模式能保证在一个事务中多次相同查询读取的老数据内容是一样的但是数据条数不一定一样。 因为可能另外一个事务会在两次读取中间插入新的数据。

 

Serializable是最严格的锁，它保证的一个事务中多次相同查询读取的数据是一样的，条数也是一样的。

 

注意： 锁越严格，性能就会越差，在真正的项目中，我们要根据我们的需求，选在合适的level. 找到平衡点。