事务Isolation Level 例子详解

举例分析：

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

Read uncommitted:

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

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

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

 

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

Read committed

在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的。

 

因为read committed模式下Read 锁是会在读完后马上释放掉，这样的话，我们就不能保证一个事务中两次相同的查询的结果是一样的，因为数据可能被另外一个事务给修改掉。

举例说明：

还是两个事务 Trans1, Trans2.

Trans1: 读取第一条数据, 读取第一条数据.

Trans2: 修改A表中第一条数据A1->A11。

 

当trans1执行完第一步但还没开始第二部的时候,  trans2事务会修改A1->A11. 那样trans1中第二部读到的数据就跟第一步不一样了，要想解决这个问题就要参照Repeatable read模式了

Repeatable reads

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

 

Serializable

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

 

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