mysqldump跨库结构同步时默认保留AUTO_INCREMENT值，需加--skip-auto-increment（8.0.29+）或sed过滤；ALTER TABLE AUTO_INCREMENT=1仅在空表或设为大于当前最大值时生效；异构迁移须用--compatible=mysql57和--default-character-set=utf8mb4。
mysqldump 跨库结构同步时自增 ID 怎么不带过去
结构同步不带自增值，本质是避免目标库后续插入冲突——不是不能带，而是默认不带更安全。关键在 mysqldump 的参数组合。
-
--no-data只导出表结构（含CREATE TABLE），但默认仍会包含AUTO_INCREMENT=12345，这恰恰是你要剔除的 - 必须加
--skip-auto-increment（MySQL 8.0.29+）或用--set-gtid-purged=OFF --skip-triggers --skip-routines配合 sed 过滤（老版本） - 更稳妥的做法：先用
mysqldump --no-data --skip-auto-increment导出，再检查输出里是否还有AUTO_INCREMENT字样；若有，说明版本不支持，得用sed '/AUTO_INCREMENT/d'管道清理
ALTER TABLE MODIFY COLUMN 强制重置自增值的风险
有人想“同步完结构再统一清空自增”，用 ALTER TABLE t1 AUTO_INCREMENT = 1，但这个操作在有数据的表上实际无效——MySQL 只允许设为大于当前最大值的数，否则静默忽略。
- 执行
ALTER TABLE t1 AUTO_INCREMENT = 1后查SHOW CREATE TABLE t1，发现AUTO_INCREMENT没变，就是被忽略了 - 真正生效的前提是：表为空，或你明确知道当前最大 ID 是 99，才可设为 100
- 跨库同步后首次插入失败？大概率是目标表已有数据，而源库导出时没清空，又没删掉
AUTO_INCREMENT值，导致新插入撞了主键
异构迁移（比如从 MySQL 5.7 → 8.0）结构同步要注意什么
不只是自增，语法兼容性才是隐形地雷。MySQL 8.0 默认启用严格模式、sql_mode 更严，且 utf8mb4_0900_as_cs 排序规则不向下兼容。
- 导出时务必加
--compatible=mysql57，它会禁用 8.0 特有语法（如隐藏索引、角色语法） - 字符集要显式指定：
--default-character-set=utf8mb4，否则老版本 dump 可能用utf8（即utf8mb3），导入 8.0 会报错 - 如果源库用了
GENERATED COLUMN或JSON字段，确认目标版本支持；5.7 导入 8.0 一般没问题，反过来则大概率失败
用 pt-online-schema-change 同步结构是否绕过自增问题
不绕过。pt-osc 是在线改表工具，核心是建影子表 + 触发器同步数据，它本身不负责“跨库结构同步”，更不处理 AUTO_INCREMENT 的清理逻辑。
- 如果你用它在同实例内改表，自增值由原表决定，影子表会继承原表的
AUTO_INCREMENT值（通过CREATE TABLE LIKE） - 跨库场景下，pt-osc 根本不适用——它不支持指定目标实例，只作用于本地库
- 真要跨库+在线，得自己写逻辑：先 dump 结构（过滤掉 auto_inc）、再用
mysql -h dst导入、最后用pt-table-checksum校验结构一致性
最易被忽略的点：不同 MySQL 版本对 SHOW CREATE TABLE 输出中 AUTO_INCREMENT 的处理逻辑不一致，有的带，有的不带，有的带了但值是错的。别信文档，导出来看一眼最实在。
