Navicat结构同步仅识别索引存在性差异（增删）和笼统“修改”，不自动标出字段顺序、前缀长度、ASC/DESC等细节，须手动进入DDL比较面板查看标准格式定义才能确认真实变更。
navicat 能识别索引存在性差异（比如某索引在源库有、目标库无），但**不会自动标出字段顺序、前缀长度、asc/desc 排序方向等语义级变更**——这些必须手动点开 ddl 比较面板肉眼确认。
结构同步里“索引差异”只显示增删，不显示改
Navicat 的结构同步界面中，“操作类型”列只会把索引差异标记为 创建、删除 或 修改。但所谓“修改”，实际涵盖所有定义变化：字段顺序调换、加了前缀长度 col_a(10)、显式写了 DESC、甚至只是 USING BTREE 被省略——它全归为一条“修改”项，不拆解。
- 右键任意标为“修改”的索引 → 选
在 DDL 比较中查看，才能看到左右两边完整的KEY `idx_name` (...)定义 -
col_a(10)和col_a在 Navicat 看来是两个不同字段，即使业务上无区别；它不提供“忽略前缀长度”选项 - MySQL 5.7 及更早版本根本不支持
DESC索引排序，但 Navicat 仍会比对并标红——这属于误报风险点，需结合目标库版本判断是否真要处理
DDL 比较面板才是唯一可信依据
Navicat 解析原始 DDL 后，会统一转成标准格式输出，例如：
KEY `idx_user_email` (`email`(191), `created_at` DESC)
这个格式已过滤注释、缩进、大小写等干扰项，是语义比对的真实基础。但注意：
- 函数索引如
KEY ((UPPER(email)))必须两边写法完全一致（UPPERvsLOWER直接判为不一致），且函数体不支持高亮对比 - 如果源库用
user_id_2、目标库用fk_user_id，Navicat 不做语义推理，一律当“删除+新建”，而非重命名 - 字符集或排序规则（
COLLATE）变更会触发索引重建提示——这不是误报，因为utf8mb4_0900_as_cs和utf8mb4_unicode_ci确实影响索引用于ORDER BY的能力
跨版本比对时 invisible index 会引发误判
MySQL 8.0+ 支持 INVISIBLE 索引，但 MySQL 5.7 不识别该属性。若源库是 8.0、目标库是 5.7：
- Navicat 会把“可见性变化”当作索引定义变更，标为
修改 - 实际执行同步时，目标库会直接忽略
INVISIBLE关键字，但 Navicat 不预警 - 执行前务必检查目标库版本是否支持所有索引属性，否则生成的 SQL 可能语法错误或静默失效
ENGINE 不一致会导致索引被跳过或报错
索引类型依赖存储引擎：比如 FULLTEXT 只在 MyISAM 和 InnoDB 中有效，SPATIAL 仅限 MyISAM（MySQL 5.7+ InnoDB 也支持）。若两库表引擎不同：
- Navicat 可能将
FULLTEXT索引判定为“不存在”，或同步时报错Unknown storage engine - 比对前必须确认两边
SHOW CREATE TABLE中的ENGINE=一致，否则索引差异结论不可靠 - 尤其注意低版本迁移至 MySQL 8.0 时，
MyISAM表未显式转换引擎，其FULLTEXT索引可能无法被正确识别
最易被忽略的一点：Navicat 从不校验索引字段的实际数据分布是否支持该索引生效——比如对 TEXT 字段建普通索引却不设前缀长度，它照样标为“一致”，但 MySQL 运行时会报错。比对结果只是 DDL 层面的“看起来一样”。
