为什么Navicat执行计划显示的Key字段为空没有走索引？-navicat-PHP中文网

key为空但possible_keys有值，说明索引被优化器看见却未选用，主因是最左前缀不匹配、函数操作、隐式类型转换、统计信息过期或选择性过低；若possible_keys也为空，则极可能索引根本未创建。

为什么navicat执行计划显示的key字段为空没有走索引？

Key 为空，不等于没建索引，也不等于索引坏了——大概率是 MySQL 优化器主动跳过了它，或者索引压根就不存在。

possible_keys 有值但 key 为空，说明索引被“看见”却没被选中

这是最典型也最容易误判的情况。优化器在 possible_keys 里列出了候选索引，但最终决定不用，key 就显示为空。常见真实原因包括：

WHERE 条件不满足最左前缀：比如索引是 (status, category, created_at)，但查询只写了 WHERE category = 'A'，这个索引完全不可用
对索引字段用了函数：WHERE DATE(create_time) = '2025-01-01' → 即使 create_time 有索引也失效
隐式类型转换：user_id 是 BIGINT，却写成 WHERE user_id = '123'（字符串字面量），MySQL 放弃索引做全表扫描
统计信息过期：大批量写入后没运行 ANALYZE TABLE table_name，优化器误判“回表代价 > 全表扫描”
索引选择性太低：比如 status 只有 'active'/'inactive' 两个值，优化器认为走索引反而更慢

key 和 possible_keys 都为空，极可能是索引根本没建

别急着调优 SQL，先确认索引是否存在。Navicat 还原数据库时默认不带索引，尤其是 .nb3 备份文件，还原后表结构里压根没有 KEY 定义。

navicatmysql

Navicat For MySQL

下载

运行 SHOW INDEX FROM table_name，输出为空或只有 PRIMARY，说明索引缺失
打开 .sql 备份文件，全文搜索 CREATE INDEX 或 KEY，看是否真包含该语句
如果是 .nb3 格式备份，它不保存完整 DDL，必须手动补建：CREATE INDEX idx_user_status ON users(status) USING BTREE
Navicat 图形界面点选建索引容易漏写 USING BTREE、列名大小写不一致，手写更稳

JSON 字段查询 key 为空，大概率是虚拟列或函数索引配置错

MySQL 8.0.22 前不支持直接对 JSON_EXTRACT() 建函数索引，必须用虚拟列。而虚拟列类型（VIRTUAL / STORED）和索引必须严格匹配。

虚拟列定义用了 VIRTUAL，但索引建在了 STORED 列上（或反过来），优化器直接忽略
WHERE 写的是 params->'$.item_id' = 123，但虚拟列表达式是 json_extract(`params`, '$.item_id') —— 二者语法等价，但内部 token 不同，老版本不视为可复用
混用 -> 和 JSON_EXTRACT()，优化器无法统一路径推导
检查 SHOW CREATE TABLE table_name，确认虚拟列存在且类型正确，再确认该列出现在 SHOW INDEXES 的 Column_name 中

FORCE INDEX 能验证索引是否可用，但不是解法

临时加 FORCE INDEX 是为了快速确认“是不是索引本身能用”，不是长期方案。

执行 SELECT * FROM orders FORCE INDEX(idx_user_id) WHERE user_id = 123，若 rows 明显下降、耗时缩短，说明索引结构没问题
但如果 idx_user_id 字段类型和 WHERE 中的值不一致（如传字符串），FORCE INDEX 仍不会生效
PostgreSQL 不支持 FORCE INDEX，得用 SET enable_seqscan = off 或 /*+ IndexScan(t idx_name) */ Hint
强制后有效，下一步该更新统计信息或修正查询写法，而不是继续依赖 FORCE

最常被忽略的一点：Navicat 执行计划表格是渲染结果，不是权威来源。真正要确认索引是否生效，必须看 EXPLAIN FORMAT=TRADITIONAL 或 EXPLAIN FORMAT=JSON 的原始输出，尤其盯住 key 和 possible_keys 字段值，再交叉验证 SHOW INDEX 和 SHOW CREATE TABLE。