MySQL基础篇-事务到底是隔离还是不隔离

数据库 评论

事务到底是隔离的还是不隔离的？

1
2
3
4
5
6
7
8

mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `k` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);

🌰：

图一

注意事务的启动时机，begin/start transaction命令并不是一个事务的起点，在执行到它们之后的第一操作InnoDB表的语句，事务才真正启动。如果你想马上启动一个事务，可以使用start transaction with consistent snapshot这个命令。

  • 第一种启动方式，一致性视图是在执行第一个快照读语句时创建的；
  • 第二种方式，一致性视图是在执行start transaction with consistent snapshot时创建的。

在这个🌰中，事务C没有显示的使用begin/commit，表示这个update语句本身就是一个事务，语句完成的时候会自动提交。事务B在更新了之后查询；事务A在一个只读事务中查询，并且时间顺序上是在事务B的查询之后。

这时事务B查到的K的值是3，而事务A查到的K的值是1。

MySQL里，有两个视图的概念：

  • 一个是view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果，创建视图的语法是create view，而它的查询方法和表一样。
  • 另一个是InnoDB在实现MVCC时用到的一致性读视图，即consistent read view，用于支持RC(Read committed,读提交)和RR(repeatable Read,可重复读)隔离界别的实现。

“快照”在MVCC里面是怎么工作的？

在可重复读隔离级别下，事务在启动的时候就是“拍了个快照”。这个快照是基于整库的

InnoDB里面每个事务有一个唯一的事务ID，叫做transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。

而每行数据也都是有多个版本的，每次事务更新数据的时候，都会生成一个新的数据版本，并切把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。

也就是说，数据表中的一行记录，其实可能有多个版本(row)，每个版本都有自己的row trx_id.


图二

图中虚线框里是同一行数据的4个版本，当前最新版本的V4，k的值是22，它是被transaction id 为25的事务更新的，因此它的row trx_id也是25.

图中三个虚线箭头，就是更新会产生undo log，V1，V2，V3并不是物理上真是存在的，而每次需要的时候根据当前版本和undo log计算出来的。

按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。

因此，一个事务只需要在启动的时候申明说，“以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认；如果是我启动以后才生成的，我就不认，我必须要找到它的上一个版本”。如果上一个版本不可见的话，那就继续往前找。如果是这个事务自己更新的数据，它自己还是要认的。

在实现上，InnoDB为每一个事务构造了一个数组，用来保存这个事务启动瞬间，当前已经启动但是没有提交的所有事务ID。

数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。

这个视图数组和高水位，就组成了当前事务的一致性视图(read-view)。

而数据版本的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果得到的。

这个视图数组把所有的row trx_id分成几种不同的情况。

图三
  1. 如果落在绿色部分，表示这个版本是已经提交的事务或者是当前事务自己生成的，这个数据是可见的。
  2. 如果落在红色部分，表示这个版本是由将来启动的事务生成，是肯定不可见的。
  3. 如果落在黄色部分，那就是有两种情况：
    • 若row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见；
    • 若row trx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见。

继续图一中的🌰：

假设：

  1. 事务A开始前，系统里面只有一个活跃事务ID是99；
  2. 事务A、B、C的版本号分别是100、101、102，且当前系统里面只有这四个事务；
  3. 三个事务开始前，（1，1）这行数据的row trx_id是90.

这样事务A的视图数组就是[99,100],事务B的视图数组是[99，100，101]，事务C的视图数组是[99，100，101，102]。

图四---事务A查询逻辑

第一个有效更新是事务C，把数据从（1，1）改成了（1，2）。这时数据的最新版本的row trx_id是102，而90这个版本已经称为了历史版本。

第二个有效更新是事务B，把数据从(1,2)改成(1,3)。这时数据的最新版本(row trx_id)是101，而102又变成了历史版本。

在事务A查询的时候，其实事务B还没有提交，但是它生成的(1,3)这个版本已经变成当前版本了。但是这个版本对事务A必须是不可见的，否则就办成脏读了。

事务A要读数据了，它的视图数组是[99,100]。读数据都是从当前版本读起的，所以事务A查询语句的读数据流程是这样的：

  • 找到(1,3)的时候，判断出row trx_id=101,比高水位大，处于红色区域，不可见；
  • 接着，找到上一个历史版本，row trx_id=102,比高水位大，处于红色区域，不可见
  • 再往前找，终于找到(1,1),它的row trx_id = 90，比低水位小，处于绿色区域，可见。

这样执行下来，虽然期间这一行数据被修改过，但是事务A不论在什么时候查询，看到这行数据的结果都是一致的，所以我们称之为一致性读。

一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：

  1. 版本未提交，不可见；
  2. 版本已提交，但是在视图创建之后提交的，不可见
  3. 版本一提交，而且是在事务视图创建前提交的，可见。

更新逻辑

更新数据都是先读后写的，而这个读，只能读当前的值，称为当前读。

因此 在更新的时候，当前读拿到的数据是(1,2),更新后生成了新版的数据(1,3)，这个新版本的row trx_id 是101.

所以执行事务B查询语句的时候，一般自己的版本号是101，最新数据的版本号也是101，是自己更新的，可以直接使用。

除了update语句外，select语句如果加锁，也是当前读

1
2
3
4
# 共享锁--S锁
select k from t where id=1 lock in share mode;
# 排她锁--X锁
select k from t where id=1 for update;

假设事务C不是马上提交，而是变成下面的事务C‘

这个时候主要考虑两阶段锁协议，事务C’没提交，也就说(1,2)这个版本上的写锁还没释放。而事务B是当前读，必须要读最新的版本，而且必须加锁，因此就被锁住了，必须等事务C’释放锁，才能继续她的当前读。

读提交的逻辑和可重复读的逻辑区别：

  • 可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里面的其他逻辑查询都共用这个一致性视图；

  • 读提交隔离级别下，每一个语句执行前都会重新计算出一个新视图。

  • 在读提交隔离级别下，start transaction with consistent snapshot 从这个语句开始，创建一个持续整个事务的一致性快照，就和start transaction 一样了。

Vincent Xin从零开始的程序猿之路

努力变瘦的胖子。