mysql 执行计划 possible_keys

2025年Java面试宝典下载地址（提取码：9b3g）

二、MySQL执行计划中的possible_keys到底是什么？

咱们程序员在面试中遇到SQL优化的题目，十有八九会被问到执行计划。最近帮朋友准备面试时发现，很多同学对possible_keys这个字段存在理解误区。今天咱们就掰开揉碎了讲明白这个核心概念，毕竟这是MySQL优化器工作的关键线索。

在EXPLAIN的结果集中，possible_keys列总是显得很"暧昧"——它明明告诉你可能用到的索引，但实际用的却是另一个。有次面试官问我："possible_keys显示有三个候选索引，为什么最终选了最差的那个？"这个问题直接暴露出候选索引和实际执行之间的微妙关系。

三、possible_keys是怎么产生的？

MySQL优化器在解析查询语句时，会先进行索引选择的预处理。系统会扫描where条件、join条件中的字段，把这些字段涉及的索引都列出来。比如where条件有age>18 and city='北京'，而表中正好有单独的age索引、city索引和联合索引，那这三个都会进入possible_keys列表。

但要注意的是：这个阶段只是机械匹配字段，不考虑索引的区分度、数据量等实际因素。就像你去餐厅点菜，服务员先把所有可能有食材的菜都报给你（possible_keys），但实际能做出来的（key）可能只有两三道。

四、优化器如何从possible_keys中做选择？

当possible_keys有多个候选时，MySQL会进入真正的优化阶段。这里有个常见的误区：认为possible_keys里的索引都是有效可用的。实际上优化器会综合考虑：

1. 索引覆盖度：是否满足覆盖索引（不用回表）
2. 索引长度：比如前缀索引可能不如全字段索引有效
3. 数据统计信息：cardinality值（索引区分度）
4. 查询成本估算：基于IO成本和CPU成本计算

举个例子，有个订单表同时有status索引和create_time索引。当查询where status=1 and create_time>='2024-01-01'时，虽然两个字段都有索引，但优化器可能发现status=1的数据占80%，而时间条件能过滤掉95%数据，这时就会优先选create_time索引。

五、possible_keys为空意味着什么？

这个问题我在美团的技术面被问到过。当EXPLAIN显示possible_keys为null时，可能有三种情况：

• 查询条件中的字段真的没有索引
• 字段类型不匹配导致索引失效（比如字符串字段用数字查询）
• 使用函数或表达式导致索引失效（比如YEAR(create_time)=2024）

有个实战经验值得注意：当发现possible_keys为空但where条件明明有索引字段时，先别急着加索引，应该检查是否出现了隐式类型转换或者函数操作。

六、利用possible_keys定位优化点

建议大家在分析慢查询时，养成三个查看习惯：

1. 对比possible_keys和key是否一致（不一致说明优化器做了取舍）
2. 检查key_len是否充分利用了复合索引
3. 验证rows字段的估算是否准确

最近帮朋友优化过一个案例：某分页查询原本走的是主键索引，但possible_keys里有更合适的联合索引。通过force index强制使用后，查询速度从800ms降到50ms。不过要注意，force index是最后的杀手锏，用不好会导致更严重的问题。

如果需要系统学习MySQL优化技巧，可以看看前面分享的Java面试宝典。通过面试鸭返利网购买会员还能返利25元，能省则省嘛。咱们程序员搞技术的同时，也要学会精打细算不是？