字段 | 含义 |
id | |
select_type | |
table | 表示查询涉及的表或衍生的表 |
type | 判断sql性能和优化程度重要指标 执行效率 ALL < index < range< ref < eq_ref < const < system 避免ALL和index const、ref和range，本质都是基于索引树的二分查找和多层跳转来查询，所以性能一般都是很高的，然后接下来到index这块，速度就比上面三种要差一些了，因为他是走遍历二级索引树的叶子节点的方式来执行了，那肯定比基于索引树的二分查找要慢多了，但是还是比全表扫描好一些的 |
possible_keys | Mysql在执行该sql语句的时候，可能用到的索引信息，实际不一定会用到。 |
key | mysql 在当前查询时所真正使用到的索引。possible_keys的子集 |
key_len | 查询优化器使用了索引的字节数 评估组合索引是否完全被使用 这也是我们优化sql时，评估索引的重要指标 |
ref | |
rows | 重要的字段 mysql 查询优化器根据统计信息，估算该sql返回结果集需要扫描读取的行数。 索引优化之后，扫描读取的行数越多，说明要么是索引设置不对，要么是字段传入的类型之类的问题 说明要优化空间越大 |
filtered | 返回结果的行占需要读到的行(rows列的值)的百分比，就是百分比越高，说明需要查询到数据越准确，百分比越小，说明查询到的数据量大，而结果集很少。 |
extra |
id
id | id相同 | 执行顺序由上而下 |
id不同 | 值越大越先被执行 |
select_type
select_type | SIMPLE | 表示此查询不包含 UNION 查询或子查询 |
PRIMARY | 表示此查询是最外层的查询 | |
SUBQUERY | 子查询中的第一个 SELECT | |
UNION | 表示此查询是 UNION 的第二或随后的查询 |
table
type
type | system | const的特殊情况，此时说明表中只有一行数据，直接返回。 |
const | 主键索引或唯一索引查询极快 当查询最多匹配一行时，常出现于where条件是＝的情况，一般常用于等值扫描或者唯一性索引扫描 select * from A where A.id=2 | |
eq_ref | 这种相当于多表之间关联查询 select A.* from A,B where A.id=B.userId 其中A中id对于B.userId是一一对应的 查询效率较高 | |
ref | 普通索引索引查询 此类型通常出现在多表的联合查询，使用了非唯一或非主键索引，或者匹配最左前缀规则索引的语句 select A.* from A where A.name='a' and A.sex=‘m'，name和sex构成一个组合索引 | |
range | 索引范围查询 通过索引字段范围获取表中部分数据记录。这个类型通常出现在 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN() 操作中。 | |
index | 表示全索引扫描(full index scan)， index 类型扫描所有的索引， 而不扫描数据。 index 类型通常出现在：所要查询的数据直接在索引树中就可以获取到, 而不需要扫描数据，但是索引本身数量很多，内容很大，那么执行效率很低。 不需要回源到聚簇索引 针对这种只要遍历二级索引就可以拿到数据 不需要回源到聚簇索引的访问方式 | |
ALL | 表示全表扫描 性能最差的查询之一 随着表的数量增多，执行效率越慢 |
possible_keys
key
key_len
ref
rows
filtered
extra
extra | using filesort
| 对结果集进行外部排序 不能通过索引顺序达到排序效果 | 一般有 using filesort都建议优化去掉， 因为这样的查询 cpu 资源消耗大，延时大。 |
using index | 覆盖索引扫描 | 表示查询在索引树中就可查找所需数据， 不用扫描表数据文件，往往说明性能不错。 | |
using temporary | 查询有使用临时表 | 一般出现于排序， 分组和多表 join 的情况 查询效率不高 建议优化 | |
using where | 使用where过滤 |
