navicat同步后索引“失效”90%是优化器未选用而非丢失，应先用explain确认执行计划，再执行analyze table更新统计信息；若索引确实缺失，则依据源库show create table语句手写create index补全。
navicat 同步完成后目标库索引“失效”，90% 以上不是真丢了，而是优化器没选它——首要动作不是重建索引，而是跑 explain 看真实执行计划。
先确认是“没建”还是“没用”
同步后索引问题分两类，处理路径完全不同：
- 如果
SHOW INDEX FROM table_name返回空，或只显示PRIMARY，说明索引压根没建上——常见于 Navicat 还原时未勾选「索引」、备份文件不含CREATE INDEX语句、或用了.nb3格式（不存 DDL） - 如果
SHOW INDEX显示索引存在，但EXPLAIN SELECT ... WHERE indexed_col = ?中key列为NULL或type是ALL，那索引在、只是没被用——大概率是统计信息过期或数据分布突变
别跳过这步直接 OPTIMIZE TABLE，否则白等几分钟还掩盖了真正原因。
统计信息过期：优先执行 ANALYZE TABLE
Navicat 同步（尤其带数据迁移）会重写表内容，但不会自动触发统计信息更新。优化器依赖旧采样值，可能误判索引无选择性而弃用。
-
ANALYZE TABLE users;耗时极短（毫秒级），InnoDB 无锁，且只刷新统计信息，不移动数据 - 批量修复：用
SELECT CONCAT('ANALYZE TABLE `', table_name, '`;') FROM information_schema.TABLES WHERE table_schema = 'your_db' AND engine = 'InnoDB';生成脚本执行 - Navicat 图形界面里的「维护 → 重新优化表」实际执行的是
OPTIMIZE TABLE，比ANALYZE重得多，非必要不用
索引真缺失：手写 CREATE INDEX 补全
若确认索引未建，别依赖 Navicat 的「设计表 → 索引」图形界面——它容易漏写 USING BTREE、错大小写、或对联合索引列序处理随意。
- 查源库定义：
SHOW CREATE TABLE source_table;复制原KEY或UNIQUE KEY语句，改名后在目标库执行 - 标准写法示例：
CREATE INDEX idx_order_status ON orders(status) USING BTREE;、CREATE UNIQUE INDEX uk_mobile ON users(mobile) USING BTREE; - 联合索引注意列序：如常查
WHERE category = ? AND created_at > ?，必须建(category, created_at)，反着建等于没建 - 大表加索引前，确认有
INDEX权限：SHOW GRANTS FOR CURRENT_USER;，缺则需 DBA 执行GRANT INDEX ON db_name.table_name TO 'user'@'%';
容易被忽略的同步配置陷阱
这些选项看似无关，实则悄悄导致索引“失效”：
- 同步向导里勾选了
Ignore AUTO_INCREMENT value：目标表自增值错乱，主键索引范围判断失准，WHERE id > 1000可能扫全表 - 未启用
Preserve index order（旧版 Navicat）：同步时删索引再重建，中间空窗期查询直接走全表扫描 - 同步日志里出现
ERROR 1091 (HY000): Can't DROP 'xxx'; check that column/key exists：说明脚本含DROP INDEX但没配CREATE INDEX，索引被删没补上
真正需要 OPTIMIZE TABLE 的场景极少——仅当 SHOW TABLE STATUS 显示 Data_free 占比超 20%，或 B+ 树深度异常时才值得动它。同步后第一反应永远是 EXPLAIN + ANALYZE TABLE。
