EXPLAIN 命令可以查看SQL执行计划的信息，可以作为日常优化SQL的工具
误区
- 用 explain 时 sql 不会执行。
解答：如果查询在 FROM 中子句包括子查询，MySQL会执行子查询，将其结果放到一个临时表中，然后完成外层查询优化。这意味着开销较大的子查询或使用临时表算法的视图会给服务器带来大量工作。 - explain 很准确。
解答：explain只是一个近似结果，会有一些相关限制（具体去查书吧。。平时也用不到，explain 只是给我们一个sql执行的参考）。 - mysql5.6 版本之前 explain 只解释 select 查询。（你可以重写某些非 select 语句来利用它）
EXPALIN 列详解
id
- 编号，标识 select 所属的行，如果没有子查询或者连表查询，那么就只有1个 select id 为 1。
- 同一级连表的id 都为1，第一个子查询为2，再深层的子查询，你懂得。
- union 查询时，最后一行会显示一张匿名临时表，id 为 null
select_type
- SIMPLE： 查询不使用UNION或子查询
- PRIMARY： 复杂查询时，最外层的SELECT
- SUBQUERY：子查询中的第一个SELECT
- DERIVED：FROM子句的子查询的SELECT，MySQL会递归执行，并将结果放到一个临时表中，称为“派生表”（子查询中派生来的）
- UNION：UNION中的第二个或后面的SELECT语句
- UNION RESULT：用来从 UNION 的匿名临时表检索结果的 SELECT
- DEPENDENT：SELECT 依赖于外层的查询
- UNCACHEABLE：SELECT 的某些特性阻止结果被缓存于一个 Item_cache 中
table
对应行正在访问的表
type
访问该表时的访问类型
- all 全表扫描（例外：使用了 limit 或者 Extra 列中显示了 “Using distinct/not exists”）
- index 和全表扫描一样，只是是按照索引次序而不是行，优点是避免了排序，缺点是要承担按索引次序读取整个表的开销。如果在 Extra 中看到了 “Using index” 证明只扫描了索引的数据，开销小很多。
- range 范围扫描，显然是查询中有 between 或者 > < ，有时候是 IN 或 OR
- ref 索引访问
- eq_ref 主键或者唯一索引访问，MySQL知道最多只返回一条符合条件的记录
- const,system MYSQL对查询的某部分进行优化并将其转化为一个常量时的访问类型，比如 where 子句中放入了主键
- NULL 意味着MYSQL能在优化阶段分解查询语句，不用再访问表或者索引
possible_keys
查询可以使用哪些索引，这些索引是在优化过程早期创建的，可能对于后续优化没有用处。
key
显示MySQL实际决定使用的索引
possible_keys 揭示了哪个索引能有助于高效的行查找，key 显示的是优化采用哪一个索引可以最小化查询成本
key_len
MYSQL 在索引中使用的字节数，可以推断出具体哪一个字段使用了索引
ref
显示了 key 列记录的索引中查找值所用的列或常量
rows
MYSQL 估计为了找到所需的行所要读取的行数。
注意这里仅仅是MYSQL认为要检查的行数，并不是结果行数
filtered
MYSQL 5.1 版本之后才有
在使用 EXPLAIN EXTENDED 时会出现
将这个值与rows中的值相乘，就是MYSQL估算出它和查询计划中前一个表的关联行数
Extra
- Using index：MYSQL 将使用覆盖索引
- Using where：将在存储引擎检索行后再进行过滤，暗示：查询可受益于不同的索引
- Using temporary：MYSQL 在对查询结果排序时会使用一个临时表
- Using filesort：MYSQL 会对查询结果进行一个外部索引排序
- range checked for each record (index map: #)：MySQL 发现没有好用的索引，新的索引将在连接的每一行上重新估算。N 是显示在 possible_keys 列中索引的位图，是冗余的。