MySQL执行计划详解与SQL性能优化实战

1. 执行计划基础认知

第一次用explain命令时，我盯着输出结果看了半天，满屏的type、key、rows字段让人眼花缭乱。这就像拿到一份体检报告却看不懂各项指标的含义——明明数据就在眼前，却不知道哪些是重点、哪些需要警惕。执行计划就是SQL语句的"体检报告"，它揭示了MySQL如何执行查询的内部机制。

explain的输出包含12个关键字段，但实际工作中我们最需要关注的是type、key、rows、Extra这四个核心指标。type列告诉你查询使用了哪种访问方法（是全表扫描还是索引查找），key列显示实际使用的索引名称，rows是预估需要检查的行数，Extra则包含额外的优化信息。这些字段的组合能快速定位SQL的性能瓶颈。

举个例子，当看到type=ALL时，就像发现体检报告中的某项指标严重超标——这意味着全表扫描，对于百万级数据表来说绝对是灾难性的。而看到type=ref时，则像是各项指标都在正常范围，说明索引使用得当。

2. 关键字段深度解析

2.1 type字段全解

type字段是执行计划的"心脏指标"，它按照性能从优到劣有以下几种常见值：

• system：表中只有一行数据，这是最优情况。就像在空荡的图书馆里找唯一的一本书，直接就能定位。
• const：通过主键或唯一索引查找，最多返回一行。例如WHERE id = 1这类查询。
• eq_ref：多表关联时，主键或唯一索引作为关联条件。好比用身份证号匹配人员信息，确保一对一关系。
• ref：使用普通索引查询，可能返回多行。就像按姓氏查找学生，可能找到多个同姓的人。
• range：索引范围扫描，如BETWEEN、IN、>等操作。类似于在字典中查找"a"到"c"开头的单词。
• index：全索引扫描，比全表扫描好但仍有优化空间。相当于把字典从头到尾翻一遍，但只看单词不读解释。
• ALL：全表扫描，性能最差。如同在图书馆逐页翻找某个关键词。

实际项目中，我遇到一个典型案例：用户列表页突然变慢，explain显示type=ALL。检查发现是在未索引的status字段上过滤，添加索引后type变为ref，查询时间从2秒降到50毫秒。

2.2 key与possible_keys的抉择

possible_keys列出可能使用的索引，而key是实际使用的索引。当这两个字段不一致时，就需要特别注意：

sql复制EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'paid';

假设表上有(user_id)单列索引和(user_id, status)联合索引，possible_keys会显示这两个索引，但key可能只使用(user_id)索引。这是因为优化器认为使用单列索引后通过status过滤的行数足够少。

我曾踩过一个坑：表上有(a,b)联合索引，但查询条件是WHERE b=1 AND a=2，由于条件顺序与索引顺序不一致，导致索引失效。调整条件顺序为a=2 AND b=1后，索引立即生效。

2.3 rows与filtered的关联分析

rows表示预估检查的行数，filtered表示条件过滤后剩余行数的百分比。这两个值需要结合看：

• 当rows很大但filtered很小时（如rows=10000, filtered=1%），说明索引筛选效果不错，最终只需处理约100行。
• 如果rows和filtered都很大，则是性能警讯。比如rows=50000, filtered=80%意味着要处理40000行数据。

在分析慢查询时，我发现一个有趣现象：有时explain显示的rows很乐观，但实际执行却很慢。这是因为rows只是估值，当数据分布不均匀时（如90%数据集中在最近一个月），估值会严重偏离实际。

3. Extra字段的隐藏信息

3.1 常见提示解读

Extra字段包含优化器的额外提示，重要值包括：

• Using index：覆盖索引，无需回表。就像点外卖时所有菜品都在一个套餐里，不需要单独下单。
• Using where：存储引擎检索行后需要额外过滤。好比先筛选出所有男装，再从中找XL码。
• Using temporary：需要创建临时表，常见于GROUP BY和ORDER BY。这就像把资料复印出来再整理，比直接整理原文件更耗时。
• Using filesort：需要额外排序操作。当看到这个提示时，应考虑添加合适的索引。

上周我优化了一个报表查询，Extra显示Using temporary和Using filesort。通过添加(create_time, department)联合索引，两个提示都消失了，查询时间从8秒降到0.5秒。

3.2 容易被忽视的重要提示

• Using index condition：索引条件下推(ICP)，5.6+版本特性。存储引擎能在索引层就过滤数据，减少回表次数。
• Select tables optimized away：优化器发现查询可以直接从索引获取结果，不需要访问表。比如SELECT MIN(id) FROM table且有id索引时。
• Distinct：优化器发现需要去重操作，会提前终止查找。对于有UNIQUE约束的字段，这个提示应该消失。

在电商项目中，商品搜索页曾出现性能问题。explain显示Using where; Using filesort，分析发现是在多个非索引字段上排序和过滤。通过建立包含这些字段的联合索引，并调整查询顺序以匹配索引顺序，性能提升了20倍。

4. 实战优化案例

4.1 订单查询优化

原始查询：

sql复制SELECT * FROM orders 
WHERE create_time > '2023-01-01' 
AND status = 'shipped'
ORDER BY amount DESC;

执行计划显示：

• type: ALL
• key: NULL
• rows: 200000
• Extra: Using where; Using filesort

优化步骤：

1. 添加(create_time, status, amount)联合索引
2. 调整查询条件顺序与索引一致

优化后执行计划：

• type: range
• key: idx_time_status_amount
• rows: 1500
• Extra: Using where

4.2 用户关联查询优化

多表关联查询：

sql复制EXPLAIN SELECT u.name, o.order_no 
FROM users u JOIN orders o ON u.id = o.user_id
WHERE u.age > 18 AND o.status = 'paid';

常见问题：

• 驱动表选择不当导致性能低下
• 关联字段无索引导致嵌套循环

优化方案：

1. 确保user.id和order.user_id都有索引
2. 在order.status字段上添加索引
3. 使用STRAIGHT_JOIN强制驱动表顺序（谨慎使用）

5. 高级技巧与误区

5.1 索引合并优化

当查询条件包含多个索引列时，MySQL可能使用Index Merge优化：

sql复制EXPLAIN SELECT * FROM products 
WHERE category_id = 5 OR price < 100;

执行计划可能显示：

• type: index_merge
• key: idx_category, idx_price
• Extra: Using union(idx_category,idx_price); Using where

但要注意：

• 不是所有OR条件都能触发索引合并
• AND条件的索引合并从5.0开始支持
• 通过optimizer_switch参数可以控制此行为

5.2 执行计划不准的情况

以下几种情况可能导致explain结果不准确：

• 统计信息过期（运行ANALYZE TABLE更新）
• 使用了临时表或存储过程
• 查询涉及视图或派生表
• 使用了FORCE INDEX等提示

我曾遇到一个案例：explain预估rows=100，实际执行却扫描了10万行。原因是该表刚经历大批量删除，统计信息未更新。执行ANALYZE TABLE后，explain结果变得准确。

5.3 JSON格式执行计划

MySQL 5.6+支持JSON格式的详细执行计划：

sql复制EXPLAIN FORMAT=JSON SELECT * FROM large_table WHERE id > 1000;

JSON格式包含更多细节：

• 成本估算（cost）
• 访问方法详情
• 子查询的执行计划
• 优化器决策过程

对于复杂查询，JSON格式能提供更全面的分析视角。特别是查看"optimizer"字段，可以了解优化器是如何重写查询的。