关于Explain

Posted onlywjy

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于Explain相关的知识,希望对你有一定的参考价值。

最近在对sql进行性能优化因此对explain相关的知识进行一个简单的整理归纳。

EXPLAIN:

  为SELECT语句中使用到的每个表返回一条 SELECT 执行的详细信息;按照mysql在处理语句时读取它们的顺序列出这些表。

命令输出格式

id = 1    
select_type = SIMPLE    
table = clazz    
partitions =     
type = const    
possible_keys = PRIMARY    
key = PRIMARY    
key_len = 98    
ref = const    
rows = 1    
filtered = 100.00    
Extra =     
  • id:SELECT 标识符,SQL执行的顺序的标识,SQL从大到小的执行
    • id相同时,执行顺序由上至下
    • 如果是子查询,id的序号会递增,id值越大优先级越高,越先被执行
    • 如果id相同,则认为是一组,从上往下顺序执行;在所有组中,id值越大,优先级越高,越先执行
  • select_type
    • SIMPLE:简单的SELECT未使用 UNION 查询或子查询
    • PRIMARY:表示此查询是最外层的SELECT(如两表做UNION或者存在子查询的外层的表操作为PRIMARY,内层的操作为UNION)
    • UNION:表示UNION操作中,查询中处于内层的SELECT(内层的SELECT语句与外层的SELECT语句没有依赖关系)
    • DEPENDENT UNION:表示UNION操作中,查询中处于内层的SELECT(内层的SELECT语句与外层的SELECT语句有依赖关系)
    • UNION RESULT:UNION 操作的结果,id值通常为null
    • SUBQUERY:子查询中的第一个 SELECT
    • DEPENDENT SUBQUERY:子查询中的第一个 SELECT, 子查询依赖于外层的查询结果
    • ERIVED:被驱动的SELECT子查询(子查询位于from子句)
    • MATERIALZED:物化子查询(对此查询会创建临时表,将制定表物化为临时表)
    • UNCACHEABLE SUBQUERY:无法缓存子查询的结果,每次都需要计算
    • UNCACHEABLE UNION:UNION操作红内层的子查询无法被物化(类似于UNCACHABLESUBQUERY)
  • table:表示查询涉及的表或衍生表技术图片
  • type
    • ALL:全表扫描,mysql将便利全表数据直至找到匹配的行
    • index:全索引扫描,遍历索引树
    • range:  范围扫描,基于索引做扫描,如between,in,>=,like等操作
    • ref: 表示上述的连接匹配条件,即哪些列或产量被用于查找索引列上的值
    • eq_ref: 类似ref区别在于索引是唯一索引,对于每个索引键值表中只有一条记录匹配,即多表连接中使用primary key或者unique key作为关联条件
    • const: 只读取一次就能获得数据(如:主键)
    • system: const的特例,查询的表中只有一行的情况下,使用system
    • null: mysql在优化的过程中分解语句,执行时甚至不用访问表或索引,例如从一个索引列里面选取最小值可以通过单独索引查找完成  
  • partitions:记录与查询匹配的分区
  • possible_keys:表示在查询时, 能够使用到的索引具体使用了哪些索引, 由 key 字段决定.
  • key:表示查询时所真正使用到的索引.
  • key_len:表示查询优化器使用了索引的字节数. 这个字段可以评估组合索引是否完全被使用, 或只有最左部分字段被使用到
    • 字符串
      • char(n): n 字节长度
      • varchar(n): 如果是 utf8 编码, 则是 3 n + 2字节; 如果是 utf8mb4 编码, 则是 4 n + 2 字节
    • 数值类型  
      • TINYINT: 1字节
      • SMALLINT: 2字节
      • MEDIUMINT: 3字节
      • INT: 4字节
      • BIGINT: 8字节
    • 时间类型 
      • DATE: 3字节
      • TIMESTAMP: 4字节
      • DATETIME: 8字节
    • 字段属性: NULL 属性 占用一个字节. 如果一个字段是 NOT NULL 的, 则没有此属性.
  • ref:被用来标识那些用来进行索引比较的列或者常量
  • rows:估算 SQL 要查找到结果集需要扫描读取的数据行数
  • filterd:给出了一个百分比的值,这个百分比值和 rows 列的值一起使用
  • Extra: 附加与操作相关联的信息
    • Using filesort
      • 表示 MySQL 需额外的排序操作, 不能通过索引顺序达到排序效果,查询 CPU 资源消耗大建议优化去掉,
    • Using index
      • "覆盖索引扫描", 表示查询在索引树中就可查找所需数据, 不用扫描表数据文件, 往往说明性能不错
    • Using where
      • where条件用于筛选出与下一个表匹配的数据然后返回给客户端
    • Using temporary
      • 查询有使用临时表, 一般出现于排序, 分组和多表 join 的情况, 查询效率不高 建议优化.
    • Impossible where
      • WHERE条件过滤没有效果,或者是始终选不出任何列(理解为最终是全表扫描)
    • Impossible HAVING
      • HAVING条件过滤没有效果,或者是始终选不出任何列(理解为返回已有查询的结果集)
    • unique row not found
      • 表中找不到满足条件唯一索引或主键索引的列
    • Using sort_union(...),Using union(...),Using intersect(...)
      • 表示在index_merge的连接类型中索引合并是怎么样完成的,及使用了怎样特别的算法

以上是关于关于Explain的主要内容,如果未能解决你的问题,请参考以下文章

1025关于explain的补充1

关于mysql的explain慢查询详解

关于mysql的explain慢查询详解

关于片段生命周期

关于js----------------分享前端开发常用代码片段

MySQL高级篇——EXPLAIN分析查询语句