不可思议的一致性读场景

偶尔会被问到，老叶你上课是不是很简单，只要一份教材在手就可以反复讲很多年，甚至会问，你上课是不是只要照着念PPT就行？

我呸，都什么年代了，怎么还有这种想法。哪怕是在应试教育著称的中小学里，也是每个学期都要更新备课材料的，怎么可能一份教案讲一辈子，无非是中小学的课程内容变化没那么快。在以知识更新日新月异的IT行业，居然还有人抱着这种思想，简直了。

抱怨归抱怨，今天我要说一个在上课过程中被同学们问倒（是真的把我问倒了）的一个案例。

先交代下运行环境：

# MySQL版本：8.0.17 under MacOS
[root@yejr.me]>\s
mysql  Ver 8.0.17 for macos10.14 on x86_64 (MySQL Community Server - GPL)

Connection id:      19
...
Server version:     8.0.17 MySQL Community Server - GPL

# 事务隔离级别：RR
[root@yejr.me]> select @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ         |
+-------------------------+

# 测试表结构及数据
[root@yejr.me]> SHOW CREATE TABLE t1\G
**************** 1. row ****************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `c1` int(11) NOT NULL,
  `c2` int(11) DEFAULT NULL,
  `c3` int(11) DEFAULT NULL,
  PRIMARY KEY (`c1`), -- c1列是主键
  KEY `c2` (`c2`)  -- c2列是辅助索引
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

[root@yejr.me]> select * from t1;
+----+------+------+
| c1 | c2   | c3   |
+----+------+------+
|  0 |    0 |    0 |
|  1 |    1 |    1 |
|  2 |    2 |    2 |
|  3 |    3 |    3 |
+----+------+------+

好，表演开始。

好，表演结束。相信看完后，你跟我的第一反应都是“握了个草，为毛会这样，这不科学”，可事实上的确如此，我再三测试了几次，都确认是这样的结果。后来我请教了下InnoDB核心开发者之一苏斌老师(苏斌老师之前在知数堂做过一次公开课分享，主题是 MySQL 8.0 InnoDB新特性)。一开始他也觉得这个案例不太可思议，后来经过查阅确认，认为这是符合一致性读的规则，看文档的解释：

A consistent read means that InnoDB uses multi-versioning to present to

简言之，上述文档说明了几点：

1. InnoDB利用MVCC机制保证在事务范围内任意时间点的一致性读需求（也就是：RR级别下，在同一个事务内任意时间点的一致性读，总是能读取到同样的数据）
2. RR级别下，是在发起第一个SELECT（不包含SELECT ... FOR UPDATE/FOR SHARE这种加锁读，以后另起一篇说这个事）时，创建的快照，因此能读取到在此之前已经提交的事务数据，在本事务之后修改的事务数据是看不到的
3. 上述第2条规则的一个例外场景时，能读取到在本事务内自己修改的数据。因此当在事务内更新完一条记录后发起SELECT可以读取到更新后的数据，同时也可能读取到旧版本的数据

在本案例中，由于两个session都是直接更新主键列，又由于InnoDB引擎的特殊性，主键列会被选择作为聚集索引。对InnoDB主键的更新是不能inplace的，需要新创建一条记录。因此对主键索引的更新时，相当于此时同一条记录在表内有两个版本，一个是更新前（该版本后续会被删除），一个是更新后的，然后等待提交。在session2中，第一次SELECT后创建了一个快照版本 [2,2,2]，而后的当前读可以读取到最新数据 [30,2,2]，因为sesison1已经提交，不会被阻塞。而session2中的更新，会在当前读的基础上进行更新，所以更新后的版本是 [31,2,2]，更新完毕后又再次进行一致性读，此时就可以看到新旧两个版本的数据了（因为旧版本对本事务而言，还在快照里）。本案例给我们的几点启示是

1. 当你想更新一条记录时，最好一开始就对其先加锁（SELECT ... FOR UPDATE），而后再在事务中进行更新，这样就可以避免被其他session给更新了。虽然一开始就加锁可能会造成更多的锁等待和死锁概率，但为了数据一致性，也必须如此了。或者，可以把事务隔离级别降为RC，这样每次SELECT总能看到已提交的最新版本
2. “永远”不要更新主键列
3. 想要做到第2点，就需要让主键列“只用作主键”，不具备业务属性，也即是我们一直强调的一个开发规范“每个InnoDB表都要有一个自增整型列做主键，且该列没有业务用途”

不知道我这样解释清楚了没有。InnoDB的这种做法，看起来像是合理的，但仔细想想又好像不太合理，我去提了个bug（#96205），但被拒了，囧...

Enjoy MySQL :)