qidao123.com技术社区-IT企服评测·应用市场
标题:
MySQL EXPLAIN 详解
[打印本页]
作者:
大号在练葵花宝典
时间:
6 天前
标题:
MySQL EXPLAIN 详解
一、
EXPLAIN 是什么?
EXPLAIN 是 MySQL 提供的性能分析工具,用于检察 SQL 查询的
执行计划
(即优化器怎样执行查询)。它通过模拟查询过程(不实际执行 SQL)返回一个表格,展示索引利用、表连接方式、扫描行数等关键信息,资助开辟者诊断性能瓶颈并优化查询。
核心作用
:
分析查询是否高效利用索引。
识别全表扫描、临时表、文件排序等高开销操纵。
提供优化方向,如调整索引或重构 SQL。
二、
为什么要用 EXPLAIN?
性能调优
:快速定位慢查询原因,比方未命中索引(type=ALL)或大量行扫描(rows值过高)。
索引验证
:检查索引是否被实际利用(key列),避免冗余或低效索引。
查询重构
:根据连接范例(type列)和额外信息(Extra列)优化复杂查询逻辑。
三、
怎样利用 EXPLAIN?
根本语法
:
EXPLAIN [FORMAT=TRADITIONAL|JSON|TREE] SELECT ...;
复制代码
FORMAT
:指定输出格式,默认是表格形式(TRADITIONAL),JSON 格式包含更详细信息。
示例
:
EXPLAIN SELECT * FROM users WHERE age > 30;
复制代码
输出结果示例:
idselect_typetabletypepossible_keyskeykey_lenrowsExtra1SIMPLEusersrangeageage41000Using where
四、
执行计划指标详解
1.
id
含义
:查询中每个子查询或操纵的唯一标识符。
规则
:
相同 id:按从上到下顺序执行。
差别 id:数值越大优先级越高(如子查询优先执行)。
2.
select_type
常见范例
:
SIMPLE
:简单查询(无子查询或 UNION)。
PRIMARY
:最外层查询。
SUBQUERY
:子查询中的 SELECT。
DERIVED
:派生表(如 FROM 子句中的子查询)。
3.
type
性能排序
(从优到劣):
system > const > eq_ref > ref > range > index > ALL。
关键范例说明
:
const
:通过主键或唯一索引查询单条记录(如 WHERE id=1)。
eq_ref
:多表关联时,主键或唯一索引的等值匹配(如 JOIN 中主键关联)。
ref
:非唯一索引的等值匹配(可能返回多行)。
range
:索引范围扫描(如 BETWEEN、IN)。
ALL
:全表扫描,需优化索引或查询条件。
4.
key 与 possible_keys
possible_keys
:可能利用的索引(若为 NULL,表示无符合索引)。
key
:实际利用的索引。若未命中索引(key=NULL),需检查 WHERE 条件或添加索引。
5.
rows
含义
:预估需要扫描的行数。若值过大,可能需优化索引或过滤条件。
6.
Extra
关键信息
:
Using index
:覆盖索引(无需回表查询数据)。
Using filesort
:额外排序(需优化 ORDER BY 或索引)。
Using temporary
:利用临时表(常见于 GROUP BY 或复杂 JOIN)。
指标含义常见值/说明
id
查询的序列号(子查询执行顺序)数值越大越先执行;相同 id 按从上到下顺序执行。
select_type
查询范例SIMPLE(简单查询)、PRIMARY(外层查询)、SUBQUERY(子查询)等。
table
当前操纵的表名表名或别名,可能为 <derivedN>(派生表)或 <unionN>(UNION 结果)。
type
访问范例(性能关键指标)const(主键)、ref(索引)、range(范围索引)、ALL(全表扫描)等。
possible_keys
可能利用的索引优化器评估可选的索引,若为 NULL 表示无可用索引。
key
实际利用的索引若为 NULL 表示未利用索引。
key_len
索引利用的字节数长度越短效率越高(比方复合索引是否完整利用)。
rows
预估需要扫描的行数数值越大性能越差(需联合过滤条件判断)。
Extra
额外信息(紧张优化线索)Using index(覆盖索引)、Using where(过滤)、Using filesort(排序)等。
五、
不利用 EXPLAIN 可能出现的题目
性能瓶颈难以定位
无法快速发现未命中索引的全表扫描(type=ALL),导致查询迟钝。
无法识别高开销操纵(如 Using filesort 或 Using temporary),影响团体性能。
索引优化盲目性
可能创建冗余或低效索引(比方对低选择性字段建索引),浪费存储资源。
无法验证索引是否实际生效,导致“假优化”。
资源浪费与扩展性题目
未优化的查询可能大量占用 CPU、内存和磁盘 I/O,降低服务器吞吐量。
复杂查询(如多表 JOIN 或子查询)可能因执行计划不佳,导致体系在高并发下崩溃。
维护资本高
慢查询日记只能发现“已发生”的题目,而 EXPLAIN 能预防潜在性能风险。
缺乏执行计划分析时,代码重构或数据库升级轻易引入性能退化。
六、
总结
必用 EXPLAIN 的场景
:
新上线 SQL 语句的性能验证。
慢查询日记中发现的低效 SQL 分析。
复杂 JOIN 或子查询的优化。
快速优化步骤
:
检查 type 是否为 ALL(全表扫描) → 思量添加索引。
检查 Extra 是否有 Using filesort 或 Using temporary → 优化排序或 GROUP BY。
检查 rows 是否远大于实际输出行数 → 优化 WHERE 条件或索引。
通过 EXPLAIN 分析,可将模糊的“慢查询”转化为具体的优化动作,大幅提升数据库性能!
MySQL 官方文档
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
欢迎光临 qidao123.com技术社区-IT企服评测·应用市场 (https://dis.qidao123.com/)
Powered by Discuz! X3.4