使用EXPLAIN分析SQL执行计划可定位性能瓶颈，通过查看type、key、Extra等字段判断索引使用情况，避免全表扫描和临时排序，结合联合索引优化查询。
理解MySQL执行计划是优化SQL查询的关键步骤。当你发现某条查询运行缓慢时，通过EXPLAIN命令查看其执行计划，可以清楚地知道MySQL是如何执行这条SQL语句的，从而找到性能瓶颈并进行优化。
一、如何使用EXPLAIN查看执行计划
在SELECT语句前加上EXPLAIN即可查看执行计划：
EXPLAIN SELECT * FROM users WHERE age > 30;
执行后会返回一个表格，包含多个字段，每个字段都提供了关于查询执行方式的重要信息。
二、执行计划各列详解
以下是EXPLAIN输出中常见列的含义：
1. id
表示查询中每个SELECT子句的标识符。相同id值代表属于同一查询块；id越大，越先执行；如果是UNION操作，其中一个id为NULL。
2. select_type
说明查询的类型，常见取值有：
- SIMPLE：简单查询（不包含子查询或UNION）
- PRIMARY：最外层的SELECT
- SUBQUERY：子查询中的第一个SELECT
- DERIVED：派生表（如FROM子句中的子查询）
- UNION：UNION中的第二个或之后的SELECT
3. table
显示当前这一行所引用的是哪张表。如果表有别名，则显示别名。
4. partitions
匹配的分区信息，如果没有分区则为NULL。适用于分区表。
5. type
连接类型，反映访问表的方式，从最优到最差：
- system：表只有一行（系统表）
- const：通过主键或唯一索引定位单行
- eq_ref：通常出现在JOIN中，主键或唯一索引被完全使用
- ref：非唯一索引等值匹配
- range：索引范围扫描（如BETWEEN、IN、>等）
- index：全索引扫描（比ALL快，因为只读索引）
- ALL：全表扫描（最差情况，应尽量避免）
重点关注是否出现ALL，这通常意味着缺少有效索引。
6. possible_keys
MySQL认为可能用到的索引，但不一定实际使用。
7. key
实际使用的索引。如果为NULL，说明没有使用索引，需要考虑添加。
8. key_len
使用的索引长度（字节）。可用于判断复合索引的使用情况。例如，INT字段通常占4字节，若key_len=4，说明只用了复合索引的第一列。
9. ref
显示索引的哪一列被使用了，或者是一个常量值（如const）。
10. rows
MySQL估计需要扫描的行数。这个值越小越好，如果很大，说明查询效率低。
11. filtered
表示存储引擎返回的数据中，被服务器层过滤后剩余的百分比（基于统计信息估算）。例如filtered=10，表示只有10%的行满足条件。
12. Extra
包含额外的执行信息，常见值有：
- Using where：使用WHERE条件过滤数据
- Using index：使用覆盖索引，无需回表，性能好
- Using temporary：需要创建临时表（如GROUP BY或ORDER BY涉及不同列）
- Using filesort：需要排序操作，可能影响性能
- Using join buffer：使用连接缓存（通常用于非索引JOIN）
- NULL：正常情况
重点关注Using temporary和Using filesort，它们通常是性能瓶颈。
三、实战分析示例
假设有一个用户表：
CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), age INT, city VARCHAR(20), INDEX idx_age (age), INDEX idx_city (city) );
执行以下查询：
EXPLAIN SELECT name FROM users WHERE age > 25 AND city = 'Beijing';
可能的执行计划中：
- type: range（因age > 25 是范围查询）
- key: idx_age 或 idx_city（取决于哪个选择性更高）
- Extra: Using where（未用覆盖索引）
优化建议：建立联合索引(city, age)，因为city是等值查询，age是范围查询，这样能更高效利用索引。
四、扩展：EXPLAIN FORMAT=JSON
使用JSON格式可以获得更详细的执行信息：
EXPLAIN FORMAT=JSON SELECT ...
它会提供成本估算、索引使用详情、是否使用索引下推（ICP）等高级信息，适合深度调优。
基本上就这些。掌握EXPLAIN，你就掌握了SQL优化的第一把钥匙。多看、多练、结合实际业务场景，才能真正提升数据库性能。
