03 | 事务隔离：为什么你改了我还看不见？

MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。

提到事务，肯定会想到ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性），这儿主要讲“隔离性”。

 

隔离级别包括：读未提交、读提交、可重复度、串行化。

读未提交：一个事务还没提交，它做的变更就能被别的事务看到。

读提交：一个事物提交之后，它做的变更才会被其他事务看到。

可重复度：一个事物执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复度隔离级别下，未提交更变对其他事务也是不可见的。

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

 

实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。

“可重复度”隔离级别下，这个视图是在事务启动的时候创建的，整个事务存在期间都在用这个视图。

“读提交”隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。

“读未提交”隔离级别下直接返回记录上的最新值，没有视图的概念。

“串行化”隔离级别下直接用加锁的方式来避免并行访问。

 

注意：Oracle的默认隔离级别是“读提交”，因此对于一些从Oracle迁移到MySQL的应用，为保证数据库隔离级别的一致，一定要记得将MySQL的隔离级别设置为“读提交”（配置方式是将启动参数transaction-isolation的值设置成READ-COMMITTED。可以用show variables来查看当前的值）。

 

事务隔离的实现：

假设一个值从1被按顺序改成了2、3、4，在回滚日志里面就会有类似下面的记录：

当前值是4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的read-view。如图中看到的，在视图A/B/C里面，这个记录的值分别是1/2/4，同一条记录在系统中可以存在多个版本，就是数据库的多版本控制。

同时你会发现，即使现在有另外一个事务正在将4改成5，这个事务跟read-view A/B/C对应的事务是不会冲突的。

什么时候删除回滚日志？答案是，在不需要的时候才删除。也就是说，系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志才会被删除。那什么时候才不需要了呢？就是当系统里没有比这个回滚日志更早的read-view的时候。

为什么不建议使用长事务，因为长事务意味着系统里面会村很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录必须保留，这就会导致占用大量存储空间。   除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库。

事务的启动方式

1、显式启动事务语句：begin或start transaction。配套的提交语句是commit，回滚语句是rollback。

2、set autocommit=0，这个命令会将这个线程的自动提交关掉。意味着如果你执行一个select语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在知道你主动执行commit或rollback，或者断开连接。

有些框架会默认连接成功后先执行一个set autocommit=0的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。因此，建议总是使用set autocommit=1,通过显式语句的方式来启动事务。

在autocommit为1的情况下，用begin显式启动的事务，如果执行commit则提交事务。如果执行commit work and chain,则是提交事务并自动启动下一个事务，这样也省去了再次执行begin语句的开销。同时带来的好处是从程序开发的角度明确的知道每个语句是否处于事务中。

可以在information_schema库的innodb_trx这个表中查询长事务，比如下面个语句，用于查找持续时间超过60s的事务:

SELECT * FROM information_schema.INNODB_TRX t WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started));

 

上一篇：02 | 日志系统：一条SQL更新语句是如何执行的

下一篇：04 | 深入浅出索引（上）