使用EXPLAIN来检查优化器的操作
EXPLAIN对于了解优化器生成的、用于处理语句的执行计划的内部信息是很有帮助的。在这一部分中，我们将解释EXPLAIN的两种用途：
· 查看采用不同的方式编写的查询是否影响了索引的使用。
· 查看向数据表添加索引对优化器生成高效率执行计划的能力的影响。
这一部分只讨论与示例相关的EXPLAIN输入字段。
前面，在"优化器是如何工作的"部分中我们得出的观点是，你编写表达式的方式将决定优化器是否能使用可用的索引。特别是上面的讨论使用了下面三个逻辑相等的WHERE子句的例子，只有第三个允许使用索引：
| WHERE TO_DAYS(date_col) - TO_DAYS(CURDATE()) < cutoff WHERE TO_DAYS(date_col) < cutoff + TO_DAYS(CURDATE()) WHERE date_col < DATE_ADD(CURDATE(), INTERVAL cutoff DAY) |
EXPLAIN允许你查看编写表达式的某种方式是否比另外的方式好一些。为了看到结果，让我们分别用这三个WHERE子句搜索成员表中过期的数据列值，把cutoff值设为30天。为了看到索引的使用和表达式编写方式之间的关系，我们首先对expiration列进行索引：
| mysql> ALTER TABLE member ADD INDEX (expiration); |
接着在每个表达式形式上使用EXPLAIN，看优化器生成了什么样的执行计划：
| mysql> EXPLAIN SELECT * FROM MEMBER -> WHERE TO_DAYS(expiration) - TO_DAYS(CURDATE()) < 30\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: MEMBER type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 102 Extra: Using where mysql> EXPLAIN SELECT * FROM MEMBER -> WHERE TO_DAYS(expiration) < 30 + TO_DAYS(CURDATE())\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: MEMBER type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 102 Extra: Using where mysql> EXPLAIN SELECT * FROM MEMBER -> WHERE expiration < DATE_ADD(CURDATE(), INTERVAL 30 DAY)\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: MEMBER type: range possible_keys: expiration key: expiration key_len: 4 ref: NULL rows: 6 Extra: Using where |
上面的结果显示，前面两个语句没有使用索引。类型（type）值表明了将如何从数据表中读取信息。ALL意味着"将检查所有的记录"。也就是说，它会执行全表扫描，没有利用索引。每个与键相关的列都是NULL也表明没有使用索引。
与此形成对比的是，第三个语句的结果显示，采用这种方式编写的WHERE子句，优化器可以使用expiration列上的索引：
· 类型（type）值表明它可以使用索引来搜索特定范围的值（小于右边表达式给定的值）。
· 可能键（possible_keys）和键（key）值显示expiration上的索引已经被考虑作为备选索引，并且它也是真正使用的索引。
· 行数（rows）值显示优化器估计自己需要检查6个数据行来处理该查询。这比前面两个执行计划的102小很多。
EXPLAIN的第二种用途是查看添加索引是否能帮助优化器更高效率地执行语句。我将使用两个未被索引的数据表。它足够显示建立索引的效率。相同的规则可以应用于涉及多表的更加复杂的联结操作。
假设我们有两个数据表t1和t2，每个有1000行，包含的值从1到1000。下面的查询查找出两个表中值相同的数据行：
| mysql> SELECT t1.i1, t2.i2 FROM t1, t2 WHERE t1.i1 = t2.i2; +------+------+ | i1 | i2 | +------+------+ | 1 | 1 | | 2 | 2 | | 3 | 3 | | 4 | 4 | | 5 | 5 | ... |
两个表都没有索引的时候，EXPLAIN产生下面的结果：
| mysql> EXPLAIN SELECT t1.i1, t2.i2 FROM t1, t2 WHERE t1.i1 = t2.i2\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t1 type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 1000 Extra: *************************** 2. row *************************** id: 1 select_type: SIMPLE table: t2 type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 1000 Extra: Using where |
类型列中的ALL表明要进行检查所有数据行的全表扫描。可能键列中的NULL表明没有找到用于提高查询速度的备选索引（键、键长度和参考列都是NULL也是因为缺少合适的索引）。Using where表明使用WHERE子句中的信息来识别合格的数据行。
这段信息告诉我们，优化器没有为提高执行查询的效率找到任何有用的信息：
· 它将对t1表进行全表扫描。
· 对于t1中的每一行，它将执行t2的全表扫描，使用WHERE子句中的信息识别出合格的行。
行数值显示了优化器估计的每个阶段查询需要检查的行数。T1的估计值是1000，因为1000可以完成全表扫描。相似地，t2的估计值也是1000，但是这个值是对于t1的每一行的。换句话说，优化器所估计的处理该查询所需要检查的数据行组合的数量是1000×1000，也就是一百万。这会造成很大的浪费，因为实际上只有1000个组合符合WHERE子句的条件。