最稳妥方式是查询information_schema.TABLES获取AUTO_INCREMENT值，它表示下一条插入将使用的ID；备份后需用ALTER TABLE重置该值以避免ID冲突，但连续性无法保障。
MySQL 中如何安全读取并备份 AUTO_INCREMENT 当前值
直接查 information_schema 是最稳妥的方式，但要注意表名大小写和权限问题。很多同学用 show create table 解析建表语句来“猜”当前值，结果在分区表或 alter 过的表上出错——因为 create table 里写的只是初始值，不是实时值。
正确做法是查系统表：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = '<code>your_db_name</code>' AND TABLE_NAME = '<code>your_table_name</code>';
-
AUTO_INCREMENT字段返回的是**下一条插入将使用的 ID 值**，不是最大已用 ID - 必须有
SELECT权限访问information_schema.TABLES，部分云数据库（如阿里云 RDS）默认禁用该权限，需单独申请 - 查询结果可能为
NULL（比如 MyISAM 表未设自增，或表被 TRUNCATE 后尚未插入），要判空处理
备份后如何恢复 AUTO_INCREMENT 值（避免主键跳跃）
不能靠 INSERT ... SELECT 或导出 SQL 再导入来“自然延续”，因为导入时若没显式指定 INSERT INTO ... VALUES 的 ID，MySQL 会按当前 AUTO_INCREMENT 值分配，导致跳号。真正可控的方式只有重置：
ALTER TABLE <code>your_table_name</code> AUTO_INCREMENT = <code>12345</code>;
- 目标值必须**大于等于表中现有最大主键值 + 1**，否则执行成功但下次插入仍从原值开始（MySQL 不校验合理性）
- 该语句会触发表重建（InnoDB）或锁表（MyISAM），线上大表慎用；建议在低峰期执行
- 如果表有外键引用，且关联字段也依赖连续性，仅改
AUTO_INCREMENT不够，还得同步检查外键约束是否允许后续插入
为什么“保障主键连续性”本身是个危险目标
连续性不是 MySQL 的设计契约，而是业务误读。只要不手动 DELETE 中间行、不用 REPLACE 或 INSERT ... ON DUPLICATE KEY UPDATE，ID 就天然递增；但连续性会在以下场景必然破坏：
- 事务回滚：
INSERT分配了 ID，但事务失败，ID 已消耗 - 批量插入时部分失败：
INSERT INTO ... VALUES (1),(2),(3)中第 2 条违反唯一约束，第 3 条仍会用 ID=3 - 主从切换或 GTID 模式下，备库重放时可能跳过某些事件
强行用 SELECT MAX(id)+1 然后 INSERT ... VALUES 来“续号”，会引发并发冲突和性能瓶颈——这不是备份问题，是架构反模式。
真正需要备份 AUTO_INCREMENT 值的典型场景
只在两类操作前必须记录当前值：一是全量迁移（比如从旧库导出再导入新库），二是做逻辑删改表结构（如拆分字段、加索引）后重建表。此时你不是为了“连续”，而是防止新表起始 ID 覆盖旧数据。
- 导出时记下
AUTO_INCREMENT值，导入后立刻执行ALTER TABLE ... AUTO_INCREMENT = <原值> - 用
mysqldump --single-transaction --skip-auto-increment可避免 dump 文件里硬编码AUTO_INCREMENT，但恢复时仍需手动补 - 如果用
pt-online-schema-change改表，它会自动继承原表的AUTO_INCREMENT值，无需额外备份
连续性没法靠备份 ID 值来“保障”，能做的只是迁移前后别让新 ID 和旧数据撞车。别的都是徒劳。
