执行计划

//输出格式
mysql> explain select * from user_info where id = 2\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: user_info
   partitions: NULL
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 8
          ref: const
         rows: 1
     filtered: 100.00
        Extra: NULL
1 row in set, 1 warning (0.00 sec)

各列的含义如下:

id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符.

select_type: SELECT 查询的类型.

table: 查询的是哪个表

partitions: 匹配的分区

type: **访问类型​​**

possible_keys: 此次查询中可能选用的索引

key: **此次查询中确切使用到的索引.**

ref: 哪个字段或常数与 key 一起被使用

rows: **显示此查询一共扫描了多少行. 这个是一个估计值.**

filtered: **表示此查询条件所过滤的数据的百分比,如10%）表示WHERE条件过滤性差，需优化索引。**

extra: 额外的信息

select_type

SIMPLE, 表示此查询不包含 UNION 查询或子查询
PRIMARY, 表示此查询是最外层的查询
UNION, 表示此查询是 UNION 的第二或随后的查询
DEPENDENT UNION, UNION 中的第二个或后面的查询语句, 取决于外面的查询
UNION RESULT, UNION 的结果
SUBQUERY, 子查询中的第一个 SELECT
DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.

type

性能关系: ALL < index < range ~ index_merge < ref < eq_ref < const < system

system : 表中只有一条数据. 这个类型是特殊的 const 类型
const : 针对主键或唯一索引的等值查询扫描
eq_ref : join 查询前表”=”后表
ref: join 查询, 针对于非唯一或非主键索引
range: 表示使用索引范围查询 > < between
index: 全索引扫描
ALL: 全表扫描最差

possible_keys

可能使用的索引，真正使用的是key里面的

key_len

使用索引的字节数,评估组合索引是否完全使用

rows

查询的行数,不准确,可配合 show status like "%innodb_rows%";查看

Extra

using index：使用覆盖索引（查询列均在索引中，无需回表）。
using where：存储引擎返回数据后，还需在服务层过滤（WHERE条件未被索引完全覆盖）。
using temporary：需要创建临时表（常见于GROUP BY、ORDER BY未用索引）。
using filesort：需要额外排序（ORDER BY字段无索引）。
using join buffer (Block Nested Loop), using join buffer (Batched Key Access): 使用BNL或者BKA算法对join优化
Using index for group-by: 分组字段使用索引

learning_notes

学习笔记

执行计划

各列的含义如下:

select_type

type

possible_keys

key_len

rows

Extra