在 MySQL 中使用 EXPLAIN 查询 SQL 语句的执行计划

1、什么是MySQL执行计划

要对执行计划有个比较好的理解,需要先对MySQL的基础结构及查询基本原理有简单的了解。

MySQL本身的功能架构分为三个部分,分别是 应用层、逻辑层、物理层,不只是MySQL ,其他大多数数据库产品都是按这种架构来进行划分的。

应用层

应用层主要负责与客户端进行交互,建立链接,记住链接状态,返回数据,响应请求,这一层是和客户端打交道的。

逻辑层

逻辑层主要负责查询处理、事务管理等其他数据库功能处理,以查询为例。

首先接收到查询SQL之后,数据库会立即分配一个线程对其进行处理,第一步查询处理器会对SQL查询进行优化,优化后会生成执行计划,然后交由计划执行器来执行。

计划执行器需要访问更底层的事务管理器,存储管理器来操作数据,他们各自的分工各有不同,最终通过调用物理层的文件获取到查询结构信息,将最终结果响应给应用层。

物理层

物理层,实际物理磁盘上存储的文件,主要有分文数据文件,日志文件。

通过上面的描述,生成执行计划是执行一条SQL必不可少的步骤,一条SQL性能的好坏,可以通过查看执行计划很直观的看出来,执行计划提供了各种查询类型与级别,方面我们进行查看以及为作为性能分析的依据。

2、如何分析执行计划

MySQL为我们提供了 explain 关键字来直观的查看一条SQL的执行计划。

explain 显示了MySQL如何使用索引来处理 select 语句以及连接表,可以帮助选择更好的索引和写出更优化的查询语句。

mysql> explain select * from payment;

+----+-------------+---------+------------+------+---------------+------+---------+------+-------+----------+-------+

| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows  | filtered | Extra |

+----+-------------+---------+------------+------+---------------+------+---------+------+-------+----------+-------+

|  1 | SIMPLE      | payment | NULL      | ALL  | NULL          | NULL | NULL    | NULL | 16086 |  100.00 | NULL  |

+----+-------------+---------+------------+------+---------------+------+---------+------+-------+----------+-------+

1 row in set, 1 warning (0.01 sec)

查询结构中有 12 列,理解每一列的含义,对理解执行计划至关重要,下面是执行结果中每一列的说明。

id:SELECT识别符,这是SELECT的查询序列号。

select_type:SELECT类型,可以为以下任何一种:

- SIMPLE: 简单SELECT(不使用UNION或子查询)
- PRIMARY: 最外面的SELECT
- UNION: UNION中的第二个或后面的SELECT语句
- DEPENDENT UNION: UNION中的第二个或后面的SELECT语句,取决于外面的查询
- UNION RESULT: UNION 的结果
- SUBQUERY: 子查询中的第一个SELECT
- DEPENDENT SUBQUERY: 子查询中的第一个SELECT,取决于外面的查询
- DERIVED: 导出表的SELECT(FROM子句的子查询)

table:输出的行所引用的表

partitions:如果查询是基于分区表的话,显示查询将访问的分区。

type:联接类型。下面给出各种联接类型,按照从最佳类型到最坏类型进行排序:

- system: 表仅有一行(=系统表)。这是const联接类型的一个特例。
- const: 表最多有一个匹配行,它将在查询开始时被读取。因为仅有一行,在这行的列值可被优化器剩余部分认为是常数。const表很快,因为它们只读取一次!
- eq_ref: 对于每个来自于前面的表的行组合,从该表中读取一行。这可能是最好的联接类型,除了const类型。
- ref: 对于每个来自于前面的表的行组合,所有有匹配索引值的行将从这张表中读取。
- ref_or_null: 该联接类型如同ref,但是添加了MySQL可以专门搜索包含NULL值的行。
- index_merge: 该联接类型表示使用了索引合并优化方法。
- unique_subquery: 该类型替换了下面形式的IN子查询的ref: value IN (SELECT primary_key FROM single_table WHERE some_expr) unique_subquery是一个索引查找函数,可以完全替换子查询,效率更高。
- index_subquery: 该联接类型类似于unique_subquery。可以替换IN子查询,但只适合下列形式的子查询中的非唯一索引: value IN (SELECT key_column FROM single_table WHERE some_expr)
- range: 只检索给定范围的行,使用一个索引来选择行。
- index: 该联接类型与ALL相同,除了只有索引树被扫描。这通常比ALL快,因为索引文件通常比数据文件小。
- ALL: 对于每个来自于先前的表的行组合,进行完整的表扫描,说明查询就需要优化了

一般来说,得保证查询至少达到 range 级别,最好能达到 ref。

possible_keys:指出MySQL能使用哪个索引在该表中找到行

key:显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL。

key_len:显示MySQL决定使用的键长度。如果键是NULL,则长度为NULL。在不损失精确性的情况下,长度越短越好

ref:显示使用哪个列或常数与key一起从表中选择行。

rows:显示MySQL认为它执行查询时必须检查的行数。多行之间的数据相乘可以估算要处理的行数。

filtered:显示了通过条件过滤出的行数的百分比估计值。

Extra:该列包含MySQL解决查询的详细信息

- Distinct: MySQL发现第1个匹配行后,停止为当前的行组合搜索更多的行。
- Select tables optimized away MySQL根本没有遍历表或索引就返回数据了,表示已经优化到不能再优化了
- Not exists: MySQL能够对查询进行LEFT JOIN优化,发现1个匹配LEFT JOIN标准的行后,不再为前面的的行组合在该表内检查更多的行。
- range checked for each record (index map: #):MySQL没有发现好的可以使用的索引,但发现如果来自前面的表的列值已知,可能部分索引可以使用。
- Using filesort:MySQL需要额外的一次传递,以找出如何按排序顺序检索行,说明查询就需要优化了。
- Using index:从只使用索引树中的信息而不需要进一步搜索读取实际的行来检索表中的列信息。
- Using temporary:为了解决查询,MySQL需要创建一个临时表来容纳结果,说明查询就需要优化了。
- Using where:WHERE 子句用于限制哪一个行匹配下一个表或发送到客户。
- Using sort_union(...), Using union(...), Using intersect(...):这些函数说明如何为index_merge联接类型合并索引扫描。
- Using index for group-by:类似于访问表的Using index方式,Using index for group-by表示MySQL发现了一个索引,可以用来查 询GROUP BY或DISTINCT查询的所有列,而不要额外搜索硬盘访问实际的表。

根据上面的阐述,可以在执行计划分析上提供很好的帮助。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,125评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,293评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,054评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,077评论 1 291
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,096评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,062评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,988评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,817评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,266评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,486评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,646评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,375评论 5 342
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,974评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,621评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,642评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,538评论 2 352

推荐阅读更多精彩内容