你真的明白数据一致性吗—— max(id) 破坏 Mysql 事务一致性

场景

业务中有一个日志表，插入数据与同步数据查询强依赖于主键的有序性

数据同步时携带上次同步更新的主键，查询到Max(id)之间的数据，只同步增量部分

意味数据只有一次同步机会

表结构如下

问题

Mysql 数据隔离级别是RR

讲道理，两个不同的事务来读取数据后一个事务 B 是无法读取的到先一个事务 A 数据的数据

但是我们这里有个逻辑很特殊Max(id)

这里有两个场景：

A先读，B后写

假设目前数据最后一条记录是3

A事务携带上次同步主键2来请求，Max(id) = 3

这时B事务前来写数据

A事务先于B事务，根据 Mysql MVCC 视图，查询到了id=2，id=3的数据

同时B事务，写入数据id=4，id=5

下次数据同步携带id=3，继续走，业务无误

图示：

A先写，B后读

假设目前数据最后一条记录是3

A事务开始写入4，5

事务还没有结束时，B携带2来读

期望同步2~3之间的数据，实际上却读到了2~5，但是时间上可读的数据还是1 2 3

这是为什么呢？

这就牵扯到了InnoDB 主键自增的规则了

InnoDB 的每个表的自增主键都，保存在内存中

偏移量：auto_increment_offset

步长：auto_increment_increment

默认双1

插入数据时获取该值，+后写入1

这个值不受MVCC事务一致性保护！！

测试方法

事务1:
BEGIN;
INSERT INTO t1 VALUES(null,1);

事务2：
SELECT max(id) from t1

事务1先通过Begin开始事务，后续每执行一次 insert 插入，事务2都能获取到最新的ID

就种情况就是对业务有损了！！

4 5 两条数据就被永远的丢失了，阿西吧！！！

天知道我查了多久啊！！！

图示：

解决方案

1.间隙锁

在数据同步查询前加上select max(1) from table for update;增加间隙锁

阻塞读写，但是会有性能瓶颈

注意：间隙锁的范围要控制好

BadCase

1.select * from table limit 1 for update;

本意是只想锁住(max-1,max](max,sumpernum]，减少锁间隙

但是忘记主键索引默认正向有序，这样其实是锁住了(-supernum,1](1,2]

正确的写法是：select * from table order by desc limit 1 for update;

2.select max(1) from table for update;

这种写法虽然满足了锁住表的要求，但是锁的是主键索引，也就是全表

当时考虑1会增加一次 Mysql 运算，希望节省性能，但是这样并发就下去了

2.分布式读写锁

以上的问题经过分析后都不是最好的方案，最后修改为分布式读写锁，具体方案见下一篇文章