mysql replace into 生成全局唯一id遇到AUTO_INCREMENT回退的问题
一、背景
前两天，有同事反馈，调用我们这边的获取全局唯一ID的接口，得到了重复的id。
二、问题跟踪
查看接口日志，发现出现正确返回前，id是五万多，出问题的后，id突然下降到了301。两条相邻的日志如下：
Apr 20, 2022 @ 14:16:52.824
Apr 20, 2022 @ 14:28:01.198
这样看来，是在下午14：28, 生成的id就出现了异常，比上一个id差距非常大。
查看接口逻辑，是通过replace into 一直修改表里的一条记录，实现生成唯一id的逻辑，具体如下。
replace into的特性如下：
1、replace根据UNIQUE约束的字段(设置为Primary Key)，确定被替换的是哪一条记录。如果不存在要替换的记录， 那么就会插入一条新的记录。
2、replace语句会删除原有的一条记录， 并且插入一条新的记录来替换原记录。
再结合接口传参，sep一直传的是个定死的参数，且有唯一索引，那么接口是通过replace into来实现表里一直只存了一条记录，并且主键id会自增。 那么为啥出问题了呢？
由于以前从来没有使用过replace into, 直接在度娘查了下“replace into出现auto_increment回退”， 刚好看到这位大神的文章，跟我们的现象基本一模一样：INSERT ON DUPLICATE KEY UPDATE与 REPLACE 语句简介 | 五块的博客
从这位大神的经验，说是由于主从库切换直接引起这个问题，切换到从库的时候，从库的auto_increment同主库的不一致。
和DBA沟通后，确认我们当天下午14：19左右，腾讯云对此数据库进行了主从切换。
那么切换后，为啥会存在auto_increment不一致呢？我们来一起建个表看看
1、建表
2、插入一条数据，此时
此时的auto_increment:
3、执行 replace into pqj_text values(null,'a');
查看其auto_increment:
可以看到加1
如果从库更新时，也是执行replace into的话， auto_increment肯定和主库一模一样，但是现在出现了差异，那么从库执行的sql是咋样的呢？ 找到DBA给出binglog，发现是update,那么从库是执行的update语句。（下图binlog是引用的别的博主截图）
那么我们试试，直接执行update 语句，会更新auto_increment吗？
4、执行update
在刚刚的测试基础上，执行以下sql
update pqj_text
set id= 10
where sep='a'再来查看其auto_increment:
结果还是3！！没有增加。那么就能看出问题所在了。
当主库执行replace into ，主库的auto_increment一直在增加。
从库通过binlog里的update语句，一直在更新主键id, 但是auto_increment没有改变。
当主从切换后，会从以前的从库auto_incremant自增，导致生成了以前已经出现过的id！！！
三、解决办法
（未完待续）