key为空但possible_keys有值，说明索引存在但被优化器跳过，主因包括最左前缀不匹配、隐式类型转换、函数包裹字段、order by顺序不符或select *导致回表代价高；需通过explain验证并实测耗时。

Navicat 执行计划里 key 为空，不等于索引“失效”，而更可能是它压根没被看到、没被选中，或根本不存在——得先分清是“没建”“建了但用不上”还是“建了但被绕过”。

执行计划 key 为空但 possible_keys 有值，说明索引存在但被跳过

这最常见于优化器主动放弃索引，而非索引坏了。典型诱因包括：

• WHERE 条件违反最左前缀：建了 (user_id, status)，却只查 status = 'active'，possible_keys 会显示该索引名，但 key 仍为空
• 隐式类型转换：字段是 BIGINT，但传参是字符串 '123'，MySQL 会转成数字再比对，导致索引无法下推
• 函数包裹字段：WHERE DATE(create_time) = '2024-01-01' → 索引失效；应改写为 create_time >= '2024-01-01' AND create_time
• 统计信息过期：大批量导入后未运行 ANALYZE TABLE table_name，优化器误判全表扫描更快

type = ALL 且 possible_keys 为空，基本可断定索引缺失

这不是优化器的问题，是物理上没定义索引。高频场景有：

• Navicat 还原数据库时勾选了「仅数据」，漏掉索引对象
• 备份文件是 .nb3 或损坏的 .psc，本身不含 CREATE INDEX 语句
• 导出 SQL 用了 --no-create-info，跳过了 DDL 部分
• 手写建表语句里忘了加 KEY idx_name (col)，只写了主键

验证方式很简单：在 Navicat 查询窗口执行 SHOW INDEX FROM your_table，如果结果为空或只有 PRIMARY，那就不是“失效”，是“没建”。

navicatmysql

Navicat For MySQL

下载

LEFT JOIN 右表 key 为空，大概率是连接字段不匹配

LEFT JOIN 对索引更敏感，右表连接字段必须能独立走索引。常见硬伤：

• 左右表字段字符集或排序规则不同（如 utf8mb4_0900_ai_ci vs utf8mb4_general_ci），加索引也白搭
• 字段类型不一致：左表 user_id INT，右表 user_id VARCHAR(64)，触发隐式转换
• WHERE 条件误写在 JOIN 外：LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' → 实际变成 INNER JOIN，且右表失去索引下推机会；应改为 ON u.id = o.user_id AND o.status = 'paid'

建完索引后 key 还是空？别只看 Navicat 界面

很多人点开「设计表 → 索引」确认字段顺序就以为万事大吉，但实际执行计划仍不走索引。原因常藏在细节里：

• Navicat 图形界面建索引容易漏写 USING BTREE，或大小写拼错字段名（尤其从备份恢复后字段名带下划线但手动输入漏了）
• 复合索引顺序和查询条件不严格对齐：查 WHERE a = ? AND b > ? ORDER BY c，索引必须是 (a, b, c)，不能是 (a, c, b)
• SELECT * 导致回表代价过高，优化器宁愿全表扫描；换成只查必要字段，key 可能立刻亮起
• PostgreSQL 中 GIN/GIST 索引需匹配操作符：用 = 查 JSONB 字段不会走 jsonb_path_ops 索引，必须用 @> 或 @@

真正可靠的验证动作只有三个：建索引 → EXPLAIN 看 key 和 rows → 实际跑一次 SQL 记录耗时 → 对比前后变化。别信 Navicat 底部那行“查询成功”，要看它到底扫了多少行。