navicat还原后索引“失效”大概率是压根没建上：先执行show index from table_name确认是否为空，若为空则说明索引缺失，需检查还原设置是否勾选“索引”、.sql文件是否含create index语句或.nb3备份是否需手动重建，并用标准sql手写create index语句补全。
navicat 还原后索引“失效”，大概率是压根没建上，而不是建了但不生效；重新触发索引构建不能靠“刷新”或“维护”按钮，得先确认缺失还是真失效，再分情况处理。
还原后 SHOW INDEX FROM table_name 返回空怎么办
这是最常见也最容易误判的情况：索引根本不存在，不是失效。Navicat 默认还原设置常漏掉索引对象。
- 检查还原对话框里的「对象类型」是否勾选了「索引」——很多用户只勾了「表」「视图」，默认不包含索引
- 打开你的
.sql备份文件，搜索CREATE INDEX或KEY，确认语句是否存在；若无，说明导出时就禁用了 DDL - 如果是
.nb3格式备份，它不保存完整 DDL，还原后必须手动补索引，Navicat 的任何“修复”功能都无效 - 别用 Navicat 图形界面批量加索引——它生成的 SQL 常漏
USING BTREE、列名大小写不匹配，或把UNIQUE错写成UNIQUE KEY
可靠做法是手写标准语句，例如：
CREATE INDEX idx_order_status ON orders(status, created_at) USING BTREE; CREATE UNIQUE INDEX uk_user_email ON users(email) USING BTREE;
EXPLAIN SELECT 显示 key 为空但 possible_keys 有值
说明索引存在，但优化器主动跳过了。这不是 Navicat 的问题，而是 MySQL 的成本估算结果。
- 检查 WHERE 是否满足最左前缀：比如索引是
(user_id, status, created_at)，但查询只写了WHERE status = 'paid'，该索引完全无法启动 - 检查隐式转换：字段是
VARCHAR，却写成WHERE id = 123（没引号），MySQL 会转成数字比对，索引失效 - 数据量太小（比如几百行）时，优化器认为全表扫描比回表更快，
type: ALL是合理行为，不是 bug - Navicat ≤16.0 版本解析
EXPLAIN输出时可能丢掉key字段，建议升级到 17+，或改用命令行执行EXPLAIN FORMAT=JSON SELECT ...
索引存在但查询仍走全表扫描，先跑 ANALYZE TABLE
同步或还原大量数据后，InnoDB 的统计信息不会自动更新，优化器基于过期采样做出错误决策——这是最被忽视也最易解决的原因。
-
ANALYZE TABLE orders;比OPTIMIZE TABLE更轻量、更对症，毫秒级完成，且 InnoDB 下基本无锁 - 不要依赖 Navicat 自动触发：它的“还原完成”动作不包含此步骤，必须手动补上
- 如果表刚导入百万级以上数据，
ANALYZE TABLE后立刻验证：EXPLAIN SELECT * FROM orders WHERE status = 'shipped'; - 注意：某些低峰期外执行
ANALYZE TABLE可能短暂加读锁（MySQL 5.7+ 影响极小，但仍需留意）
Navicat 同步结构时新增复合索引不识别
不是 Navicat 没看到，是默认根本不比对多列索引，连“差异”都不会显示出来。
- 路径：
Tools → Options → Data Modeling → Synchronization，必须勾选Compare composite indexes（注意不是上面那个Compare indexes） - 改完设置后必须重启 Navicat，否则不生效
- 即使开了，也可能因字段排序（如
a DESC, b ASC）、索引名含特殊字符（如idx-user-id）、或SEQ_IN_INDEX不连续而识别失败 - 最靠谱验证方式：同步前点「Save as SQL File」，打开生成的 SQL 文件，搜索
CREATE INDEX，确认目标索引是否在其中
真正麻烦的是那种“索引建了但顺序错”的情况——Navicat 同步过去，语法合法，但查询时 type: ALL，你得自己查 SHOW CREATE TABLE 和业务查询条件才能发现。
