Navicat 16「设计表」保存索引后未生效是正常现象，因仅执行DDL修改元数据，未更新统计信息；必须手动执行ANALYZE TABLE才能使优化器识别并使用新索引。
navicat 16 的「设计表」界面本身不触发索引优化，这是正常行为，不是 bug —— 它只修改表结构定义，不执行 analyze 或 optimize。
为什么“设计表 → 保存”后索引没生效
在 Navicat 16 中通过「设计表」添加或修改索引（比如勾选“索引”列、设为 UNIQUE），点击保存后只会执行 ALTER TABLE ... ADD INDEX 或 ADD UNIQUE KEY 这类 DDL。它不会自动更新统计信息，也不会重建 B+ 树物理结构。这意味着：
- 索引定义已写入元数据（
SHOW INDEX FROM table_name能查到） - 但优化器可能因统计信息陈旧，仍拒绝使用该索引（
EXPLAIN中key为空） - 如果表已有大量数据，新索引的 B+ 树页可能未充分填充，查询初期性能也不稳定
手动补上 ANALYZE TABLE 才算真正完成
添加/修改索引后，必须显式刷新统计信息，否则优化器大概率继续走全表扫描。这不是可选项，是必要步骤：
- 在 SQL 编辑器中直接执行：
ANALYZE TABLE your_table_name; - 右键目标表 → 「维护」→ 「重新优化表」：注意，这个菜单项在 Navicat 16 中实际执行的是
OPTIMIZE TABLE，代价高，不推荐作为首选；应优先用ANALYZE TABLE - 若需批量处理多个表，可写脚本生成一串
ANALYZE TABLE语句，避免逐个点开
容易被忽略的两个陷阱
即使你记得执行 ANALYZE TABLE，以下两点仍常导致“看似没生效”：
-
ANALYZE TABLE在 InnoDB 中默认采样约 10–20 页，对超大表（如千万级）可能不够准；若EXPLAIN的rows值明显偏离实际，可加参数强制更细粒度采样：ANALYZE TABLE your_table_name UPDATE HISTOGRAM ON column_name;（MySQL 8.0+） - Navicat 16.0.x 某些版本（尤其是 ≤16.0.12）在「解释」功能中解析
EXPLAIN输出时会丢掉key字段值，造成误判；验证方法：把语句复制到命令行客户端执行EXPLAIN FORMAT=JSON SELECT ...，看key和used_columns是否真实为空
别依赖「设计表」里的“索引”标签页做性能验证
「设计表 → 索引」标签页只展示定义，不反映运行时状态。哪怕这里显示索引存在且启用，也完全不能说明它正在被使用。真正的验证路径只有一条：
- 写一个带明确 WHERE 条件的
SELECT（避免用?占位符） - 在 Navicat 中右键 → 「解释」
- 紧盯
type（不能是ALL）、key（必须非空）、rows（接近实际匹配行数）
只要 key 是空的，就说明优化器没选——无论「设计表」里看起来多完美，都得回头检查最左前缀、隐式转换、统计信息这三件事。
