正文
explain详解
key列
该列表示实际用到的索引。
可能会出现possible_keys列为NULL，但是key不为NULL的情况。
演示之前，先看看test1表结构：
test1表中数据：
使用的索引：
code和name字段使用了联合索引。
执行sql如下：
explain select code from test1;
结果：
这条sql预计没有使用索引，但是实际上使用了全索引扫描方式的索引。
key_len列
该列表示使用索引的长度。上面的key列可以看出有没有使用索引，key_len列则可以更进一步看出索引使用是否充分。不出意外的话，它是最重要的列。
有个关键的问题浮出水面：key_len是如何计算的？
决定key_len值的三个因素：
1.字符集
2.长度
3.是否为空
常用的字符编码占用字节数量如下：
目前我的数据库字符编码格式用的：UTF8占3个字节。
mysql常用字段占用字节数：
| 字段类型 | 占用字节数 |
| char(n) | n |
| varchar(n) | n + 2 |
| tinyint | 1 |
| smallint | 2 |
| int | 4 |
| bigint | 8 |
| date | 3 |
| timestamp | 4 |
| datetime | 8 |
此外，如果字段类型允许为空则加1个字节。
上图中的 184是怎么算的？
184 = 30 * 3 + 2 + 30 * 3 + 2
再把test1表的code字段类型改成char，并且改成允许为空：
执行sql如下：
explain select code from test1;
结果：
怎么算的？
183 = 30 * 3 + 1 + 30 * 3 + 2
还有一个问题：为什么这列表示索引使用是否充分呢，还有使用不充分的情况？
执行sql如下：
explain select code from test1 where code='001';
结果：
上图中使用了联合索引：idx_code_name，如果索引全匹配key_len应该是183，但实际上却是92，这就说明没有使用所有的索引，索引使用不充分。
ref列
该列表示索引命中的列或者常量。
执行sql如下：
explain select * from test1 t1 inner join test1 t2 on t1.id=t2.id where t1.code='001';
结果：
我们看到表t1命中的索引是const(常量)，而t2命中的索引是列sue库的t1表的id字段。
rows列
该列表示MySQL认为执行查询必须检查的行数。
对于InnoDB表，此数字是估计值，可能并不总是准确的。
filtered列
该列表示按表条件过滤的表行的估计百分比。最大值为100，这表示未过滤行。值从100减小表示过滤量增加。
rows显示了检查的估计行数，rows× filtered显示了与下表连接的行数。例如，如果 rows为1000且 filtered为50.00（50％），则与下表连接的行数为1000×50％= 500。
Extra列
该字段包含有关MySQL如何解析查询的其他信息，这列还是挺重要的，但是里面包含的值太多，就不一一介绍了，只列举几个常见的。
- Impossible WHERE
表示WHERE后面的条件一直都是false，
执行sql如下：
explain select code from test1 where 'a' = 'b';
- 结果：
- Using filesort
表示按文件排序，一般是在指定的排序和索引排序不一致的情况才会出现。
执行sql如下：
explain select code from test1 order by name desc;
结果：
这里建立的是code和name的联合索引，顺序是code在前，name在后，这里直接按name降序，跟之前联合索引的顺序不一样。
3.Using index
表示是否用了覆盖索引，说白了它表示是否所有获取的列都走了索引。
上面那个例子中其实就用到了：Using index，因为只返回一列code，它字段走了索引。
4.Using temporary
表示是否使用了临时表，一般多见于order by 和 group by语句。
执行sql如下：
explain select name from test1 group by name;
结果：
5.Using where
表示使用了where条件过滤。
6.Using join buffer
表示是否使用连接缓冲。来自较早联接的表被部分读取到联接缓冲区中，然后从缓冲区中使用它们的行来与当前表执行联接。
索引优化的过程
1.先用慢查询日志定位具体需要优化的sql
2.使用explain执行计划查看索引使用情况
3.重点关注：
key（查看有没有使用索引）
key_len（查看索引使用是否充分）
type（查看索引类型）
Extra（查看附加信息：排序、临时表、where条件为false等）
一般情况下根据这4列就能找到索引问题。
4.根据上1步找出的索引问题优化sql
5.再回到第2步
