Navicat结构同步能识别索引增删改，但默认不展开字段顺序、唯一性等细节，需手动进入DDL比较面板查看；索引名不同即视为删除+新建，不推理语义等价性。
结构同步比对会显示索引增删改，但默认不展开索引细节
navicat 17 的结构同步（工具 → 结构同步）能识别索引层面的差异，比如某张表在源库有 idx_user_email，目标库没有，就会标为“创建”；反之标为“删除”。但它**不会默认把索引字段顺序、是否唯一、是否前缀索引等差异单独列成一条可点击项**——这些信息藏在 ddl 比较面板里，需要手动点开看。
常见误判场景：两个索引名不同但逻辑等价（如 user_id_2 vs fk_user_id），Navicat 一律视为“删除+新建”，而不是“重命名”。它只比对象存在性与定义一致性，不推理语义。
- 执行结构同步前，确保两个库中对应表的
ENGINE一致（比如都是InnoDB），否则索引类型（如 FULLTEXT）可能被忽略或报错 - 如果目标库是 MySQL 8.0+ 而源库是 5.7，注意
invisible index属性在低版本不支持，Navicat 会把“可见性变化”当作索引定义变更 - 比对完成后，不要只扫“操作类型”列；右键每条索引相关的差异项 → 选“在 DDL 比较中查看”，才能确认是字段顺序变了，还是
USING BTREE被省略了
索引字段顺序/表达式差异必须靠 DDL 比较面板肉眼识别
Navicat 解析 DDL 后生成的标准输出里，索引定义会统一转成类似 KEY `idx_name` (`col_a`, `col_b`(10), `col_c` DESC) 的格式。这意味着：如果你原始 SQL 里写的是 KEY idx_name (col_b(10), col_a)，而目标库是 (col_a, col_b(10))，结构同步会标为“修改”，但具体哪改了得看 DDL 面板。
容易踩的坑：
-
col_b(10)和col_b被视为不同索引字段，即使实际业务中没区别；Navicat 不会提示“前缀长度可忽略” - 函数索引（如 MySQL 8.0+ 的
KEY ((UPPER(email)))）若两边写法不完全一致（比如一边用UPPER，一边用LOWER），直接标为不一致，且不给出函数体对比高亮 - 排序方向（
ASC/DESC）在 MySQL 8.0 前被忽略，但 Navicat 仍会比对并标记——这可能导致你误以为有变更，其实目标库根本不认这个语法
跨库比对索引时，字符集与排序规则影响索引可用性判断
当两个数据库的表使用不同 COLLATE（比如 utf8mb4_0900_as_cs vs utf8mb4_unicode_ci），Navicat 可能将同一索引判定为“需重建”，因为它认为列的比较行为已变。这不是误报，而是真实风险：排序规则变更会导致索引无法用于某些 ORDER BY 或 WHERE 场景。
实操建议：
- 先运行
SHOW CREATE TABLE table_name确认两边索引定义中的COLLATE是否一致；如果不一致，且你确认业务不需要严格大小写敏感，可在结构同步结果中右键该索引项 → “忽略此项” - 对含中文字段的索引，特别检查
CHARACTER SET：若一边是utf8mb4，另一边是utf8（即utf8mb3），Navicat 会强制标为差异，因为后者不支持 emoji，索引可能失效 - 不要依赖“忽略大小写”类选项——Navicat 没有全局开关来跳过 collation 比对，只能逐条忽略
视图/存储过程里的隐式索引依赖不会被结构同步捕获
结构同步只比对显式创建的索引（CREATE INDEX 或 KEY 子句），不会分析视图定义中 WHERE 条件是否依赖某个索引，也不会检查存储过程中 FORCE INDEX 引用的索引是否存在。也就是说，就算两个库的索引集合完全一致，只要视图 SQL 里写了 USE INDEX (missing_idx)，而该索引在目标库不存在，Navicat 也完全不管。
这意味着：
- 仅靠结构同步无法保证查询性能一致；你得额外导出视图和存储过程定义，用文本 diff 工具人工核对
INDEX、KEY、FORCE等关键词 - 如果升级脚本里包含
ALTER VIEW且新增了高选择性过滤条件，但没同步加索引，结构同步不会报警——它只管“有没有”，不管“够不够” - 最易被忽略的一点：MySQL 的隐藏主键（
GEN_CLUST_INDEX）在无主键表中存在，但 Navicat 不展示也不比对，这种底层索引差异只会在EXPLAIN时暴露
