mysql优化之 EXPLAIN（一）

数据库优化最常用的命令就是用explain查看一下写的sql是否用到了索引:

如：

(root@localhost) [akapp]>explain select * from sc_activity where id='3a2cd2a83892d322c1332acdfe';
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
| 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Impossible WHERE noticed after reading const tables |
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+
1 row in set (0.00 sec)

(root@localhost) [akapp]>explain select * from sc_activity where id like '%3a2cd2a83892d322c1332acdfe%';
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | sc_activity | ALL | NULL | NULL | NULL | NULL | 6665 | Using where |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+

各列的含义如下：

1、id:SQL执行的顺序的标识。

sql从里向外执行，通过以上观察发现sql是按照id从大到小执行的。

2、select_type: select类型

1)、SIMPLE(不使用UNION或子查询等)
2) 、PRIMARY：最外层的select
3）、DERIVED：派生表的SELECT(FROM子句的子查询)
4）、UNION：UNION中的第二个或后面的SELECT语句
5）、UNION RESULT：UNION的结果。
6）、DEPENDENT UNION：UNION中的第二个或后面的SELECT语句，取决于外面的查询
7）、SUBQUERY：子查询中的第一个SELECT
8）、DEPENDENT SUBQUERY：子查询中的第一个SELECT，取决于外面的查询
3、table：表的名字。
有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步执行的结果)
4、type：连接操作的类型。
这列很重要,显示了连接使用了哪种类别,有无使用索引。在各种类型的关联关系当中，效率最高的是system，然后依次是const、eq_ref、ref、range、index和
All。一般来说，得保证查询至少达到range级别，最好能达到ref，否则就可能会出现性能问题。

1）、system
表只有一行：system表。这是const连接类型的特殊情况
2）、const
表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待
3）、eq_ref
在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用
4）、ref
这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少（越少越好）

5）、range
这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况
6）、index
这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）
7）、ALL
这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免。因为它要扫描整个表。你可以加入更多的索引来解决这个问题。
5、possible_key：MySQL在搜索数据记录时可以选用的各个索引名。
这里的索引名是创建索引时指定的索引昵称;如果索引没有昵称，则默认显示的是索引中第一个列的名字(在上一节举的例子中是“firstname”)。默认索引名字的含义往往不是很明显。

6、key：它显示了MySQL实际使用的索引。

key数据列是MySQL实际选用的索引，如果它为空(或NULL)，则MySQL不使用索引。

7、key_len：索引中被使用部分的长度，以字节计。

key_len的值可以告诉你在联合索引中mysql会真正使用了哪些索引。

在上例中，key_len是102，其中firstname占50字节，lastname占50字节，age占2字节（smallint存储大小为2字节）。如果MySQL只使用索引中的firstname部分，则key_len将是50。
在不损失精确性的情况下 ，key_len数据列里的值越小越好(意思是更快)。

8、ref：显示使用哪个列或常数与key一起从表中选择行。

ref数据列给出了关联关系中另一个数据表里的数据列的名字。

9、rows：MySQL所认为的它在找到正确的结果之前必须扫描的记录数。

这个数据越少越好。

10、extra：附加信息

Using index和Using where会遇到的比较多，可以重点记下，看到using filesort就是重点关注了。

1）、Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
2）、Not exists
MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了
3）、Range checked for each
没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一
4）、Using filesort
看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行  如果没有要求建议不要排序
5）Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候
6）Using temporary
看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上
7）Using where
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题
8）Impossible WHERE noticed after reading const tables | 5.7.17显示 no matching row in const table
产生“
Impossible WHERE noticed after reading const
tables”的原因是这样的，当在查询语句中存在满足如下条件的 WHERE 语句时，MySQL在 EXPLAIN
之前会优先根据这一条件查找出对应的记录，并用记录的实际值替换查询中所有使用到的该表属性。这是因为满足以下四个条件时，就会使得针对该表的查询最多只能产生一条命中结果。在该表无法命中数据的情况下就会提示“在
const table 表中没有找到匹配的行”，而这个 “const table”就指的是满足下面四个条件的表。这是 MySQL
的一个优化策略。

a、当查询条件中包含了某个表的主键或者非空的唯一索引列
b、该列的判定条件为等值条件
c、目标值的类型与该列的类型一致
d、目标值为一个确定的常量