MySQL Explain详解
explain命令：可查看SQL语句的执行计划，查看SQL语句有没有使用上了索引，有没有做全表扫描，这都可以通过explain命令来查看。
具体操作是：select前添加explain来实现，它可以告诉我们你的语句性能如何。
平常查询：(MySQL逐条统计，当数据过大时，想看到结果很费时间)
利用explain命令查看SQL语句的执行计划：
概要描述：
| 1 | id | select的识别符，这是select的查询序列号。 |
| 2 | select_type： |
select的类型。SELECT类型,可以为以下任何一种：
|
| 3 | table | 输出结果集的表格。 |
| 4 | partitions |
匹配的分区。 |
| 5 | type |
对表访问方式。表示MySQL在表中找到所需行的方式，又称“访问类型”。 ”访问类型“，按照从 '' 最佳类型--最坏类型 '' 进行排序：
|
| 6 | possible_keys |
表示查询时，可能使用的索引。( MySQL能使用哪个索引在该表中找到行) |
| 7 | key |
实际使用的索引(键)，必然包含在possible_keys中。如果没有选择索引，索引是NULL。 要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。 |
| 8 | key_len |
索引的长度 ( 使用的字节数 )。如果索引是NULL，则长度为NULL。不损失精确性的情况下，长度越短越好 。 key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的。 |
| 9 | ref |
使用哪个列或常数，与索引一起被用于从表中查找索引列上的值。( 列与索引的比较，表示上述表的连接匹配条件。) 显示索引的哪一列被使用了，如果可能得话，是一个常数。 |
| 10 | rows |
MySQL认为它执行查询时必须检查的行数。( 扫描出的行数 [估算的行数 ]。) |
| 11 | filtered |
通过表条件过滤出的行数的百分比估计值。 |
| 12 | Extra |
Mysql执行情况的描述和详细说明。
|
| 总结： • EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况。 • EXPLAIN不考虑各种Cache(缓存)。 • EXPLAIN不能显示MySQL在执行查询时所作的优化工作。 • 部分统计信息是估算的，并非精确值。 • EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划。 |
||
对这些字段进一步描述：
一、id
SELECT识别符。这是SELECT的查询序列号。
我的理解是SQL执行的顺序的标识，SQL从大到小的执行。
1. id如果相同，可以认为是一组，由上至下顺序执行；
2. 在所有组中，id值越大，优先级越高，越先执行；
3. 如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行；
二、select_type
SELECT类型,可以为以下任何一种：
- SIMPLE（simple）：简单SELECT(不使用UNION或子查询)。
- PRIMARY（primary）：子查询中最外层查询，查询中若包含任何复杂的子部分，最外层的select被标记为PRIMARY。
- UNION（union）：UNION中的第二个或后面的SELECT语句。
- DEPENDENT UNION（dependent union）：UNION中的第二个或后面的SELECT语句,取决于外面的查询。
- UNION RESULT（union result）：UNION的结果，union语句中第二个select开始后面所有select。
- SUBQUERY（subquery）：子查询中的第一个SELECT，结果不依赖于外部查询。
- DEPENDENT SUBQUERY（dependent subquery）：子查询中的第一个SELECT，依赖于外部查询。
- DERIVED（derived）：派生表的SELECT (FROM子句的子查询)。
- UNCACHEABLE SUBQUERY（uncacheable subquery）：(一个子查询的结果不能被缓存，必须重新评估外链接的第一行)
显示这一步所访问数据库中 '' 表名称 ''（显示这一行的数据是关于哪张表的），有时不是真实的表名字，可能是简称。
四、partitions
四、partitions
匹配的分区。
五、type
对表访问方式。表示MySQL在表中找到所需行的方式，又称“访问类型”。
”访问类型“，按照从 '' 最佳类型--最坏类型 '' 进行排序：
”访问类型“，按照从 '' 最佳类型--最坏类型 '' 进行排序：
- NULL： MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里选取最小值可以通过单独索引查找完成。
- system：表仅有一行(=系统表)。这是const联接类型的一个特例。当MySQL对查询某部分进行优化，并转换为一个常量时，使用这些类型( system/const )访问。如将主键置于where列表中，MySQL就能将该查询转换为一个常量。当查询的表只有一行的情况下，使用system。
- const：表最多有一个匹配行，它将在查询开始时被读取。因为仅有一行，在这行的列值可被优化器剩余部分认为是常数。const表很快，因为它们只读取一次！
- eq_ref：类似ref，区别就在使用的索引是唯一索引，对于每个索引键值，表中只有一条记录匹配，简单来说，就是多表连接中使用primary key或者 unique key作为关联条件。这可能是最好的联接类型，除了const类型。
- ref：表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值。
- ref_or_null：该联接类型如同ref，但是添加了MySQL可以专门搜索包含NULL值的行。
- index_merge：该联接类型表示使用了索引合并优化方法。【不常用】
- unique_subquery：该类型替换了下面形式的IN子查询的 ref：value IN (SELECT primary_key FROM single_table WHERE some_expr) unique_subquery是一个索引查找函数，可以完全替换子查询，效率更高。【不常用】
- index_subquery：该联接类型类似于unique_subquery。可以替换IN子查询，但只适合下列形式的子查询中的非唯一索引：value IN (SELECT key_column FROM single_table WHERE some_expr)。【不常用】
- range：只检索给定范围的行，使用一个索引来选择行。
- index：该联接类型与ALL相同，Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常比ALL快，因为索引文件通常比数据文件小。
- ALL：Full Table Scan， MySQL将遍历全表以找到匹配的行。
- type显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：Null > system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
- 一般来说，得保证查询至少达到range级别，最好能达到ref。
- 我们在进行条件查询时，建议使用索引，否则将引起全表扫描，IO的开销和程序的性能都没法保证！
表示查询时，可能使用的索引。( MySQL能使用哪个索引在该表中找到行)。
指出MySQL能使用哪个索引在表中找到记录，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用（该查询可以利用的索引，如果没有任何索引显示 null）
该列完全独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys中的某些键实际上不能按生成的表次序使用。
如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查WHERE子句看是否它引用某些列或适合索引的列来提高你的查询性能。如果是这样，创造一个适当的索引并且再次用EXPLAIN检查查询
六、Key
实际使用的索引(键)，必然包含在possible_keys中。如果没有选择索引，索引是NULL。
要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
七、key_len
实际使用的索引(键)，必然包含在possible_keys中。如果没有选择索引，索引是NULL。
要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
八、key_len
索引的长度 ( 使用的字节数 )。如果索引是NULL，则长度为NULL。不损失精确性的情况下，长度越短越好 。
key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的。
九、ref
使用哪个列或常数，与索引一起被用于从表中查找索引列上的值。( 列与索引的比较，表示上述表的连接匹配条件。)
显示索引的哪一列被使用了，如果可能得话，是一个常数。
十、rows
MySQL认为它执行查询时必须检查的行数。( 扫描出的行数 [估算的行数 ]。)
十一、filtered
通过表条件过滤出的行数的百分比估计值。
十二、Extra
Mysql执行情况的描述和详细说明。
• EXPLAIN，不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况。
• EXPLAIN，不考虑各种Cache(缓存)。
• EXPLAIN，不能显示MySQL在执行查询时所作的优化工作。
• EXPLAIN，部分统计信息(rows)是估算的，并非精确值。
• EXPALIN，只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划。
- Distinct：MySQL发现第1个匹配行后，停止为当前的行组合搜索更多的行。
- Not exists：MySQL能够对查询进行LEFT JOIN优化，发现1个匹配LEFT JOIN标准的行后，不再为前面的的行组合在该表内检查更多的行。
- range checked for each record (index map: #)：MySQL没有发现好的可以使用的索引，但发现如果来自前面的表的列值已知，可能部分索引可以使用。
- Using filesort：当Query中包含 order by 操作，而且无法利用索引完成的排序操作称为“文件排序”。
- Using index：从只使用索引树中的信息而不需要进一步搜索读取实际的行来检索表中的列信息。
- Using temporary：为了解决查询，MySQL需要创建一个临时表来容纳结果集，常见于排序和分组查询，常见于 group by、order by。
- Using where：不用读取表中所有信息，仅通过索引就可以获取所需数据，这发生在对表的全部的请求列都是同一个索引的部分的时候，表示mysql服务器将在存储引擎检索行后再进行过滤。
- Using sort_union(...)、Using union(...)、Using intersect(...)：这些函数说明如何为index_merge联接类型合并索引扫描。
- Using index for group-by：类似于访问表的Using index方式，Using index for group-by表示MySQL发现了一个索引，可以用来查询GROUP BY或DISTINCT查询的所有列，而不要额外搜索硬盘访问实际的表。
- Using join buffer：改值强调了在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果。如果出现了这个值，那应该注意，根据查询的具体情况可能需要添加索引来改进能。
- Impossible where：这个值强调了where语句会导致没有符合条件的行（通过收集统计信息不可能存在结果）。
- Select tables optimized away：这个值意味着仅通过使用索引，优化器可能仅从聚合函数结果中返回一行。
- No tables used：Query语句中使用from dual 或不含任何from子句。
• EXPLAIN，不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况。
• EXPLAIN，不考虑各种Cache(缓存)。
• EXPLAIN，不能显示MySQL在执行查询时所作的优化工作。
• EXPLAIN，部分统计信息(rows)是估算的，并非精确值。
• EXPALIN，只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划。
参考文档：官方文档 + https://www.cnblogs.com/lori/p/8535037.html + https://www.cnblogs.com/tufujie/p/9413852.html