在数据库性能调优中，EXPLAIN是MySQL提供的核心工具之一。它通过解析SQL语句的执行计划，帮助开发者直观理解查询如何访问数据、是否使用索引、是否存在潜在性能瓶颈。本文将结合真实案例与官方文档，系统讲解EXPLAIN的使用方法及优化策略。
一、EXPLAIN的核心价值
EXPLAIN通过模拟查询优化器的决策过程，输出以下关键信息：
- 数据访问路径：全表扫描（ALL）还是索引扫描（index/range）
- 索引使用情况：实际使用的索引（key列）与可能使用的索引（possible_keys列）
- 连接顺序与方式：表关联顺序（id列）及连接类型（type列）
- 额外操作：是否需要临时表（Using temporary）、文件排序（Using filesort）等
典型场景：某电商系统查询商品列表时响应缓慢，通过EXPLAIN发现查询使用了ALL类型扫描，扫描行数达百万级。优化后通过添加复合索引，扫描行数降至千级，响应时间从3秒降至0.02秒。
二、EXPLAIN输出字段详解
1. 基础结构
EXPLAINSELECTu.name,o.order_dateFROMusers uJOINorders oONu.id=o.user_idWHEREu.status='active'ANDo.amount>100;输出结果示例：
| id | select_type | table | type | possible_keys | key | rows | Extra |
|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | u | ref | idx_status | idx_status | 1000 | Using where |
| 1 | SIMPLE | o | ref | idx_user_id | idx_user_id | 50 | Using index condition |
2. 关键字段解析
type列（访问类型，性能从高到低）：
system>const>eq_ref>ref>range>index>ALL- 示例：
type=range表示使用索引范围查询（如BETWEEN、>），而type=ALL表示全表扫描
key列：
- 实际使用的索引，若为
NULL表示未使用索引 - 案例：某查询
possible_keys显示有3个候选索引，但key为NULL，说明索引选择策略失效
- 实际使用的索引，若为
Extra列（需重点优化）：
Using index：覆盖索引，无需回表（最佳情况）Using filesort：需额外排序，可能引发性能问题Using temporary：使用临时表，常见于GROUP BY
三、实战优化案例
案例1：索引失效导致全表扫描
问题SQL：
SELECT*FROMproductsWHEREnameLIKE'%手机%';EXPLAIN结果：
type: ALL, key: NULL, Extra: Using where优化方案：
- 避免前导通配符（
%开头），改用name LIKE '手机%' - 若必须模糊查询，考虑使用全文索引（FULLTEXT）
案例2：覆盖索引优化
原始SQL：
SELECTuser_id,order_dateFROMordersWHEREuser_id=1001;优化前：
- 索引：
PRIMARY KEY (id) - EXPLAIN显示需回表查询（Extra无
Using index）
优化后：
- 添加复合索引：
ALTER TABLE orders ADD INDEX idx_user_date (user_id, order_date); - EXPLAIN结果：
type: ref, key: idx_user_date, Extra: Using index- 扫描行数从10万降至10行，且无需回表
案例3：连接查询优化
问题SQL：
SELECTu.name,o.amountFROMusers uLEFTJOINorders oONu.id=o.user_idWHEREo.amount>500;EXPLAIN问题：
LEFT JOIN导致优化器无法使用o.amount索引过滤- 实际执行计划先扫描users表（10万行），再关联orders表
优化方案：
- 改用
INNER JOIN（若业务允许） - 或调整WHERE条件顺序：
SELECTu.name,o.amountFROMorders oINNERJOINusers uONo.user_id=u.idWHEREo.amount>500;- 优化后扫描行数从10万+降至1000+
四、高级技巧
1. 使用EXPLAIN FORMAT=JSON
获取更详细的执行计划信息，包括成本估算、循环次数等：
EXPLAINFORMAT=JSONSELECT*FROMlarge_tableWHEREcategory='A';输出示例：
{"query_block":{"select_id":1,"cost_info":{"query_cost":"1234.56"},"table":{"table_name":"large_table","access_type":"ref","key":"idx_category","rows_examined_per_scan":1000,"filtered":10.00}}}2. 分析慢查询日志
结合slow_query_log定位问题SQL：
-- 开启慢查询日志SETGLOBALslow_query_log='ON';SETGLOBALlong_query_time=2;-- 设置阈值（秒）-- 分析工具示例（使用mysqldumpslow）mysqldumpslow-s t/var/log/mysql/mysql-slow.log3. 索引条件下推（ICP）
当Extra显示Using index condition时，表示优化器将WHERE条件过滤下推到存储引擎层，减少回表次数。例如：
-- 假设orders表有(user_id, status)复合索引EXPLAINSELECT*FROMordersWHEREuser_id=1001ANDstatus='paid';输出可能显示：
type: ref, key: idx_user_status, Extra: Using index condition五、常见误区与注意事项
索引并非越多越好：
- 每个额外索引增加写操作开销
- 案例：某表有10个索引，INSERT性能下降40%
避免过度优化：
- 对小表（<1000行）的全表扫描可能比使用索引更快
- 使用
FORCE INDEX需谨慎，可能适得其反
定期更新统计信息：
ANALYZETABLElarge_table;-- 更新表统计信息监控索引使用率：
SELECT*FROMperformance_schema.table_io_waits_summary_by_index_usage;
六、总结
通过EXPLAIN分析SQL执行计划是数据库优化的核心技能。开发者应重点关注：
- 访问类型（type列）是否高效
- 是否使用了合适的索引（key列）
- 是否存在额外的排序/临时表操作（Extra列）
建议建立优化流程：
- 识别慢查询（通过慢查询日志或APM工具）
- 使用EXPLAIN分析执行计划
- 根据分析结果调整索引或SQL写法
- 验证优化效果（对比优化前后的rows/Extra字段）
掌握这些技巧后，开发者可系统化解决80%以上的数据库性能问题，显著提升系统吞吐量与响应速度。
)