EXPLAIN

EXPLAIN 语句来帮助我们查看某个查询语句的具体执行计划。

id

包含子查询的select语句中，每个select都有一个id。

id为NULL 表明这个临时表是为了合并两个查询的结果集而创建的

在连接查询的执行计划中，每个表都会对应一条记录，这些记录的id列的值是相同的，出 现在前边的表表示驱动表，出现在后边的表表示被驱动表。

type

某个表的执行查询时的单表访问方法。

如：

• const：根据主键或者唯一二级索引列与常数进行等值匹配

• ref：当通过普通的二级索引列与常量进行等值匹配时来查询某个表，那么对该表的访问方法就可能是ref。

• range：如果使用索引获取某些范围区间的记录，那么就可能使用到range访问方法。

• ALL：全表扫描。

possible_keys、key

possible_keys 列表示在某个查询语句中，对某个表执行单表查询时可能用 到的索引有哪些，key列表示实际用到的索引有哪些。

rows

如果查询优化器决定使用全表扫描的方式对某个表执行查询时，执行计划的rows列就代表预计需要扫描的行 数，如果使用索引来执行查询时，执行计划的rows列就代表预计扫描的索引记录行数。

Extra

额外信息。

如：

Using index：当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用索引覆盖的情况下，在 Extra 列将会提示该额外信息。

Using index condition：有些搜索条件中虽然出现了索引列，但却不能使用到索引，

Using where：当我们使用全表扫描来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件时

optimizer trace

完整的使用optimizer trace 功能的步骤总结如下：

 # 1. 打开optimizer trace功能 (默认情况下它是关闭的): 
SET optimizer_trace="enabled=on"; 
# 2. 这里输入你自己的查询语句 
SELECT ...; 
# 3. 从OPTIMIZER_TRACE表中查看上一个查询的优化过程 
SELECT * FROM information_schema.OPTIMIZER_TRACE; 
# 4. 可能你还要观察其他语句执行的优化过程，重复上边的第2、3步
 ... 
# 5. 当你停止查看语句的优化过程时，把optimizer trace功能关闭 
SET optimizer_trace="enabled=off";

这个 OPTIMIZER_TRACE 表有4个 列，分别是：

• QUERY ：表示我们的查询语句。

• TRACE ：表示优化过程的JSON格式文本。

• MISSING_BYTES_BEYOND_MAX_MEM_SIZE ：由于优化过程可能会输出很多，如果超过某个限制时，多余的文本 将不会被显示，这个字段展示了被忽略的文本字节数。

• INSUFFICIENT_PRIVILEGES ：表示是否没有权限查看优化过程，默认值是0，只有某些特殊情况下才会是 1 ，我们暂时不关心这个字段的值。