本文通过一个事故案例，讲述了MySQL自增ID异常增长的原因，涉及REPLACE INTO和INSERT ... ON DUPLICATE KEY UPDATE ...两条SQL语句的影响，以及innodb_autoinc_lock_mode参数的作用。作者分析了问题并提出了两种解决方案：修改业务逻辑或更改表结构。
点击关注，快速进阶高级架构师
作者：燕南飞Liam
引言
小A正在balabala写代码呢，DBA小B突然发来了一条消息，“快看看你的用户特定信息表T，里面的主键，也就是自增id，都到16亿了，这才多久，在这样下去过不了多久主键就要超出范围了，插入就会失败，balabala......”
我记得没有这么多，最多1k多万，count了下，果然是1100万。原来运维是通过auto_increment那个值看的，就是说，表中有大量的删除插入操作，但是我大部分情况都是更新的，怎么会这样？
问题排查
这张表是一个简单的接口服务在使用，每天大数据会统计一大批信息，然后推送给小A，小A将信息更新到数据库中，如果是新数据就插入，旧数据就更新之前的数据，对外接口就只有查询了。
很快，小A就排查了一遍自己的代码，没有删除的地方，也没有主动插入、更新id的地方，怎么会这样呢？难道是小B的原因，也不太可能，DBA那边儿管理很多表，有问题的话早爆出来了，但问题在我这里哪里也没头绪。
小A又仔细观察了这1000多万已有的数据，将插入时间、id作为主要观察字段，很快，发现了个问题，每天第一条插入的数据总是比前一天多1000多万，有时候递增的多，有时候递增的少，小A又将矛头指向了DBA小B，将问题又给小B描述了一遍。
小B问了小A，“你是是不是用了REPLACE INTO ...语句”，这是怎么回事呢，原来REPLACE INTO ...会对主键有影响。
REPLACE INTO ...对主键的影响
假设有一张表t1:
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
