(5) possible_keys：possible_keys字段是指 mysql在搜索表记录时可能使用哪个索引。注意，这个字段完全独立于explain 显示的表顺序。这就意味着 possible_keys里面所包含的索引可能在实际的使用中没用到。如果这个字段的值是null，就表示没有索引被用到。这种情况下，就可以检查 where子句中哪些字段那些字段适合增加索引以提高查询的性能。就这样，创建一下索引，然后再用explain 检查一下。想看表都有什么索引，可以通过 show index from tbl_name来看。

(6) key：key字段显示了mysql实际上要用的索引。当没有任何索引被用到的时候，这个字段的值就是null。想要让mysql强行使用或者忽略在 possible_keys字段中的索引列表，可以在查询语句中使用关键字force index,use index,或 ignore index。如果是 myisam 和 bdb 类型表，可以使用 analyzetable 来帮助分析使用使用哪个索引更好。如果是 myisam类型表，运行命令 myisamchk --analyze也是一样的效果。

(7) key_len：key_len 字段显示了mysql使用索引的长度。当 key 字段的值为 null时，索引的长度就是 null。注意，key_len的值可以告诉你在联合索引中mysql会真正使用了哪些索引。

(8) ref：ref 字段显示了哪些字段或者常量被用来和 key配合从表中查询记录出来。

(9) rows：rows 字段显示了mysql认为在查询中应该检索的记录数。

(10) extra：本字段显示了查询中mysql的附加信息。以下是这个字段的几个不同值的解释：

A. distinct:mysql当找到当前记录的匹配联合结果的第一条记录之后，就不再搜索其他记录了。

B. not exists:mysql在查询时做一个 left join优化时，当它在当前表中找到了和前一条记录符合 left join条件后，就不再搜索更多的记录了。下面是一个这种类型的查询例子：select * from t1left join t2 on t1.id=t2.id where t2.id is null; 假使 t2.id 定义为 not null。这种情况下，mysql将会扫描表 t1并且用 t1.id 的值在 t2 中查找记录。当在 t2中找到一条匹配的记录时，这就意味着 t2.id 肯定不会都是null，就不会再在 t2 中查找相同 id值的其他记录了。也可以这么说，对于 t1 中的每个记录，mysql只需要在t2 中做一次查找，而不管在 t2 中实际有多少匹配的记录。

C. range checked for each record(index map: #) mysql没找到合适的可用的索引。取代的办法是，对于前一个表的每一个行连接，它会做一个检验以决定该使用哪个索引（如果有的话），并且使用这个索引来从表里取得记录。这个过程不会很快，但总比没有任何索引时做表连接来得快。

D. using filesort: mysql需要额外的做一遍从而以排好的顺序取得记录。排序程序根据连接的类型遍历所有的记录，并且将所有符合 where条件的记录的要排序的键和指向记录的指针存储起来。这些键已经排完序了，对应的记录也会按照排好的顺序取出来。

E. using index字段的信息直接从索引树中的信息取得，而不再去扫描实际的记录。这种策略用于查询时的字段是一个独立索引的一部分。

F. using temporary: mysql需要创建临时表存储结果以完成查询。这种情况通常发生在查询时包含了groupby和 order by 子句，它以不同的方式列出了各个字段。

G. using where，where子句将用来限制哪些记录匹配了下一个表或者发送给客户端。除非你特别地想要取得或者检查表种的所有记录，否则的话当查询的extra 字段值不是 usingwhere 并且表连接类型是 all 或 index时可能表示有问题。

H. 如果你想要让查询尽可能的快，那么就应该注意 extra 字段的值为using filesort 和 using temporary 的情况。

使用explain优化SQL实例

通过 explain 的结果中 rows字段的值的乘积大概地知道本次连接表现如何。它可以粗略地告诉我们mysql在查询过程中会查询多少条记录。如果是使用系统变量 max_join_size 来取得查询结果，这个乘积还可以用来确定会执行哪些多表select 语句。下面的例子展示了如何通过 explain提供的信息来较大程度地优化多表联合查询的性能。假设有下面的 select 语句，正打算用 explain 来检测：

[sql] 
explain select tt.ticketnumber, tt.timein, tt.projectreference,tt.estimatedshipdate, tt.actualshipdate, tt.clientid,tt.servicecodes, tt.repetitiveid, tt.currentprocess,tt.currentdppers tt.recordvolume, tt.dpprinted, et.country,et_1.country, do.custname   
[sql] 
from tt, et, et as et_1, do   
[sql] 
where tt.submittime is null and tt.actualpc = et.employid and tt.assignedpc = et_1.employid and tt.clientid = do.custnmbr;   

从from子句可以看出select子句要进行多表查询，要从三个表tt, et 和do三个表中进行联合查询，看起来是四个表

重点看where比较子句：tt.submittime is null and tt.actualpc = et.employid and tt.assignedpc =et_1.employid and tt.clientid = do.custnmbr;

假设要比较的字段定义为表tt中的actualpc，actualpc 和clientid 均为 char(10)类型，et的employid 为char(15) 类型，do 的custnmbr为char(15) 类型，

这三个表的索引为tt有上那个索引：actualpc（值分布不均匀），assignedpc和clientid， et的为主键索引：employid (primary key)，do表的也为主键索引custnmbr (primary key)

第一步，在任何优化措施未采取之前，经过 explain分析的结果显示如下：