key列为空说明查询未使用索引，常见原因包括未满足最左前缀、字段类型不匹配或优化器放弃；应先用SHOW INDEX确认索引存在且顺序一致，避免对索引字段使用函数。
Navicat执行计划里key列为空，但实际有索引怎么办
navicat的执行计划表格中key列为空，不代表没索引，只说明这条查询**没走那个索引**。常见原因不是索引不存在，而是条件没对上最左前缀、字段类型不匹配或优化器主动放弃。
实操建议：
- 先用
SHOW INDEX FROM table_name确认索引确实存在，且Column_name顺序与WHERE条件严格一致 - 检查查询中是否对索引字段用了函数，比如
DATE(create_time) = '2023-01-01'→ 改成create_time >= '2023-01-01' AND create_time - 如果
possible_keys有值而key为空，大概率是索引选择性低（如status只有3个值），MySQL判定全表扫描更快——可用FORCE INDEX (idx_name)临时验证，但别长期依赖 - 注意隐式转换：
user_id是BIGINT，但查询写了WHERE user_id = '123'（字符串），会触发类型转换，索引失效
Navicat解释计划不显示索引名，怎么查到底用了哪个索引
Navicat默认渲染的执行计划表格精简了字段，key列只显示索引名，但有时它为空或你怀疑它不准。真正要定位“到底走了哪个索引”，得看底层原始输出。
实操建议：
- 右键执行计划结果表格 → 选「显示所有列」，重点看
key_len（实际使用索引字节数）和ref（用于索引查找的列或常量），能反推命中了哪几列 - 在查询前手动加
EXPLAIN FORMAT=JSON（MySQL 5.6+），Navicat v15.5+会解析并展示used_columns、used_indexes等诊断字段 - 如果连
FORMAT=JSON都不支持（如旧版Navicat或连接的是MariaDB），直接在查询窗口运行EXPLAIN SELECT ...，看文本输出里的key和possible_keys对比 - PostgreSQL用户注意：
EXPLAIN默认不显示索引名，要看Index Scan using idx_name on table_name这类提示，需确保Navicat调用的是EXPLAIN (BUFFERS)而非纯EXPLAIN
Navicat图形化执行计划节点里看不到索引名，怎么点开看细节
SQL Server和PostgreSQL连接下，Navicat会调用图形化执行计划API，节点图标（如Index Seek、Index Scan）本身不带索引名文字，但双击或右键可展开详细信息。
实操建议：
- SQL Server：点击节点 → 右下角属性面板里找
Index Name或Object字段；若为空，说明走的是Clustered Index Scan（即聚簇索引，通常就是主键） - PostgreSQL：鼠标悬停在Index Scan节点上，提示框会显示
Index Name: idx_xxx；若没显示，执行计划可能退化为Bitmap Heap Scan或Seq Scan，说明索引未被选用 - MySQL不提供图形化计划，Navicat的“解释”标签页始终是表格形式，所谓“节点”是误解——别在MySQL连接下找图形节点
- Oracle连接需确认已执行过
EXPLAIN PLAN FOR，否则图形界面无数据；索引名出现在OBJECT_NAME列，不是OPERATION列
为什么Navicat执行计划里索引名显示为NULL或<auto>
NULL或<auto>不是Bug，是数据库引擎返回的明确信号：当前操作没走任何用户定义索引。可能路径包括全表扫描、覆盖索引回表、或使用了隐式索引（如主键聚簇索引）。
实操建议：
-
NULL在MySQL中常见于type=ALL或type=index（全索引扫描），此时key为空是正常行为，重点看rows是否远超结果集行数 -
<auto>多见于SQL Server，表示优化器选择了系统生成的统计信息辅助路径，不是用户建的索引——这时应检查Missing Index Details建议 - 如果确定该走索引却显示
NULL，用ANALYZE TABLE table_name（MySQL）或UPDATE STATISTICS table_name（SQL Server）刷新统计信息，旧统计可能导致优化器误判 - 别忽略
Extra列：Using index表示走了覆盖索引（哪怕key为空，也可能用了隐式主键），而Using where; Using index才是真·覆盖
rows、key_len、Extra组合起来才能判断真实路径。 
