Navicat同步后索引丢失90%是根本未建，需先用SHOW INDEX确认是否存在；若为空，则检查同步是否勾选“导出索引”、.sql文件是否含CREATE INDEX语句或.nb3格式是否需手写补全。
navicat 同步模型时索引丢失，90% 是压根没建上，不是“失效”或“损坏”——第一步必须用 show index from table_name 确认是否存在，而不是直接跑 analyze table 或点“优化表”。
同步后 SHOW INDEX 返回空，说明索引根本没建
这是最常见也最容易误判的情况：Navicat 默认不导出索引 DDL，尤其在结构同步（Structure Synchronization）模式下，若未手动勾选关键选项，索引会被完全跳过。
- 检查同步向导「选项」页是否勾选了「导出索引」——该选项默认关闭，必须手动打钩
- 若源备份是
.nb3格式，它不保存任何 DDL（包括索引、外键、注释），还原后必须手写补全，Navicat 的任何“修复”功能都无效 - 打开你用的
.sql文件，搜索CREATE INDEX或KEY，确认语句是否存在；若无，说明导出时就禁用了 DDL 生成 - 别依赖 Navicat 图形界面「设计表 → 索引」添加——它常漏写
USING BTREE、列名大小写不匹配，或把UNIQUE错写成UNIQUE KEY
EXPLAIN 显示 key 为空但 possible_keys 有值
说明索引存在，但优化器没选它。此时不是同步问题，而是统计信息陈旧或查询条件不匹配最左前缀。
- 先执行
ANALYZE TABLE table_name—— 耗时毫秒级、InnoDB 无锁，比OPTIMIZE TABLE更轻量且对症 - 检查 WHERE 条件是否满足最左前缀：比如索引是
(status, created_at)，但查询只写了WHERE created_at > '2026-07-01'，该索引完全不可用 - 检查隐式转换：字段是
VARCHAR，却写成WHERE id = 123（没引号），MySQL 会转类型，索引失效 - Navicat ≤16.0 版本解析
EXPLAIN输出时可能丢掉key字段，建议升级到 17+，或改用命令行执行EXPLAIN FORMAT=JSON SELECT ...
手写 CREATE INDEX 补索引时的关键细节
补索引不是复制粘贴完事，列序、语法、权限都直接影响可用性。
- 联合索引列顺序必须贴合高频查询：常查
WHERE category = ? AND created_at > ?，就得建(category, created_at)，反着建等于没建 - 必须显式指定
USING BTREE：MySQL 8.0+ 默认引擎是 InnoDB，但省略该子句可能导致兼容性问题或被忽略 - 执行前确认权限：
SHOW GRANTS FOR CURRENT_USER，缺INDEX权限需 DBA 执行GRANT INDEX ON db_name.table_name TO 'user'@'%' - 避免用
ALTER TABLE ADD INDEX替代CREATE INDEX—— 后者语义更清晰，且 MySQL 8.0+ 对两者的锁行为有细微差异 - 大表加索引期间会阻塞写入，建议在低峰期执行；加完立刻验证：
EXPLAIN SELECT * FROM t WHERE indexed_col = ?
真正容易被忽略的是同步配置里的「导出索引」开关——它静默关闭，不报错、不提示，但直接导致目标库变成裸表。补索引前，务必先确认它是真缺失，而不是被优化器暂时冷落。
