文章目录
- 1 问题描述
- 2 验证
- 2.1 验证猜想1
- 2.2 验证猜想2
- 3 结论
- 4 mysql 为什么这么设计呢？
1 问题描述
创建一张表t，插入一行数据
mysql> CREATE TABLE `t` (
`id` int(11) NOT NULL primary key auto_increment,
`a` int(11) DEFAULT NULL
) ENGINE=InnoDB;
insert into t values(1,2);
现在表t中已经有id = 1，a=2这一行
执行更新语句，更新id=1这一样，将a的值修改为2（逻辑上值不变）
update t set a = 2 where id = 1;
可以看到返回结果，0 rows affected。
仅从现象上看，mysql在处理这个条sql语句时，可能是以下三种情况：
- 命令执行到server层返回，因为执行更新之前需要先读出数据，server层的执行器拿到id=1的这一行，发现a=2，于是不会调用InnoDB修改行字段的接口，直接返回。没加写锁
- 命令执行到Innodb层返回，server层调用了InnoDB修改行字段的接口，InnoDB对数据加上了写锁，然后进行当前读，读出最新的a的值是2，发现与旧值相同，于是不更新，直接返回。加了写锁，没执行更新
- InnoDB认真执行了修改操作，InnoDB对数据加上了写锁，然后进行当前读，读出最新的a的值是2，发现与旧值相同，但是还是执行了一次更新操作，将2赋值给a，然后记录到redo log中，经过两阶段提交，结束事务。也就是一个完整的，正常的更新过程
2 验证
2.1 验证猜想1
猜想1很好验证，如果没加写锁，让事务A和事务B并发的执行更新语句，如果后执行的事务没有被阻塞，则证明猜想1正确。
| 时间 | 事务A | 事务B |
|---|---|---|
| t0 | begin; | |
| t1 | begin; | |
| t2 | update t set a = 2 where id = 1; | |
| t3 | update t set a = 2 where id = 1; | |
| t4 | commit; | |
| t5 | commit; |
事务A
事务B
事务B的update语句被阻塞，等到事务A commit后才会提交。说明update过程中是加锁了的，猜想1不正确。
2.2 验证猜想2
猜想2是加锁，但是没有执行更新逻辑。可以采用InnoDB，MVCC机制来验证，MVCC就是在事务整个过程中会拿到一致性视图，对普通读进行复用，达到可重复读的隔离级别。
| 时间 | 事务A | 事务B |
|---|---|---|
| t0 | begin; | |
| t1 | select * from t where id = 1 // (1,2) | |
| t2 | begin; | |
| t3 | update t set a = 3 where id = 1; | |
| t4 | commit; | |
| t5 | select * from t where id = 1 // (1,2) | |
| t6 | commit; |
由于MVCC的机制，且InnooDB引擎默认设置的隔离级别是可重复度，所以事务A在开始的时候就会创建一致性视图，整个事务过程中进行复用。
所以，第一句select和第二句select查到的都是(1,2)，因为事务B的更新对事务A是不可见的。
接下来，我们对事务A再加一条更新的sql语句:
| 时间 | 事务A | 事务B |
|---|---|---|
| t0 | begin; | |
| t1 | select * from t where id = 1 // (1,2) | |
| t2 | begin; | |
| t3 | update t set a = 3 where id = 1; | |
| t4 | commit; | |
| t5 | update t set a = 3 where id = 1; | |
| t6 | select * from t where id = 1 // (1,3) | |
| commit; |
t5时刻，事务A执行了更新，更新语句是当前读，不是快照读，所以更新语句会读取到当前表中最新的数据，事务A读出来此时a=3，而自己要更新的也是3，旧值与要更新的新值相同，根据猜想2，事务A此次更新不会执行。也就是，InnoDB 的undo log中保留的行数据还是事务B更新的版本，而这个版本的更新是对事务A是不可见的，也就是后续的select语句读出来的结果应该还是(1,2)。但此时，事务A读出来的结果却是(1,3)。说明猜想2错误，InnoDB确实做了更新，并记录了undo log 和 redo log。
3 结论
mysql要更新一条行记录是，即使这条行记录的旧值与要更新的新值相同，mysql也会按部就班地进行更新。
4 mysql 为什么这么设计呢？
我想有以下几点原因：
- 数据一致性，InnoDB会按照用户要求的进行操作，即使这个操作显而易见地可以优化，比如要更新的值与旧值相同。这是为了保证数据一致性，如果让InnoDB决定哪些操作需要跳过，可能会导致数据不一致。
- 事务，因为update这条语句可能只是这个事务的其中一环，如果这个语句不按照正常的更新流程走，再发生事务回滚时，就回滚不了。
- 触发器，如果有表触发器，比如只要update执行了就触发的触发器，如果innodb自行跳过，这些触发器就不会执行。
