自增id冲突根本原因是多节点auto_increment步长未对齐；须配对设置increment（总节点数）和offset（各节点不同，1~increment间），否则仅设offset无效。
主从复制中自增ID冲突到底怎么发生的
根本原因不是“主库写、从库读”本身，而是多节点同时插入时 auto_increment 步长没对齐。比如主库设了 auto_increment_increment = 2，但两台主（双主）都用默认 auto_increment_offset = 1，结果都生成 ID 1、3、5……一同步就撞车。
常见错误现象：Duplicate entry 'X' for key 'PRIMARY'，尤其在从库 SQL 线程报错停摆；或者应用层插入返回成功，但查不到数据——其实是被从库的冲突回滚掉了。
- 双主架构下必须配对设置
auto_increment_increment和auto_increment_offset - 单主多从不用调
offset，只调主库的increment即可（从库不生成自增ID） - MySQL 8.0+ 的组复制（MGR）自动处理自增逻辑，但传统异步/半同步复制仍要手动配
怎么安全设置 auto\_increment\_offset 和 increment
假设你有 3 台 MySQL 节点（A/B/C），想支持任意两台可升为主库，就得让它们生成的自增ID完全不重叠。核心是：所有节点用相同 auto_increment_increment（步长），但各自 auto_increment_offset（起始偏移）不同。
实操建议：
-
auto_increment_increment设为总节点数，比如 3 台就设3 -
auto_increment_offset每台设不同值：A=1、B=2、C=3（范围必须在 1 到increment之间） - 修改后需重启 MySQL 或执行
SET PERSIST（MySQL 8.0+）或SET GLOBAL（临时生效） - 注意：已存在的表不受影响，新插入才走新规则；如果表已有自增字段值接近上限，先检查
SHOW CREATE TABLE里的AUTO_INCREMENT值是否会被跳过
示例（主库 A）：
SET PERSIST auto_increment_increment = 3; SET PERSIST auto_increment_offset = 1;
为什么不能只改 offset 不改 increment
只调 auto_increment_offset 没用——它只是“第一个值”，后续还是按默认步长 +1 递增，照样撞。比如 A 设 offset=1、B 设 offset=2，但两者 increment=1，A 插 1、2、3，B 插 2、3、4，冲突照旧。
关键逻辑：offset 定起点，increment 定间隔，二者必须配合。漏掉任一，等于白配。
- 常见误操作：运维只在 cnf 里加了
auto_increment_offset=2，忘了配auto_increment_increment - 验证是否生效：连接各节点执行
SELECT @@auto_increment_increment, @@auto_increment_offset; - 某些云厂商 RDS（如阿里云 MySQL）禁止修改
auto_increment_offset，得换用其它方案（如应用层分配ID、UUID、雪花算法）
调整后还要注意哪些隐性坑
参数生效只是第一步，真正上线前容易忽略的是数据一致性边界。
- 已有数据不会重排，如果某张表当前
AUTO_INCREMENT=100，而新规则下下一个值是 103（increment=3, offset=1），那中间 101、102 就永远空着——多数场景可接受，但做分库分表路由时可能出问题 -
mysqldump 导出再导入会重置
AUTO_INCREMENT值，若 dump 时没加--skip-auto-increment，可能把 offset 规则覆盖掉 - 使用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO时，即使没实际插入，自增值也会跳——这在 offset/increment 规则下更容易暴露间隙问题
最麻烦的其实是测试阶段：本地启两个 Docker 实例模拟双主，不连真实业务流量，光靠脚本压测很难复现低概率冲突，得人工构造并发插入+网络延迟来触发。
