日常 Bug 排查 - MVCC 和 for update 混用导致读数据不一致
前言
日常 Bug 排查系列都是一些简单 Bug 的排查。笔者将在这里介绍一些排查 Bug 的简单技巧,同时顺便积累素材。
Bug 现场
又是喜闻乐见的读数据不一致的问题。这次的问题是这样,业务在一个事务中更新 A 和 B 两个表的两个数据。但是在另一个事务中只看到了 A 的更新,而 B 依旧是更新之前的值。说好的原子性感觉又被打破了。如下图所示:
思路
在将这两个请求的 SQL 按照时序画出来的时候,笔者立马就明白了相关问题所在。核心就在于数据库是 RR 隔离级别的,同时业务在查询 A 的时候使用的是 Select for update,在查询 B 的时候使用的是普通的 Select。这么使用的原因可能是觉得所有的查询都需要先查 A 再查 B,那么只需要对 A 加锁就行,减少了数据库锁的数量。 但是,这里是有一个问题的,就是对 B 表的查询用的是普通的 Select,也就是使用了 MySQL 的 MVCC 机制。而 MySQL MVCC 的默认创建时刻就是事务的第一个不带 for update 的普通 Select (具体原理见笔者的博客 https://my.oschina.net/alchemystar/blog/1927425)。那么我们就可以从上面的 SQL 顺序可以看到,在事务 1 开始之前就已经创建了视图,此时的视图是 A1 和 B1。那么由于 RR,查询 B 表的普通 Select 看到的自然是 B1,而 select for update 不走 MVCC,于是看到的是 A2。如下图所示:
解决方案
让业务对 B 表的查询也用 Select for update 即可,相比于不一致增加的一点非热点行锁的性能可以忽略不计。
总结
MVCC 和数据库锁两者采用了不同的机制,如果不清楚其中的原理可能会导致不一致的现象出现。同时,在这次的问题中业务对于 B 表不用锁这样的优化实际上是一个负优化。这再次提醒我们,不要过早优化!