sql优化神器 explain

查看执行计划:EXPLAIN SELECT * FROM xxx WHERE id=12

|id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra|

id：查询序列号
select_type：普通查询、联合、子查询
table：查询表
type：显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALLtype一般来说，得`保证查询至少达到range级别，最好能达到ref。
就type进行详细的介绍：all : 即全表扫描
index : 按索引次序扫描，就type进行详细的介绍：
System,const,eq_ref,ref,range,index,all
all : 即全表扫描

index : 按索引次序扫描，先读索引，再读实际的行，结果还是全表扫描，主要优点是避免了排序。因为索引是排好的。
range:以范围的形式扫描。
explain select * from a where a_id > 1\G
ref:非唯一索引访问(只有普通索引)
create table a(a_id int not null, key(a_id));
insert into a values(1),(2),(3),(4),(5),(6),(7),(8),(9),(10);
mysql> explain select * from a where a_id=1\G
eq_ref:使用唯一索引查找(主键或唯一索引)
const:常量查询
当出现using index时，表示sql使用覆盖索引，性能较好，而当出现using filesort、using temporary、using where时，查询需要优化。
先读索引，再读实际的行，结果还是全表扫描，主要优点是避免了排序。因为索引是排好的。
range:以范围的形式扫描。
explain select * from a where a_id > 1\G
ref:非唯一索引访问(只有普通索引)
create table a(a_id int not null, key(a_id));
insert into a values(1),(2),(3),(4),(5),(6),(7),(8),(9),(10);
mysql> explain select * from a where a_id=1\G
eq_ref:使用唯一索引查找(主键或唯一索引)
const:常量查询
当出现using index时，表示sql使用覆盖索引，性能较好，而当出现using filesort、using temporary、using where时，查询需要优化。`

possible_keys：指出MySQL能使用哪个索引在该表中找到行。如果是空的，没有相关的索引。这时要提高性能，可通过检验WHERE子句，看是否引用某些字段，或者检查字段不是适合索引。
key：显示MySQL实际决定使用的键。如果没有索引被选择，键是NULL。key_len：显示MySQL决定使用的键长度。如果键是NULL，长度就是NULL。文档提示特别注意这个值可以得出一个多重主键里mysql实际使用了哪一部分。ref：显示哪个字段或常数与key一起被使用。rows：这个数表示mysql要遍历多少数据才能找到，在innodb上是不准确的。Extra：如果是Only index，这意味着信息只用索引树中的信息检索出的，这比扫描整个表要快。如果是where used，就是使用上了where限制。如果是impossible where 表示用不着where，一般就是没查出来啥。如果此信息显示Using filesort或者Using temporary的话会很吃力，WHERE和ORDER BY的索引经常无法兼顾，如果按照WHERE来确定索引，那么在ORDER BY时，就必然会引起Using filesort，这就要看是先过滤再排序划算，还是先排序再过滤划算。

重点注意:type,key,extra

索引优化三大原则：

1、最左前缀原则；

2、不冗余原则；

3、最大选择性原则。

基于之前的三大原则，大家还可以看看什么地方可以进一步优化。
能用单索引，不用联合索引；能用窄索引，不用宽索引；能复用索引，不新建索引。
不要小看这个索引，差的索引不但不能提升sql性能，反而增加DB,磁盘I/O的开销，甚至导致大量锁的问题。