EXPLAIN 结果中 key 字段为空，是否意味着索引失效？
先别急于下定论。当 EXPLAIN 输出的 key 列显示为 NULL 时，许多开发者会直接认为“索引没有生效”。实际上，这仅表明 MySQL 查询优化器在最终的执行计划中，未选择使用任何索引来检索数据。其背后的原因，往往比表面现象更为复杂。
通常，这扇“索引之门”未被开启，不外乎以下几种典型场景：索引本身可能已经失效或未被正确创建；表的统计信息过于陈旧，误导了优化器的成本估算；查询条件未能匹配索引的“最左前缀”原则；或者，由于数据量过小，优化器判定全表扫描的效率反而更高。
遇到此类情况，建议按照以下步骤进行系统性排查：
- 首先，执行
SHOW INDEX FROM table_name命令，确认目标索引是否存在，以及其字段顺序是否符合查询预期。 - 接着，仔细核对
WHERE子句中的条件列，是否与索引定义精确匹配。例如，若你创建了(a, b, c)的联合索引，但查询条件仅为b = ?，则该索引大概率无法被有效利用。 - 然后，运行
ANALYZE TABLE table_name命令，更新表的统计信息。这在经历大规模数据插入、删除或更新操作后尤为重要。 - 若仍存疑虑，可使用
FORCE INDEX语法进行临时性验证，例如SELECT * FROM t FORCE INDEX (idx_a_b) WHERE a = 1，以观察强制使用特定索引后的执行效果。
ref 字段显示 const、func 或列名，分别代表何种含义？
如果说 key 字段揭示了“使用了哪个索引”，那么 ref 字段则解释了“使用什么值去索引中进行查找”。它清晰地展示了查询条件与索引列之间的关联关系，是判断索引是否被高效利用的核心依据。
以下是几种常见 ref 值的具体含义：
const：这是最理想的状况。表示查询条件使用了常量值进行等值匹配，例如id = 123或主键查询，其执行效率通常最高。- 列名（如
db.t.a）：这通常出现在多表关联查询（JOIN）中。意味着当前表的索引查找，是由另一张表或子查询中的某个列值来驱动的。 func：这是一个需要警惕的信号。它表明查询条件中使用了函数或表达式，例如WHERE YEAR(created_at) = 2023。在大多数情况下（除非使用 MySQL 8.0.13 及以上版本并创建了函数索引），这会导致索引失效，引发全表扫描。NULL：表示未使用索引的等值查找逻辑。这可能是因为查询执行了范围扫描（type为range），或者直接进行了全表扫描（type为ALL）。
type = index 与 type = ALL 同为全扫描，核心差异是什么？
虽然两者都涉及“扫描”，但 type = index（索引全扫描）与 type = ALL（全表扫描）在性能表现上可谓天壤之别。
type = index 代表**索引全扫描**。它遍历的是索引 B+ 树的叶子节点。由于索引数据通常远小于完整的数据行，且物理存储更为紧凑，因此这种扫描的 I/O 开销较小，速度更快。有时还能直接利用索引的有序性，避免额外的排序操作。
而 type = ALL 代表**聚簇索引（即数据页）全扫描**。它需要读取整张表的每一行数据，I/O 开销巨大，是数据库性能优化中应极力避免的情况。
那么，在何种场景下会触发效率相对较高的 index 扫描呢？
- 查询语句所涉及的字段完全被某个索引覆盖（即“覆盖索引”）。例如，
SELECT a,b FROM t WHERE a > 10，而(a,b)恰好是一个联合索引，此时数据库仅需读取索引数据，无需回表查询。 ORDER BY子句的字段完全匹配索引的最左前缀。这使得数据库可以直接利用索引的有序性返回结果，避免出现额外的Using filesort操作。- 需要注意的是：如果
WHERE条件无法有效过滤数据，同时查询又未能利用覆盖索引，那么即使type显示为index，其性能也可能非常低下。
为何有时已添加索引，EXPLAIN 显示 key 有值但 rows 预估行数却很大？
这是最令人困惑的场景之一：key 字段有值，表明索引已被使用，但预估的扫描行数（rows）却异常庞大。这实际上传递了一个明确信号：索引虽然被启用了，但使用效率极低。
rows 值是优化器基于统计信息估算出的扫描行数。其数值偏高，通常指向两个核心问题：要么是索引列的选择性太差（即该列重复值过多），要么是查询条件仅命中了索引中效率较低的前缀部分。
排查时，可遵循以下思路：
- 计算索引列的选择性：
SELECT COUNT(DISTINCT col) / COUNT(*) FROM t。若结果低于 0.1（即10%），则该索引的价值可能非常有限。 - 检查
WHERE条件中是否使用了LIKE '%xxx'这类前导通配符，或者使用OR连接了非索引列。这些写法会导致索引只能部分生效，甚至退化为低效的范围扫描。 - 进行更深入的分析，可以对比
EXPLAIN FORMAT=JSON输出中的used_range_access_method和range_details字段，查看优化器实际划定的索引扫描范围是否过大。 - 最后，注意 MySQL 版本间的差异。例如，5.7 版本对隐式类型转换（如用数字查询字符串字段）更为敏感，容易导致索引失效；而 8.0 及以上版本在某些场景下会进行更智能的优化。
因此，解读 EXPLAIN 执行计划，难点不在于判断 key 是否为空。真正的关键在于理解 ref 字段背后的索引查找逻辑，分析 rows 预估行数虚高的原因，并洞察不同 type 值所隐含的磁盘 I/O 代价。这些细节，如果仅查看传统的表格输出而忽略 JSON 格式的详细信息，很容易导致误判。
