MySQL执行计划复习

MySQL执行计划分析

Ⅰ、认识执行计划的每一个字段

(root@localhost) [(none)]> desc select 1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | No tables used |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

1.1 id

• 单纯的join，id都是1，且从上到下
• subquery、scala subquery都会使id递增

1.2 select type

• simple
  • 不使用union或者subquery的简单query
  • 子查询被优化器打开，失效了
• primary
  • 使用union结合select时，第一个select type
  • subquery的query
• union
  • 使用union结合select除了第一个select type为primary，其他为union(extra中union result是union去掉重复值的临时表)
  • 5.7开始union all不会出现union result，由于不去重
• subquery
  • 不是用在from后面的subquery
  • 和外部表无关联
  • subquery(标量子查询)执行计划没错误，不表明sql执行没错(不能超过1行数据，subquery return more than 1 row)
• dependent subquery
  • 必须依附于外面的值
  • scala subquery(和外部有关系的标量子查询)
  • exists
• derived
  • from位置以后的subquery
  • derived是生成在内存或者临时表空间中
  • 若是derived做驱动表时，要点是减小数据量
  • 看成被驱动表时产生auto_key索引，也是以减小数据量为目
  • 5.7中optimizer_switch='derived_merge=on'能够把简单subquery打开成join
  • derived_merge为on时被驱动表的链接条件要有索引，为off时被驱动表结果集要小
  • 5.7的derived_merge可能致使子查询中order by失效
  • 5.7如下操做能够防止derived_merge
    • unin/union all
    • group by
    • distinct
    • 聚合函数
    • limit
    • @
• materialized
  • 物化，5.7开始in会产生，也会生成auto_key索引
  • in中使用hint QB_NAME，外层使用这个hint
    • select /+ semijoin(@sub MATERIALIZATION) / * from t_order t2 where t2.emp_no in (select /+ QB_NAME(sub) / t1.emp_no from dept_emp t1);

1.3 table

• NULL
  • 表示不使用任何表
  • 使用dual
  • extra中出现select tables optimized away,多见于count操做
• 表名或者表的别名
• <derived+ id><union + id>
  • 临时表<>里的数字是id列
  • tmp_table_size = max_heap_table_size适当调大

1.4 type

• const
  • 使用primary key或者unique key取得一条数据
• eq_ref
  • join，且知足被驱动表的链接条件unique key或者primary key
• ref
  • 对索引列作等号判断
• range
  • between in like > <
  • 和const的区别在于索引扫描范围不同
• index
  • 索引全扫描，比扫全表且order by的状况快，可是绝大部分状况下也是优化对象
  • 不能使用range，const，ref的状况下，且只查询索引列，即不回表，使用索引进行排序或者聚合即省略排序
  • 索引(a,b),select a from xxx where b = ''; 即联合索引中前导列不在where条件中，且查询列在索引中
  • 在聚合运算中group by后面的列在索引或者primary key中，且查询列也在索引中
• all
  • 全表扫描
  • 大表中查询超过一半以上的值，效果更好
  • 索引失效
    • 无索引
    • 对索引列加工
    • 索引列隐式类型转换
    • 对日期类型进行like '20xxx'
    • 单列索引，对数字列进行like '30%'

1.5 possible_keys

• 列出可能用到的索引，对优化没什么帮助
• 5.6以后开始支持auto_key
• auto_key就是临时建立索引，须要消耗一些内存和cpu，对tmp_table_size，max_heap_table_size依赖较大
• mysql列大小超过767个字节，没法生成auto_key
• convert(xxx,数据类型,字符集)

1.6 key

• sql用到的索引

1.7 key_len

• 显示sql到底使用了多少索引

1.8 ref

• 只有type是ref或者const才会出现内容，没啥用，不用管

1.9 rows

• MySQL优化器根据统计信息预估出来的值，不许

1.10 filter

• 和rows同样是预估值，非100的状况是extra有using where关键字，表示从存储引擎中拿到数据后再加工的比例
• 5.7开始该值比较准确

1.11 Extra

• Distinct
  • MySQL在join过程当中取出一行以后查询另外一个表时，碰到一行就中止，有点像exsits
  • 必须是join
  • distinct关键字
  • select列上只能含有驱动表的字段
  • 使用straight_join hint能够强制改变驱动表
• select tables optimized away
  • 查询中只有min、max的时候出现，有时候count貌似也会出现
  • 联合主键，其中任一一个字段用等值查询，查出另外一个字段的min或max，且不能包含group by
• Using filesort
  • order by, group by且没使用索引
  • 8.0 group by不会出现
• Using index
  • 只使用索引不回表就能够查到
  • 若是表对应的where条件选择率不是很好，且一行长度很长，此时课考虑建立包含对应列的索引达到减小物理io的目的
  • 延迟join必须使用using index，不然无效
• Using temporary
  • sql执行过程当中存储中间结果会使用tempoary table，但没法判断在内存仍是disk
  • order by,group by未使用索引
  • 执行计划中的select type为derived
  • show swssion status like '%tmp%'
  • max_heap_table_size和tmp_table_size(不一致时以小的为准)
• Using where
  • 通常和filtered，rows一块儿看
  • 表示从存储引擎中拿到数据再过滤
  • rows是存储引擎中拿数据的预估值，filtered是再过滤的百分比
• Using index condition
  • 必须是二级索引才有,且有索引后面部分没法使用时，回表次数很大，效果更好
  • optimizer_switch='index_condition_pushdown=on'
• Using MRR
  • optimizer_switdch='mrr_cost_based=0ff'
  • 回表以前先排序，下降随机io
• Range checked for each record
  • type为all
  • 这是优化对象，紧接着用show warnings来定位问题
• Using join buffer(Block Nested Loop)
  • optimizer_switch='block_nested_loop=on,batched_key_access=on'
  • 被驱动表没有索引且数据量较少的时候，通常这种状况也是优化对象

Ⅱ、获取运行中SQL的执行计划

desc for connection connection_id;