EXPLAIN 使用、可视化、性能和扩展测试

EXPLAIN使用

explain 可以用来分析sql的执行计划。格式如下:

{EXPLAIN | DESCRIBE | DESC}
    tbl_name [col_name | wild]

{EXPLAIN | DESCRIBE | DESC}
    [explain_type]
    {explainable_stmt | FOR CONNECTION connection_id}

{EXPLAIN | DESCRIBE | DESC} ANALYZE select_statement    

explain_type: {
    FORMAT = format_name
}

format_name: {
    TRADITIONAL
  | JSON
  | TREE
}

explainable_stmt: {
    SELECT statement
  | TABLE statement
  | DELETE statement
  | INSERT statement
  | REPLACE statement
  | UPDATE statement
}

一般用的最多的是第二种格式。例

DESC SELECT * FROM salaries WHERE to_date = '1991-06-25'

返回
file

结果输出展示

字段 format=json时的名称 含义
id select_id 该语句的唯一标识
select_type 查询类型
table table_name 表名
partitions partitions 匹配的分区
type access_type 联接类型
possible_keys possible_keys 可能的索引选择
key key 实际选择的索引
key_len key_length 索引的长度
ref ref 索引的哪一列被引用了
rows rows 估计要扫描的行
filtered filtered 表示符合查询条件的数据百分比
Extra 没有 附加信息

结果解读

id

该语句的唯一标识。如果explain的结果包括多个id值,则数字越大越先执行;而对于相同id的行,则表示从上往下依次执行。

select_type

查询类型,有以下取值

查询类型 作用
SIMPLE 简单查询(未使用UNION或子查询)
PRIMARY 最外层的查询
UNION 在UNION中的第二个和随后的SELECT被标记为UNION。如果UNION被FROM子句中的子查询包含,那么它的第一个SELECT会被标记为DERIVED。
DEPENDENT UNION UNION中的第二个或后面的查询,依赖了外面的查询
UNION RESULT UNION的结果
SUBQUERY 子查询中的第一个 SELECT
DEPENDENT SUBQUERY 子查询中的第一个 SELECT,依赖了外面的查询
DERIVED 用来表示包含在FROM子句的子查询中的SELECT,MySQL会递归执行并将结果放到一个临时表中。MySQL内部将其称为是Derived table(派生表),因为该临时表是从子查询派生出来的
DEPENDENT DERIVED 派生表,依赖了其他的表
MATERIALIZED 物化子查询
UNCACHEABLE SUBQUERY 子查询,结果无法缓存,必须针对外部查询的每一行重新评估
UNCACHEABLE UNION UNION属于UNCACHEABLE SUBQUERY的第二个或后面的查询

table

表示当前这一行正在访问哪张表,如果SQL定义了别名,则展示表的别名

partitions

当前查询匹配记录的分区。对于未分区的表,返回null

type

连接类型,有如下几种取值,性能从好到坏排序, 如下:

  • system:该表只有一行(相当于系统表),system是const类型的特例
  • const:针对主键或唯一索引的等值查询扫描, 最多只返回一行数据. const 查询速度非常快, 因为它仅仅读取一次即可
  • eq_ref:当使用了索引的全部组成部分,并且索引是PRIMARY KEY或UNIQUE NOT NULL 才会使用该类型,性能仅次于system及const。
-- 多表关联查询,单行匹配
SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

-- 多表关联查询,联合索引,多行匹配
SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;
  • ref:当满足索引的最左前缀规则,或者索引不是主键也不是唯一索引时才会发生。如果使用的索引只会匹配到少量的行,性能也是不错的。
-- 根据索引(非主键,非唯一索引),匹配到多行
SELECT * FROM ref_table WHERE key_column=expr;

-- 多表关联查询,单个索引,多行匹配
SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

-- 多表关联查询,联合索引,多行匹配
SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;
  • fulltext:全文索引
  • ref_or_null:该类型类似于ref,但是MySQL会额外搜索哪些行包含了NULL。这种类型常见于解析子查询
SELECT * FROM ref_table
  WHERE key_column=expr OR key_column IS NULL;
  • index_merge:此类型表示使用了索引合并优化,表示一个查询里面用到了多个索引
  • unique_subquery:该类型和eq_ref类似,但是使用了IN查询,且子查询是主键或者唯一索引。例如:
value IN (SELECT primary_key FROM single_table WHERE some_expr)
  • index_subquery:和unique_subquery类似,只是子查询使用的是非唯一索引
value IN (SELECT key_column FROM single_table WHERE some_expr)
  • range:范围扫描,表示检索了指定范围的行,主要用于有限制的索引扫描。比较常见的范围扫描是带有BETWEEN子句或WHERE子句里有>、>=、<、<=、IS NULL、<=>、BETWEEN、LIKE、IN()等操作符。
SELECT * FROM tbl_name
  WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name
  WHERE key_column IN (10,20,30);
  • index:全索引扫描,和ALL类似,只不过index是全盘扫描了索引的数据。当查询仅使用索引中的一部分列时,可使用此类型。有两种场景会触发:
  1. 如果索引是查询的覆盖索引,并且索引查询的数据就可以满足查询中所需的所有数据,则只扫描索引树。此时,explain的Extra 列的结果是Using index。index通常比ALL快,因为索引的大小通常小于表数据。

  2. 按索引的顺序来查找数据行,执行了全表扫描。此时,explain的Extra列的结果不会出现Uses index。

  • ALL:全表扫描,性能最差。

possible_keys

展示当前查询可以使用哪些索引,这一列的数据是在优化过程的早期创建的,因此有些索引可能对于后续优化过程是没用的。

key

表示MySQL实际选择的索引

key_len

索引使用的字节数。由于存储格式,当字段允许为NULL时,key_len比不允许为空时大1字节。

ref

表示将哪个字段或常量和key列所使用的字段进行比较。如果ref是一个函数,则使用的值是函数的结果。要想查看是哪个函数,可在EXPLAIN语句之后紧跟一个SHOW WARNING语句。

rows

MySQL估算会扫描的行数,数值越小越好。

filtered

表示符合查询条件的数据百分比,最大100。用rows × filtered可获得和下一张表连接的行数。例如rows = 1000,filtered = 50%,则和下一张表连接的行数是500。

在MySQL 5.7之前,想要显示此字段需使用explain extended命令;
MySQL.5.7及更高版本,explain默认就会展示filtered

Extra

展示有关本次查询的附加信息,取值如下:

  • Child of ‘table’ pushed join@1: 此值只会在NDB Cluster下出现。
  • const row not found : 例如查询语句SELECT … FROM tbl_name,而表是空的
  • Deleting all rows : 对于DELETE语句,某些引擎(例如MyISAM)支持以一种简单而快速的方式删除所有的数据,如果使用了这种优化,则显示此值
  • Distinct : 查找distinct值,当找到第一个匹配的行后,将停止为当前行组合搜索更多行
  • FirstMatch(tbl_name) : 当前使用了半连接FirstMatch策略,详见https://www.cnblogs.com/abclife/p/10895624.html
  • Full scan on NULL key : 子查询中的一种优化方式,在无法通过索引访问null值的时候使用
  • Impossible HAVING : HAVING子句始终为false,不会命中任何行
  • Impossible WHERE : WHERE子句始终为false,不会命中任何行
  • Impossible WHERE noticed after reading const tables : MySQL已经读取了所有const(或system)表,并发现WHERE子句始终为false
  • LooseScan(m…n): 当前使用了半连接LooseScan策略,详见 https://www.javacoder.cn/?p=39
  • No matching min/max row : 没有任何能满足例如 SELECT MIN(…) FROM … WHERE condition 中的condition的行
  • no matching row in const table : 对于关联查询,存在一个空表,或者没有行能够满足唯一索引条件
  • No matching rows after partition pruning : 对于DELETE或UPDATE语句,优化器在partition pruning(分区修剪)之后,找不到要delete或update的内容
  • No tables used : 当此查询没有FROM子句或拥有FROM DUAL子句时出现。例如:explain select 1
  • Not exists : MySQL能对LEFT JOIN优化,在找到符合LEFT JOIN的行后,不会为上一行组合中检查此表中的更多行。例如:
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
  WHERE t2.id IS NULL;

假设t2.id定义成了NOT NULL ,此时,MySQL会扫描t1,并使用t1.id的值查找t2中的行。 如果MySQL在t2中找到一个匹配的行,它会知道t2.id永远不会为NULL,并且不会扫描t2中具有相同id值的其余行。也就是说,对于t1中的每一行,MySQL只需要在t2中只执行一次查找,而不考虑在t2中实际匹配的行数。
在MySQL 8.0.17及更高版本中,如果出现此提示,还可表示形如 NOT IN (subquery) 或 NOT EXISTS (subquery) 的WHERE条件已经在内部转换为反连接。这将删除子查询并将其表放入最顶层的查询计划中,从而改进查询的开销。通过合并半连接和反联接,优化器可以更加自由地对执行计划中的表重新排序,在某些情况下,可让查询提速。你可以通过在EXPLAIN语句后紧跟一个SHOW WARNING语句,并分析结果中的Message列,从而查看何时对该查询执行了反联接转换。

两表关联只返回主表的数据,并且只返回主表与子表没关联上的数据,这种连接就叫反连接

  • Plan isn’t ready yet : 使用了EXPLAIN FOR CONNECTION,当优化器尚未完成为在指定连接中为执行的语句创建执行计划时, 就会出现此值。

  • Range checked for each record (index map: N): MySQL没有找到合适的索引去使用,但是去检查是否可以使用range或index_merge来检索行时,会出现此提示。index map N索引的编号从1开始,按照与表的SHOW INDEX所示相同的顺序。 索引映射值N是指示哪些索引是候选的位掩码值。 例如0x19(二进制11001)的值意味着将考虑索引1、4和5。
    示例:下面例子中,name是varchar类型,但是条件给出整数型,涉及到隐式转换。
    图中t2也没有用到索引,是因为查询之前我将t2中name字段排序规则改为utf8_bin导致的链接字段排序规则不匹配。

explain select a.* from t1 a left  join t2 b
on t1.name = t2.name
where t2.name = 2;

结果:
file

SELECT
  ...
FROM
  t,
  LATERAL (derived table that refers to t) AS dt
...
  • Scanned N databases : 表示在处理INFORMATION_SCHEMA表的查询时,扫描了几个目录,N的取值可以是0,1或者all。详见 https://www.cnblogs.com/abclife/p/10895531.html
  • Select tables optimized away : 优化器确定:①最多返回1行;②要产生该行的数据,要读取一组确定的行,时会出现此提示。一般在用某些聚合函数访问存在索引的某个字段时,优化器会通过索引直接一次定位到所需要的数据行完成整个查询时展示,例如下面这条SQL。
explain
select min(id)
from t1;
  • Skip_open_table, Open_frm_only, Open_full_table: 这些值表示适用于INFORMATION_SCHEMA表查询的文件打开优化;

    1. Skip_open_table:无需打开表文件,信息已经通过扫描数据字典获得
    2. Open_frm_only:仅需要读取数据字典以获取表信息
    3. Open_full_table:未优化的信息查找。表信息必须从数据字典以及表文件中读取
  • Start temporary, End temporary:表示临时表使用Duplicate Weedout策略,详见 https://www.cnblogs.com/abclife/p/10895531.html

  • unique row not found : 对于形如 SELECT … FROM tbl_name 的查询,但没有行能够满足唯一索引或主键查询的条件

  • Using filesort: 当Query 中包含 ORDER BY 操作,而且无法利用索引完成排序操作的时候,MySQL Query Optimizer 不得不选择相应的排序算法来实现。数据较少时从内存排序,否则从磁盘排序。Explain不会显示的告诉客户端用哪种排序。官方解释:“MySQL需要额外的一次传递,以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序,并按排序顺序检索行”

  • Using index : 仅使用索引树中的信息从表中检索列信息,而不必进行其他查找以读取实际行。当查询仅使用属于单个索引的列时,可以使用此策略。例如:

explain SELECT id FROM t
  1. MySQL分成了Server层和引擎层,下推指的是将请求交给引擎层处理。
  2. 理解这个功能,可创建所以INDEX (zipcode, lastname, firstname),并分别用如下指令,
    SET optimizer_switch = 'index_condition_pushdown=off'; 
    SET optimizer_switch = 'index_condition_pushdown=on';

开或者关闭索引条件下推,并对比:

explain SELECT * FROM people
  WHERE zipcode='95054'
  AND lastname LIKE '%etrunia%'
  AND address LIKE '%Main Street%';

的执行结果。
index condition pushdown从MySQL 5.6开始支持,是MySQL针对特定场景的优化机制,感兴趣的可以看下 https://blog.51cto.com/lee90/2060449

    -- name字段有索引
    explain SELECT name FROM t1 group by name
    -- name无索引
    explain SELECT name FROM t1 group by name
  • Using where: 如果我们不是读取表的所有数据,或者不是仅仅通过索引就可以获取所有需要的数据,则会出现using where信息
    explain SELECT * FROM t1 where id > 5
  • Using where with pushed condition: 仅用于NDB
  • Zero limit: 该查询有一个limit 0子句,不能选择任何行
    explain SELECT name FROM resource_template limit 0

估计查询性能

多数情况下,你可以通过计算磁盘的搜索次数来估算查询性能。对于比较小的表,通常可以在一次磁盘搜索中找到行(因为索引可能已经被缓存了),而对于更大的表,你可以使用B-tree索引进行估算:你需要进行多少次查找才能找到行:
*log(row_count) / log(index_block_length / 3 2 / (index_length + data_pointer_length)) + 1*
在MySQL中,index_block_length通常是1024字节,数据指针一般是4字节。比方说,有一个500,000的表,key是3字节,那么根据计算公式
log(500,000)/log(1024/3
2/(3+4)) + 1 = 4 次搜索。
该索引将需要500,000 7 3/2 = 5.2MB的存储空间(假设典型的索引缓存的填充率是2/3),因此你可以在内存中存放更多索引,可能只要一到两个调用就可以找到想要的行了。
但是,对于写操作,你需要四个搜索请求来查找在何处放置新的索引值,然后通常需要2次搜索来更新索引并写入行。
前面的讨论并不意味着你的应用性能会因为log N而缓慢下降。只要内容被OS或MySQL服务器缓存,随着表的变大,只会稍微变慢。在数据量变得太大而无法缓存后,将会变慢很多,直到你的应用程序受到磁盘搜索约束(按照log N增长)。为了避免这种情况,可以根据数据的增长而增加key的。对于MyISAM表,key的缓存大小由名为key_buffer_size的系统变量控制,详见 https://dev.mysql.com/doc/refman/8.0/en/server-configuration.html

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注