【mysql】mysql 调优之 ——执行计划 explain

1.what is explain(explain 是个什么东东)

explain(解释)，在 Mysql 中作为一个关键词，用来解释 Mysql 是如何执行语句，可以连接 select 、delete、insert、update 语句。

通常我们使用 explain 连接一条 select 语句，查看运行状态，判断是否需要优化。

2.how to use explain（如何使用呢）

栗子：

explain select s.name,s.id,s.age,s.create_time from student s;

输出：

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

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

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

|  1 | SIMPLE      | s     | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    7 |   100.00 | NULL  |

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

1 row in set, 1 warning (0.00 sec)

官方：

EXPLAIN  [explain_type]  explainable_stmt

explain_type: {

    EXTENDED

  | PARTITIONS

  | FORMAT = format_name

}

explainable_stmt: {

    SELECT statement

  | DELETE statement

  | INSERT statement

  | REPLACE statement

  | UPDATE statement

}

输出的列名：

id : select 标识符
select_type:select 类型

`select_type` 可选值	含义
`SIMPLE`	简单的 select，没有使用 UNION 或者子查询
`PRIMARY`	最外一层的 select
`UNION`	UNION 中第二个或者后面的 select 语句
`DEPENDENT UNION`	UNION 中第二个或者后面的 select 语句，依赖于外层的 select
`UNION RESULT`	UNION 的结果
`SUBQUERY`	子查询的第一个 select
`DEPENDENT SUBQUERY`	子查询的第一个 select,取决于外层的 select
`DERIVED`	派生表
`MATERIALIZED`	Materialized subquery
`UNCACHEABLE SUBQUERY`	无法缓存结果的子查询，必须为外部查询的每一行重新计算其结果
`UNCACHEABLE UNION`	UNION 查询中不可缓存的子查询中的第二个或者后一个 select

table：输出行对应的表
partitions：匹配的分区
type：join 类型
possible_keys：可选的索引，可以通过 show index from tbl_name 查看表有哪些索引。
key：实际选择的索引
key_len：实际使用索引的长度
ref：与索引比较的列
rows：扫描行数的预估值
filtered：按表条件筛选的行的百分比
Extra：额外信息

3.重点关注的列

3.1 type 列

type 列描述了表的 join 类型，以下以查询的最优到最差的排序列出了可能值：

system ：当表只有一条数据（= system table）时，为 system 类型，是 const 类型的特例。

const：当表最多只有一条数据相匹配时，为 const 类型。因为只有一行，所以优化器的其余部分可以将此行列中的值视为常量（constant）。const表非常快，因为它们只读一次。在使用主键或者唯一索引和常量比较时，即为 const 类型。

如下的查询，tbl_name 可以被用作 const 表：

SELECT * FROM tbl_name WHERE primary_key=1;

SELECT * FROM tbl_name

  WHERE primary_key_part1=1 AND primary_key_part2=2;

栗子：

explain select s.* from student s where s.id = 1

输出：

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

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

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

|  1 | SIMPLE      | s     | NULL       | const | PRIMARY       | PRIMARY | 8       | const |    1 |   100.00 | NULL  |

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

eq_ref：通常出现在多表 join 查询，并且关联的字段是主键或者唯一非空索引，即后表只能匹配一条数据。

下面的示例，可以使用 eq_ref join 来处理 ref_table：

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：通常出现在多表 join 查询，关联使用了最左前缀原则的索引或者关联的是非主键或者非唯一索引（也就是说，join 不能根据索引选择单行数据）

下面的示例，Mysql 可以使用 ref join 来处理 ref_table:

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：使用全文索引执行 join
ref_or_null：在 ref 的基础上，另外还搜索了包含空值的行

下面的示例，Mysql 可以使用 ref_or_null join 来处理 ref_table:：

SELECT * FROM ref_table

  WHERE key_column=expr OR key_column IS NULL;

index_merge: 合并索引优化
unique_subquery：子查询返回唯一主键。

形如下面的示例：

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：当索引和常量使用诸如=, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, LIKE, or IN() 进行比较时，可以使用 range.

例如：

SELECT * FROM tbl_name

  WHERE key_column = 10;

SELECT * FROM tbl_name

  WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name

  WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name

  WHERE key_part1 = 10 AND key_part2 IN (10,20,30);

index：和 all 类似，只不过扫描的是索引树
all：全表扫描，可以通过增加索引避免全表扫描

3.2 keys 列：真正使用的索引

3.3 rows 列：扫描的记录数

4.使用 explain 提升查询性能案例分析

假设有如下的 sql：根据订单日期和店员id 查询订单信息（已创建了订单日期的索引），查询结果返回 18条记录。

  SELECT * FROM orders

  WHERE YEAR(o_orderdate) = 1992 AND MONTH(o_orderdate) = 4

  AND o_clerk LIKE '%0223';

Explain 输出执行计划：

问题所在：

根据 type 为 ALL ，查询进行了全表扫描，被扫描的记录 rows 为 150万。
possible_keys 和 ky 均为空，订单日期索引完全失效，原因在于被索引的字段使用了处理函数导致索引失效

4.1.修改sql 保证订单日期索引正常，

 SELECT * FROM orders

  WHERE o_orderdate BETWEEN '1992-04-01' AND '1992-04-30'

  AND o_clerk LIKE '%0223';

重新使用 Explain 查看执行计划：

发现：type 由 ALL 变为 range ，订单日期索引得以利用，被扫描的记录由 15万降为 3.3万左右。

4.2.另一个优化点在店员字段的过滤

为店员字段创建索引：

CREATE INDEX i_o_clerk ON orders(o_clerk);

再次输出执行计划：

发现：基本上并没有什么变化，新建的索引没有被利用，原因在于该字段是模糊查询，过滤指定后缀的店员信息。但是索引对于后缀过滤会失效（尽管索引对于前缀有效果）。

修改sql，全量过滤店员字段：

SELECT * FROM orders

WHERE o_orderdate BETWEEN '1992-04-01' AND '1992-04-30'

AND o_clerk LIKE 'Clerk#000000223';

再次输出执行计划：

发现：可用索引增加，真正使用的索引变为店员字段上的索引，被扫描的行由 3.3万降为 1546。

4.3.对于多条件查询，可以考虑使用组合索引

创建如下索引：

CREATE INDEX io_clerk_date ON orders(o_clerk, o_orderdate)

　　** ：这里将 o_clerk 放在 o_orderdate 之前，因为 o_orderdate 使用了范围，更优的放在前面。

再次输出执行计划：

发现：使用了组合索引，被扫描记录即为输出的18条记录。效率已最优化。

多次优化的总结：

Type	Possible keys	Key	Rows Scanned	Duration (seconds)	Extra info	Rows returned
all	NULL	NULL	1.50M	1.201	Using where	18
range	i_o_orderdate	i_o_orderdate	32642	0.281	Using index condition; Using where	18
range	i_o_orderdate, i_o_clerk	i_o_clerk	1546	0.234	Using index condition; Using where	18
range	i_o_orderdate, i_o_clerk, i_o_clerk_date	i_o_clerk_date	18	0.234	Using index condition	18