深入理解MySQL的事务隔离

1、什么是事务？

    数据库事务（简称：事务）是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作构成。

   要注意一下几点：

1.  首先，事务就是要保证一组数据库操作，要么全部成功，要么全部失败
2. 在MySQL中，事务是在引擎层实现的
3. 并不是所有引擎都支持事务，如MyISAM就不支持，InnoDB就支持

2、事务的属性

  原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）

1）原子性：操作这些指令时，要么全部执行成功，要么全部不执行。只要其中一个指令执行失败，所有的指令都执行失败，数据进行回滚，回到执行指令前的数据状态。

2）一致性：事务的执行使数据从一个状态转换为另一个状态，但是对于整个数据的完整性保持稳定。

3）隔离性：当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。

4）持久性：当事务正确完成后，它对于数据的改变是永久性的。

 

3、为什么需要隔离性？

     如果事务之间不是互相隔离的，可能将会出现以下问题。

1、脏读

        脏读（dirty read），简单来说，就是一个事务在处理过程中读取了另外一个事务未提交的数据。

        这种未提交的数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。

   举例：

    

2、不可重复读

   不可重复读（non-repeatable read），是指一个事务范围内，多次查询某个数据，却得到不同的结果。

  在第一个事务中的两次读取数据之间，由于第二个事务的修改，第一个事务两次读到的数据可能就是不一样的。

举例 ：

  

3、幻读

幻读（phantom read），是事务非独立执行时发生的一种现象。

例如事务 T1 对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务 T2 又对这个表中插入了一行数据项为“1”的数据，并且提交给数据库。

而操作事务 T1 的用户如果再查看刚刚修改的数据，会发现数据怎么还是 1？其实这行是从事务 T2 中添加的，就好像产生幻觉一样，这就是发生了幻读。

举例：

  

 

注意：

 脏读是某一事务读取了另外一个事务未提交的数据，不可重复读是读取了其他事务提交的数据。

幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。

 

4、事务的隔离级别

为了解决上面可能出现的问题，我们就需要设置隔离级别，也就是事务之间按照什么规则进行隔离，将事务隔离到什么程度。

首先，需要明白一点，隔离程度越强，事务的执行效率越低。

ANSI/ISO SQL 定义了 4 种标准隔离级别：

① Serializable（串行化）：花费最高代价但最可靠的事务隔离级别。 

“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

事务 100% 隔离，可避免脏读、不可重复读、幻读的发生。

② Repeatable read（可重复读，默认级别）：多次读取同一范围的数据会返回第一次查询的快照，即使其他事务对该数据做了更新修改。事务在执行期间看到的数据前后必须是一致的。

但如果这个事务在读取某个范围内的记录时，其他事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行，这就是幻读。

可避免脏读、不可重复读的发生。但是可能会出现幻读。

③ Read committed (读已提交)：保证一个事物提交后才能被另外一个事务读取。另外一个事务不能读取该事物未提交的数据。

可避免脏读的发生，但是可能会造成不可重复读。

大多数数据库的默认级别就是 Read committed，比如 Sql Server , Oracle。

④ Read uncommitted (读未提交)：最低的事务隔离级别，一个事务还没提交时，它做的变更就能被别的事务看到。

任何情况都无法保证。

再次总结

读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。
读已提交：别人改数据的事务已经提交，我在我的事务中才能读到。
可重复读：别人改数据的事务已经提交，我在我的事务中也不去读。
串行：我的事务尚未提交，别人就别想改数据。

这 4 种隔离级别，并行性能依次降低，安全性依次提高。

总的来说，事务隔离级别越高，越能保证数据的完整性和一致性，但是付出的代价却是并发执行效率的低下。

 

5、隔离级别的实现

 我们每一次的修改操作，并不是直接对行数据进行操作。

比如我们设置 id 为 3 的行的 A 属性为 10，并不是直接修改表中的数据，而是新加一行。

同时数据表其实还有一些隐藏的属性，比如每一行的事务 id，所以每一行数据可能会有多个版本，每一个修改过它的事务都会有一行，并且还会有关联的 undo 日志，表示这个操作原来的数据是什么，可以用它做回滚。

那么为什么要这么做？

因为如果我们直接把数据修改了，那么其他事务就用不了原先的值了，违反了事务的一致性。

那么一个事务读取某一行的数据到底返回什么结果呢？

取决于隔离级别，如果是 Read Committed，那么返回的是最新的事务的提交值，所以未提交的事务修改的值是不会读到的，这就是 Read Committed 实现的原理。

如果是 Read Repeatable 级别，那么只能返回发起时间比当前事务早的事务的提交值，和比当前事务晚的删除事务删除的值。这其实就是 MVCC 方式。

undo log

undo log 中存储的是老版本数据。假设修改表中 id=2 的行数据，把 Name='B' 修改为 Name = 'B2' ，那么 undo 日志就会用来存放 Name='B' 的记录，如果这个修改出现异常，可以使用 undo 日志来实现回滚操作，保证事务的一致性。

当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着 undo 链找到满足其可见性的记录。当版本链很长时，通常可以认为这是个比较耗时的操作。

何时删除？

在不需要的时候才删除。也就是说，系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除。

就是当系统里没有比这个回滚日志更早的 read-view 的时候。

 

6、长事务

直观感觉，一个事务花费很长时间不能够结束，就是一个长的事务，简称长事务（Long Transaction）。

长事务是数据库用户经常会碰到且是非常令人头疼的问题。长事务处理需要恰当进行，如处理不当可能引起数据库的崩溃，为用户带来不必要的损失。

根据上面的论述，长事务意味着系统里面会存在很老的事务视图。

由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的 undo log 都必须保留，这就会导致大量占用存储空间。

在 MySQL 5.5 及以前的版本，回滚日志是跟数据字典一起放在 ibdata 文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。

除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库，这个我们会在后面讲锁的时候展开。

因此，我们要尽量避免长事务。