MySQL 使用 explain [SQL]
查看执行计划, 该计划不一定完全正确但可供参考
mysql> explain select * from beike_ershoufang where kid = '101103640578'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: beike_ershoufang
partitions: NULL
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 258
ref: const
rows: 1
filtered: 100.00
Extra: NULL
1 row in set, 1 warning (0.00 sec)
select_type 查询类型
select_type | 含义 |
---|---|
SIMPLE | 简单SELECT(不使用 UNION或子查询) |
PRIMARY | 最外层的SELECT |
UNION | UNION中的第二个或后面的SELECT语句 |
DEPENDENT UNION | UNION中的第二个或后面的SELECT语句, 取决于外面的查询 |
UNION RESULT | UNION 的结果 |
SUBQUERY | 子查询中的第一个SELECT |
DEPENDENT SUBQUERY | 子查询中的第一个SELECT, 取决于外面的查询 |
DERIVED | 导出表的SELECT(FROM子句的子查询) |
DEPENDENT DERIVED | 派生表依赖于另一个表 |
MATERIALIZED | 被物化的子查询 |
UNCACHEABLE SUBQUERY | 对于外层的主表,子查询不可被物化,每次都需要计算(耗时操作) |
UNCACHEABLE UNION | UNION操作中, 内层的不可被物化的子查询 |
table 输出的行所引用的表
partitions 匹配的分区
type access_type 联接类型
type | 含义 |
---|---|
ALL | 对于每个来自于先前的表的行组合, 进行完整的表扫描 |
index | 与ALL相同, 除了只有索引树被扫描. 通常比ALL快, 因为索引文件通常比数据文件小 |
range | 只检索给定范围的行, 使用一个索引来选择行 |
index_subquery | 类似于unique_subquery, 可以替换IN子查询, 但只适合下列形式的子查询中的非唯一索引: value IN (SELECT key_column FROM single_table WHERE some_expr) |
unique_subquery | 该类型替换了下面形式的IN子查询的ref: value IN (SELECT primary_key FROM single_table WHERE some_expr) unique_subquery是一个索引查找函数,可以完全替换子查询,效率更高 |
index_merge | 表示查询使用了两个以上的索引, 最后取交集或者并集. 常见and 、or的条件使用了不同的索引, 官方排序这个在ref_or_null之后, 但实际上由于要读取多个索引, 性能可能大部分时间都不如range |
ref_or_null | 同ref, 但是添加了MySQL可以专门搜索包含NULL值的行 |
fulltext | 全文索引检索. 要注意, 全文索引的优先级很高, 若全文索引和普通索引同时存在时, mysql不管代价, 优先选择使用全文索引 |
ref | 对于每个来自于前面的表的行组合, 所有有匹配索引值的行将从这张表中读取 |
eq_ref | 对于每个来自于前面的表的行组合, 从该表中读取一行. 除const类型,可能是最好的联接类型 |
const | 表最多有一个匹配行, 它将在查询开始时被读取 |
system | 表仅有一行(=系统表). 这是const联接类型的一个特例 |
possible_keys 可能的索引项
key 显示MySQL实际决定使用的键(索引). 如果没有选择索引,键是NULL
key_len 显示MySQL决定使用的键长度. 如果键是NULL,则长度为NULL
ref 显示使用哪个列或常数与key一起从表中选择行
rows 显示MySQL认为它执行查询时必须检查的行数
filtered 按表条件过滤的百分比
Extra 附加信息
Extra | 含义 |
---|---|
distinct | 在select部分使用了distinc关键字 |
no tables used | 不带from字句的查询或者From dual查询 |
not exists | 使用not in()形式子查询或not exists运算符的连接查询, 这种叫做反连接. 即, 一般连接查询是先查询内表, 再查询外表, 反连接就是先查询外表, 再查询内表 |
using filesort | 排序时无法使用到索引时, 就会出现这个. 常见于order by和group by语句中 |
using index | 查询时不需要回表查询, 直接通过索引就可以获取查询的数据. |
using join buffer(block nested loop), using join buffer(batched key accss) | 5.6.x之后的版本优化关联查询的BNL, BKA特性. 主要是减少内表的循环数量以及比较顺序地扫描查询. |
using sort_union, using_union, using intersect, using sort_intersection | |
using intersect | 表示使用and的各个索引的条件时, 该信息表示是从处理结果获取交集 |
using union | 表示使用or连接各个使用索引的条件时, 该信息表示从处理结果获取并集 |
using sort_union和using sort_intersection | 与前面两个对应的类似, 只是他们是出现在用and和or查询信息量大时, 先查询主键, 然后进行排序合并后, 才能读取记录并返回. |
using temporary | 表示使用了临时表存储中间结果. 临时表可以是内存临时表和磁盘临时表, 执行计划中看不出来, 需要查看status变量, used_tmp_table, used_tmp_disk_table才能看出来. |
using where | 表示存储引擎返回的记录并不是所有的都满足查询条件, 需要在server层进行过滤. 查询条件中分为限制条件和检查条件, 5.6之前, 存储引擎只能根据限制条件扫描数据并返回, 然后server层根据检查条件进行过滤再返回真正符合查询的数据. 5.6.x之后支持ICP特性, 可以把检查条件也下推到存储引擎层, 不符合检查条件和限制条件的数据, 直接不读取, 这样就大大减少了存储引擎扫描的记录数量. extra列显示using index condition |
firstmatch(tb_name) | 5.6.x开始引入的优化子查询的新特性之一, 常见于where字句含有in()类型的子查询. 如果内表的数据量比较大, 就可能出现这个 |
loosescan(m..n) | 5.6.x之后引入的优化子查询的新特性之一, 在in()类型的子查询中, 子查询返回的可能有重复记录时, 就可能出现这个 |