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