MySQL事务隔离：为何你的修改我无法即时察觉

文章标题：

MySQL事务隔离：探寻修改为何无法即时被感知

文章内容：事务的关键在于保证一组数据库操作要么全部达成，要么全部落空。在MySQL里，事务支持是在引擎层来实现的，这也是InnoDB取代MyISAM的重要缘由之一。

隔离性与隔离级别

事务具备原子性、一致性、隔离性、持久性这四大特性。本文重点探讨隔离性。

当数据库上有多个事务同时运行时，可能会出现脏读、不可重复读、幻读这类状况，为了解决这些问题，就产生了隔离级别的概念。

SQL标准所规定的事务隔离级别包含以下四种：

• 读未提交：一个事务还未提交时，它所做的变动就能被其他事务观察到。

• 读已提交：一个事务提交之后，它所做的变动才会被其他事务发现。

• 可重复读：一个事务在执行过程中看到的数据，始终和该事务启动时看到的数据保持一致。

• 串行化：对于同一行记录，写操作会添加写锁，读操作会添加读锁，当出现锁冲突时，后续访问的事务得等待前一个事务执行完毕才能继续执行。

下面通过举例来阐释隔离级别。假设有两个事务，它们的行为时间顺序如下：

那么在不同的隔离级别下，事务A的查询结果为：

• 读未提交：事务B的修改能被A看到，所以V1=V2=V3=2。

• 读已提交：事务B的修改在提交后才会被A看到，因此V1=1，V2=V3=2。

• 可重复读：事务A在执行过程中看到的数据，和事务A启动时看到的一样，所以V1=V2=1。由于之后事务A提交了，所以V3=2。

• 串行化：事务B想要修改时会被锁住，直到事务A提交。所以V1=V2=1，V3=2。

在实现上，数据库中会创建一个视图，访问时以该视图的逻辑结果为准。在可重复读隔离级别下，视图是在事务启动时创建的，整个事务期间都使用同一个视图。在读已提交隔离级别下，每个SQL语句开始执行时都会创建一个视图。

事务隔离的实现

接下来，详细说明可重复读的实现。

在MySQL中，实际上每条记录在更新时都会同时记录一条回滚操作。通过回滚操作，记录上的最新值能够回溯到之前的状态。假设一个值从1依次变成了2、3、4，那么回滚日志是这样的：

当前值是4，但在查询时，不同时刻启动的事务有着不同的read view，所以看到的值并不一定是当前值。同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。

MVCC能够实现隔离性，从上面可以看出，即便现在有另外的事务正在把4改成5，这个事务也不会对read view A、B、C对应的事务产生影响。

回滚日志并非一直保留，当系统判断没有事务再需要用到这些回滚日志时，回滚日志就会被删除。具体来说，当系统里没有比这个回滚日志更早的read view时，就会删除，这等同于系统中不存在任何read view的min_trx_id比回滚日志所属事务的trx_id小。

基于以上实现，我们建议尽量不要使用长事务，因为长事务意味着系统里存在很旧的事务视图，那么在该事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这会占用大量存储空间。除此之外，长事务还会占用锁资源，有可能拖垮整个库。

可以在infomation_schema库的innodb_trx表查询长事务，比如下面的语句，用于查找持续时间超过60秒的事务：

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

事务的启动方式

最后讲讲事务的启动方式。MySQL事务启动方式有以下几种：

• 显式启动。语句是begin或start transaction，配套的提交语句是commit，回滚语句是rollback。

• set autocommit=0，该命令会将线程的自动提交关闭。这意味着如果只执行一个select语句，这个事务就会启动，但不会主动提交。事务会一直存在直到主动提交或回滚，或者连接断开。

有些客户端连接框架默认连接成功后就先执行set autocommit=0，这就导致接下来的查询都在事务中，可能会导致无意的长事务。因此，建议显式启动。