好险！一入职，就遇到MySQL这么大Bug！差点背锅走人...

发布时间：2025-11-04 07:47:36 来源：创站工坊 作者：人工智能

今年这种情况，好险有时候不找好下家还真不敢跳，入职人这不，大点背前段时间刚跳到新东家，锅走刚办入职那天，好险就遇上事了，入职人真的大点背是吓出一身冷汗（老大一直盯着我，说要快速解决这个问题），锅走差点被（背）开（锅）了....

情况如何？好险且听我下面慢慢道来！！入职人！大点背希望对大家有所帮助与借鉴。锅走

问题描述

线上有个重要Mysql客户的好险表在从5.6升级到5.7后，master上插入过程中出现"Duplicate key"的入职人错误，而且是大点背在主备及RO实例上都出现。

以其中一个表为例，迁移前通过“show create table” 命令查看的auto increment id为1758609， 迁移后变成了1758598,实际对迁移生成的新表的自增列用max求最大值为1758609。

用户采用的是Innodb引擎，而且据运维同学介绍，之前碰到过类似问题，重启即可恢复正常。

内核问题排查

由于用户反馈在5.6上访问正常，切换到5.7后就报错。云南idc服务商因此，首先得怀疑是5.7内核出了问题，因此第一反应是从官方bug list中搜索一下是否有类似问题存在，避免重复造车。经过搜索，发现官方有1个类似的bug，这里简单介绍一下该bug。

背景知识1

Innodb引擎中的auto increment 相关参数及数据结构。

主要参数包括：innodb_autoinc_lock_mode用于控制获取自增值的加锁方式，auto_increment_increment， auto_increment_offset用于控制自增列的递增的间隔和起始偏移。

主要涉及的结构体包括：数据字典结构体，保存整个表的当前auto increment值以及保护锁；事务结构体，保存事务内部处理的行数；handler结构体，保存事务内部多行的循环迭代信息。

背景知识2

mysql及Innodb引擎中对autoincrement访问及修改的流程

从我们的实际业务流程来看，我们的错误只可能涉及insert及update流程。 

此时，首次插入时，write_row流程会调用handler::update_auto_increment来设置autoinc相关的信息。首先通过ha_innobase::get_auto_increment获取当前的autoincrement的值(即max(id) + 1)，并根据autoincrement相关参数修改下一个autoincrement的值为next_id。

当auto_increment_increment大于1时，max(id) + 1 会不大于next_id。handler::update_auto_increment获取到引擎层返回的值后为了防止有可能某些引擎计算自增值时没有考虑到当前auto increment参数，会重新根据参数计算一遍当前行的自增值，由于Innodb内部是考虑了全局参数的，因此handle层对Innodb返回的自增id算出的自增值也为next_id，即将会插入一条自增id为next_id的行。

handler层会在write_row结束的时候根据当前行的值next_id设置下一个autoincrement值。如果在write_row尚未设置表的下一个autoincrement期间，有另外一个线程也在进行插入流程，那么它获取到的自增值将也是next_id。这样就产生了重复。

通过上述分析，这个bug仅在autoinc_lock_mode > 0 并且auto_increment_increment > 1的情况下会发生。实际线上业务对这两个参数都设置为1，因此，可以排除这个bug造成线上问题的可能性。

现场分析及复现验证

既然官方bug未能解决我们的问题，那就得自食其力，从错误现象开始分析了。

(1) 分析max id及autoincrement的规律 由于用户的表设置了ON UPDATE CURRENT_TIMESTAMP列，因此可以把所有的出错的表的max id、autoincrement及最近更新的几条记录抓取出来，看看是否有什么规律。抓取的信息如下：

乍看起来，这个错误还是很有规律的，update time这一列是最后插入或者修改的时间，结合auto increment及max id的值，现象很像是最后一批事务只更新了行的自增id，没有更新auto increment的值。

联想到【官方文档】中对auto increment用法的介绍，update操作是可以只更新自增id但不触发auto increment推进的。按照这个思路，我尝试复现了用户的现场。复现方法如下：

同时在binlog中，我们也看到有update自增列的操作。如图：

不过，由于binlog是ROW格式，我们也无法判断这是内核出问题导致了自增列的变化还是用户自己更新所致。因此我们联系了客户进行确认，结果用户很确定没有进行更新自增列的操作。

那么这些自增列到底是怎么来的呢？

(2) 分析用户的表及sql语句 继续分析，发现用户总共有三种类型的表 

这三种表都有自增主键。

但是前面两种都出现了autoinc错误，唯独hz_freeze_balance_sharding表没有出错。难道是用户对这两种表的访问方式不一样？抓取用户的sql语句，果然，前两种表用的都是replace into操作，最后一种表用的是update操作。难道是replace into语句导致的问题？搜索官方bug, 又发现了一个疑似bug。 

原因：

因此在slave机上就会出现max(id)大于autoincrement的情况。此时在ROW模式下对于insert操作binlog记录了所有的列的值，在slave上回放时并不会重新分配自增id，因此不会报错。但是如果slave切master，遇到Insert操作就会出现”Duplicate key”的错误。

解决方案

业务侧的可能解决方案：

内核侧可能解决方案：

心得

只有这样才能在找官方bug时精准的匹配场景，如果官方没有相关bug，也能通过已有线索独立分析。 

相关文章