主从切换后自增id冲突并非切换本身导致，而是因切换前未对齐auto_increment配置、未校准各节点auto_increment值、未封住从库误写路径所致；必须配对设置auto_increment_increment与offset，切换前在新主库执行alter table ... auto_increment = max(id)+1，并确保所有节点最大id已对齐。
主从切换后自增ID冲突，不是切换操作本身导致的，而是切换前没对齐配置、没校准值、没封住误写路径——只要漏掉其中一环，Duplicate entry 'X' for key 'PRIMARY' 就会准时报错。
为什么切换后立刻报 Duplicate entry？
新主库的 AUTO_INCREMENT 值仍沿用旧从库状态，而旧主库（现从库）可能已分配出更高 ID；一旦新主库开始插入，就大概率撞上旧主库里已存在的记录。这不是“同步延迟”问题，是两台机器各自维护一套不互通的计数器。
- MySQL 启动时用
SELECT MAX(id) + 1初始化自增值（5.7 及之前），不读 binlog，也不看对方状态 - 即使开了 GTID，
auto_increment_offset和auto_increment_increment仍完全独立，GTID 不管 ID 怎么生成 -
SHOW SLAVE STATUS显示Exec_Master_Log_Pos追平了，不代表自增 ID 已对齐——它根本不记录这个
必须配对设置 auto_increment_increment 和 auto_increment_offset
只改 offset 没用，必须和 increment 绑定使用，否则还是按默认步长 +1 递增，照样撞。
- 双节点：统一设
auto_increment_increment = 2，主库offset = 1（生成 1,3,5…），从库offset = 2（生成 2,4,6…） - 三节点双主可升场景：
increment = 3，三台分别设offset = 1/2/3，且offset必须在 1 到increment之间，否则 MySQL 启动时静默重置为 1 - 配置必须写进
my.cnf并重启生效；SET GLOBAL只影响新连接，复制线程可能还在用旧值
切换前必须手动校准新主库的 AUTO_INCREMENT 值
不能靠 mysqldump 导出参数或启动选项“自动修复”，它们只影响导入初始值，不更新表元数据里的当前计数器。
- 在目标从库（即将升主）上执行：
SELECT MAX(id) FROM tbl_name; - 取结果 +1，设为新值：
ALTER TABLE tbl_name AUTO_INCREMENT = N;（N 必须大于当前所有节点该表的最大 ID） - 确认生效：
SHOW CREATE TABLE tbl_name;查看AUTO_INCREMENT字段是否已更新 - 如果应用有跨库写入历史，得先查所有节点的
MAX(id)，取最大值再 +1，不能只看本机
最容易被忽略的三个点
很多团队配了 offset/increment、也做了校准，还是踩坑，往往栽在这三个地方：
-
innodb_autoinc_lock_mode没锁死：双主必须设为0（传统模式），否则INSERT SELECT或批量导入会跳号，错开逻辑失效 - 没关
log_slave_updates：从库不记 relay log 到本地 binlog，双向复制断裂，GTID 无法启用，工具校验失灵 - 误写从库没封住：应用层直连、监控脚本、定时任务、DBA 手动 INSERT 都可能往从库写，哪怕只写一次，ID 序列就乱了
