最近在对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在优化的过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里面选取最小值可以通过单独索引查找完成
- possible_keys:表示在查询时, 能够使用到的索引具体使用了哪些索引, 由 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的连接类型中索引合并是怎么样完成的,及使用了怎样特别的算法
如对本文有疑问，
点击进行留言回复！！
我要评论
网友评论