mysql(5) 笔记

Explain 命令

一条查询语句在经过 MySQL 查询优化器的各种基于成本和规则的优化会后生成一个所谓的 执行计划，EXPLAIN 语句来帮助我们查看某个查询语句的具体执行计划

例如：EXPLAIN SELECT 1;

列名	描述
id	在一个大的查询语句中每个 SELECT 关键字都对应一个唯一的 id
select_type	SELECT 关键字对应的那个查询的类型
table	表名
partitions	匹配的分区信息
type	针对单表的访问方法
possible_keys	可能用到的索引
key	实际上使用的索引
key_len	实际使用到的索引长度
ref	当使用索引列等值查询时，与索引列进行等值匹配的对象信息
rows	预估的需要读取的记录条数
filtered	某个表经过搜索条件过滤后剩余记录条数的百分比
Extra	一些额外的信息

• id

  • 一个select 关键字对应一个id；每查询一个表就会生成一条explain 计划；当两表连接查询时，会生成两条执行计划，但id 相同；
  • SELECT * FROM s1 WHERE key1 IN (SELECT * FROM s2); SELECT * FROM s1 UNION SELECT * FROM s2; 子查询和union 可能包含多个select，就会生成多个不同的id；但有时子查询会被重写为连接查询，此时就只有一个相同的id，这也可以作为我们判断是否重写的依据；
  • 当连接查询时，出现在前边的表表示驱动表，出现在后边的表表示被驱动表
  • 对于union 联合查询，还会生成一条id 为null的联合表执行计划；为什么？ union 会对结果去重；同理union all 就不需要去重处理，也就没有id 为null的联合表执行计划；

• possible_keys和key

• possible_keys 列表示在某个查询语句中，对某个表执行单表查询时可能用 到的索引有哪些， key 列表示实际用到的索引有哪些，

• possible_keys列中的值并不是越多越好，可能使用的索引越多，查询优化器计算查询成

  本时就得花费更长时间，所以如果可以的话，尽量删除那些用不到的索引。

• 当使用到联合索引时，可能possible_keys 为null ，key 又存在的情况（联合索引的最左匹配）；

• Extra 额外信息

• No tables used ：没有表可以使用；

• Impossible WHERE 查询字句的where 字句永远为false 时会显示该信息； eg： where 1 != 1 ;

• No matching min/max row 当查询列表处有 MIN 或者 MAX 聚集函数，但是并没有符合 WHERE 子中的搜索条件的记录时，将会提示该额外信息，比方说： SELECT MIN(key1) FROM s1 WHERE key1 = ‘abcdefg’;

• Using index 当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用索引覆盖的情况下，在 Extra 列将会提示该额外信息。

• Using index condition 有些搜索条件中虽然出现了索引列，但却不能使用到索引，比如下边这个查询：

  SELECT * FROM s1 WHERE key1 > ‘z’ AND key1 LIKE ‘%a’;

• Using where 当我们使用全表扫描来执行对某个表的查询，并且该语句的 WHERE 子句中有针对该表的搜索条件时

• Using join buffer 在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度， MySQL 一般会为其分配一块名叫join buffer 的内存块来加快查询速度，也就是我们所讲的 基于块的嵌套循环算法

• Using filesort 有一些情况下对结果集中的记录进行排序是可以使用到索引的，

• Using intersect(…) 、 Using union(…) 和 Using sort_union(…) 使用Intersect索引合并、使用Union索引合并、使用 Sort-Union索引合并

• Using temporary 使用到了临时表。比如去重、排序之类的

• Start temporary, End temporary 查询优化器会优先尝试将 IN 子查询转换成 semi-join，驱动表查询执行计划的 Extra 列将显示 Start temporary 提示，被驱动表查询执行计划 的 Extra 列将显示 End temporary 提示，

• LooseScan 松散扫描

• FirstMatch 在将 In 子查询转为 semi-join 时，如果采用的是 FirstMatch 执行策略

松散扫描

• FirstMatch 在将 In 子查询转为 semi-join 时，如果采用的是 FirstMatch 执行策略