explain查看执行计划

type

ALL

全表扫描

Index

索引表全表扫描，其性能不会比ALL高，因为它实际还是会回表查数据的，每在索引表中查一条索引就回主表查一次数据
除非是排序情况，因为聚集索引是按照主键排序的，而其他索引是根据索引的列排序的。如果是需要列排序，Index才会比ALL快，因为免除了一次排序。
什么时候会出现index情况？一般需要查询的列都处在索引中时，会走index，因为要查的数据都在索引中，因此直接在索引中查即可，不需要回主表查，但如果不存在排序的话，效率跟ALL没区别

range

这种情况会计算出一个索引范围，只查询这个范围内的索引（只会在这个范围内回表查）。
范围计算的规则是基于最左匹配的，遇到不在索引中的，或者范围查询时，范围限定就此终结，如果后面的列仍在索引中，其会起到过滤的作用，虽然不会减小索引的范围，但能够阻止多余的回表查询。
举个例子：

index(a,b,c)
where a = 1 and b > 3 and c=4

以上只有a，b能缩小索引范围，而c虽然不能缩小要查询的索引的范围，但当扫描索引c!=4的记录时将不会进行回表查数据，而回表是主要性能瓶颈，因此c同样很重要

Ref

查找条件使用索引但使用的不是唯一索引或主键索引，因此可能会存在多个记录。但范围很小，其与range的区别如下：

range：

where a = 1 and b > 3

对应的索引为a = 1 and b = 4，a = 1 and b = 5，a = 1 and b = 6……， 其中每条都可能对应着多个主键记录

ref：

where a = 1 and b = 3

对应的索引为a = 1 and b = 3，其对应的主键记录可能有多条
对于非唯一索引，其存储结构为跟着多条主键所在页号

Ref-eq

在表连接查询时，根据主键或者唯一二级索引查询被驱动表时，被驱动表的访问方式为ref-eq

const

最好的情况，如果where后存在主键或者唯一索引的等值查询，将能够定位到这条唯一的记录，只会查一次

where id = 1

额外

对于where查询，不需要根据索引中列顺序来，因为优化器会自动优化顺序，使用索引

where a=1 and b=1
where b=1 and a=1

以上两个没区别，因此对于索引(a,b)无论哪个语句都能使用索引
因此，where中的列的顺序是无关的，因为无论怎么换都不影响，我们进行最左匹配原则的时候的最左匹配看的是索引中的列的顺序。

where a = 1 and b > 10
where b > 10 and a = 1

对于索引(a,b)以上都能使用到a和b，但对于索引(b,a)，则只能使用到索引b，因为b是范围查询

key

使用的索引

key_len

索引长度

rows

扫描的行数

Extra

profile查看各阶段执行时间

set profiling=1;                  //打开分析

run your sql1;

run your sql2;

show profiles;                    //查看sql1,sql2的语句分析

show profile for query 1;        //查看sql1的具体分析

show profile ALL for query 1;    //查看sql1相关的所有分析【主要看i/o与cpu,下边分析中有各项意义介绍】

set profiling=0;                  //关闭分析

Optimizer trace分析查询计划

#打开设置
SET optimizer_trace='enabled=on';  
#最大内存根据实际情况而定， 可以不设置
SET OPTIMIZER_TRACE_MAX_MEM_SIZE=1000000;
SET END_MARKERS_IN_JSON=ON;
SET optimizer_trace_limit = 1;
SHOW VARIABLES LIKE '%optimizer_trace%';

#执行所需sql后，查看该表信息即可看到详细的执行过程
SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`;

打开慢日志

set global slow_query_log=on
设置连接慢日志时间为0来记录所有语句：
set long_query_time=0