必须在首次启动前配置auto_increment_increment和auto_increment_offset，因为MySQL 8.0启动时复制线程即按配置文件初始化计数器，运行时SET GLOBAL修改无效，且binlog已按旧规则生成ID，同步必报ERROR 1062主键冲突。
必须在首次启动前就配好 auto_increment_increment 和 auto_increment_offset，否则后续补配等于重做整套双主初始化——因为 MySQL 8.0 的自增值一旦写入系统表，运行时修改 SET GLOBAL 不影响已加载的复制线程和表计数器。
为什么不能等上线后再改步长
MySQL 8.0 启动时，复制线程会立即读取配置文件里的 auto_increment_increment 和 auto_increment_offset 值来初始化内部计数器；之后所有 INSERT 都基于该初始状态推进。运行时执行 SET GLOBAL auto_increment_increment = 2 看似成功，但新连接仍可能沿用旧序列，且 binlog 里记录的自增 ID 已按旧规则生成，同步到对端必然撞 ERROR 1062 (23000): Duplicate entry。
- 重启 mysqld 是唯一生效方式，
systemctl reload mysqld或SIGHUP无效 - 即使只有一台先启、另一台后启，只要没统一配 offset+increment，第一次并发插入就可能冲突
- 若已建库建表，仅改全局变量无法修正表级
AUTO_INCREMENT值，需额外ALTER TABLE ... AUTO_INCREMENT = N对齐
双主节点怎么配才真正错开序列
不是“A 设 1、B 设 2”就行，而是必须满足：两节点 auto_increment_increment 相同，auto_increment_offset 互异且落在不同模余类中。例如双主场景下：
- A 节点：
auto_increment_increment = 2+auto_increment_offset = 1→ 实际生成 1, 3, 5, 7…（所有奇数） - B 节点：
auto_increment_increment = 2+auto_increment_offset = 2→ 实际生成 2, 4, 6, 8…（所有偶数） - 若 A 设了
offset = 1却漏设increment = 2，它仍从 1 开始以步长 1 插入，和 B 完全重叠
验证方法：连上各节点，执行 SELECT @@auto_increment_increment, @@auto_increment_offset;，必须看到预期值；再建空表插入一行，查 SHOW CREATE TABLE t 中的 AUTO_INCREMENT= 是否符合模运算逻辑（即 (next_id - offset) % increment == 0）。
除了步长，还有三个参数必须同步配齐
只调自增参数，就像给车装了防撞梁却不装刹车——能防一次碰撞，挡不住连续事故。以下三项缺一不可：
-
innodb_autoinc_lock_mode = 0：双主下必须关掉优化锁模式，否则INSERT INTO t SELECT类批量操作可能跳号，导致后续单行插入撞序列 -
log_slave_updates = ON：关闭它，B 收到 A 的变更后不会写 binlog，双向复制断裂，GTID 失效，校验工具全瘫 -
server-id全局唯一（如 A=1、B=2）且replicate-same-server-id = 0：否则 A→B→A 回环，同一事务被反复执行，ID 冲突只是表象，数据逻辑早已错乱
已有数据时，表级 AUTO_INCREMENT 值怎么安全对齐
迁移或 dump/reload 后，表的 AUTO_INCREMENT 值常卡在旧偏移位置，和新步长规则不兼容。比如 A 节点设了 offset=1/increment=2，但 SHOW CREATE TABLE 显示 AUTO_INCREMENT=100（偶数），下一条插入就是 100，直接撞 B 的序列。
- 先查当前最大 ID：
SELECT MAX(id) FROM your_table - 按公式算下一个合法值：向上取整到满足
(N - offset) % increment == 0的最小N > MAX(id) - 停写全集群后执行：
ALTER TABLE your_table AUTO_INCREMENT = N - 注意：该语句本身会触发自增值落盘，但若中间有并发 INSERT，可能被覆盖，务必确保无写入
最易被忽略的是：MySQL 8.0 的自增值是持久化的，但它只在 INSERT 或 ALTER 后更新；你看到的 AUTO_INCREMENT 值，是磁盘里存着的那个，不是靠 MAX(id) 算出来的——所以别信 information_schema.tables.auto_increment，只信 SHOW CREATE TABLE 输出。
