经过Explain查询和分析SQL的执行计划

 

索引类型

在 MySQL 中，主要有四种类型的索引，分别为： B-Tree 索引， Hash 索引， Fulltext 索引和 R-Tree 索引。

 

 

Explain解释

能够经过Explain查询SQL的执行计划，例子以下：

Explain

explain返回的各列的含义：

 

列	含义
table	显示查询是关于哪一个表的
type	很重要的列，显示链接使用了何种类型。从最好到最差的链接类型为const、eq_reg、ref、range、index和ALL
possible_keys	显示可能应用在这张表中的索引。若是为空，没有可能应用的索引
key	实际使用的索引。若是为NULL，则没有使用索引
key_len	使用的索引的长度。在不损失精确性的状况下，长度越短越好
ref	显示索引的哪一列被使用了
rows	MYSQL认为必须检查的用来返回请求的行数
extra	当这一列的值是Using filesort或Using temporary时，说明查询须要优化了

 

建索引的五大原则

1.最左前缀匹配原则，很是重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就中止匹配，好比a = 1 and b = 2 and c > 3 and d = 4 若是创建(a,b,c,d)顺序的索引，d是用不到索引的，若是创建(a,b,d,c)的索引则均可以用到，a,b,d的顺序能够任意调整。

 

1. 2.=和in能够乱序，好比a = 1 and b = 2 and c = 3 创建(a,b,c)索引能够任意顺序，mysql的查询优化器会帮你优化成索引能够识别的形式

 

3.尽可能选择区分度高的列做为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大咱们扫描的记录数越少，惟一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不一样，这个值也很难肯定，通常须要join的字段咱们都要求是0.1以上，即平均1条扫描10条记录

 

4.索引列不能参与计算，保持列“干净”，好比from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，缘由很简单，b+树中存的都是数据表中的字段值，但进行检索时，须要把全部元素都应用函数才能比较，显然成本太大。因此语句应该写成create_time = unix_timestamp(’2014-05-29’);

 

5.尽可能的扩展索引，不要新建索引。好比表中已经有a的索引，如今要加(a,b)的索引，那么只须要修改原来的索引便可

 

回到开始的慢查询

根据最左匹配原则，最开始的sql语句的索引应该是status、operator_id、type、operate_time的联合索引；其中status、operator_id、type的顺序能够颠倒，因此我才会说，把这个表的全部相关查询都找到，会综合分析；

好比还有以下查询

select * from task where status = 0 and type = 12 limit 10;

select count(*) from task where status = 0 ;

那么索引创建成(status,type,operator_id,operate_time)就是很是正确的，由于能够覆盖到全部状况。这个就是利用了索引的最左匹配的原则

 

 

慢查询优化基本步骤

0.先运行看看是否真的很慢，注意设置SQL_NO_CACHE

1.where条件单表查，锁定最小返回记录表。这句话的意思是把查询语句的where都应用到表中返回的记录数最小的表开始查起，单表每一个字段分别查询，看哪一个字段的区分度最高

2.explain查看执行计划，是否与1预期一致（从锁定记录较少的表开始查询）

3.order by limit 形式的sql语句让排序的表优先查

4.了解业务方使用场景

5.加索引时参照建索引的几大原则

6.观察结果，不符合预期继续从0分析