Navicat结构同步本身不会修改auto_increment_increment，该值异常系目标库自身配置被人为或脚本更改所致；需通过SELECT @@auto_increment_increment等命令核查，并注意innodb_autoinc_lock_mode影响分配行为。
Navicat结构同步后自增步长异常，先查 auto_increment_increment
navicat 结构同步本身不会修改 mysql 的全局或会话级自增步长变量，所以目标库 auto_increment_increment 变了，基本可以断定不是 navicat 同步操作导致的，而是目标库自身配置被人为或脚本改过。常见错误现象是：同步后插入新记录，id 跳着增长（比如 1→101→201），而不是 +1。
auto_increment_increment 和 auto_increment_offset 是 MySQL 的服务器变量，影响所有 AUTO_INCREMENT 列的生成逻辑。它们默认都是 1，但一旦被设为其他值（如主从架构中为避免冲突常设为 2），就会全局生效。
- 查当前值用：
SELECT @@auto_increment_increment, @@auto_increment_offset; - 检查是否被临时会话修改过：
SHOW VARIABLES LIKE 'auto_increment%';（注意区分GLOBAL和SESSION） - 如果发现值异常（比如
auto_increment_increment = 10），说明目标库被单独调优或误配过，和 Navicat 无关
为什么 Navicat 同步预览里看不到步长变更？
因为 Navicat 的结构同步只比对表定义（CREATE TABLE 语句能表达的部分），而 auto_increment_increment 属于服务器运行时状态，不在 DDL 范围内，也不会出现在任何表结构差异列表或生成的 SQL 中。
- 即使你勾选了「Compare auto-increment value」，它比的也只是表元数据里的当前
AUTO_INCREMENT=xxx值（即计数器起点），不是步长 - 所以你在同步预览窗口里永远看不到
SET GLOBAL auto_increment_increment = 2这类语句——它根本就不会生成
目标库步长被改了，同步前怎么快速兜底？
如果你无法确认目标库步长是否可靠，又必须做结构同步，建议在同步前加一层防御性检查：
- 在 Navicat 执行同步前，先手动连目标库执行：
SET SESSION auto_increment_increment = 1; SET SESSION auto_increment_offset = 1;
- 这样能确保本次会话创建/修改表时，生成的
AUTO_INCREMENT计数器行为是标准的（+1） - 注意：
SESSION级设置只对当前连接有效，不影响其他连接，也不改变GLOBAL值 - 如果目标库是生产环境且已配置非 1 步长（如双主写入场景），不要强行改
GLOBAL，而应接受该设定，并在应用层适配 ID 分布逻辑
容易忽略的细节：MySQL 8.0+ 的 innodb_autoinc_lock_mode
即使步长是 1，innodb_autoinc_lock_mode 设置不同也会让“看起来像步长变”的现象出现：
innodb_autoinc_lock_mode = 0（传统模式）：简单 INSERT 严格按顺序分配，ID 连续innodb_autoinc_lock_mode = 2（交错模式，MySQL 8.0 默认）：批量 INSERT（如INSERT ... SELECT）可能预分配大段 ID，导致空洞、跳号，不是步长变了，而是分配策略变了查这个值：
SELECT @@innodb_autoinc_lock_mode;它不参与 Navicat 结构同步，但会影响同步后首次批量插入的行为表现
如果你依赖连续 ID 做业务逻辑（比如分页、导出序号），不能只盯着
auto_increment_increment，还得确认这个锁模式是否一致
真正决定同步后 ID 行为的，从来不是 Navicat 的某个开关，而是目标库那几个藏在 SHOW VARIABLES 里的全局参数。
