【黑魔法】绝对是压箱底的法宝

微信公众号：猿人谷转发或在文末点赞！你们的支持，是我坚持的最大动力。

今天给大家介绍两个黑魔法，这都是压箱底的法宝。大家在使用时，一定要弄清他们的适用场景及用法，用好了，就是一把开天斧，用不好那就是画蛇添足。

1.Covering Indexes

可能有小伙伴会问，Covering Indexes到底是什么神器呢？它又是如何来提升性能的呢？接下来我会用最通俗易懂的语言来进行介绍，毕竟不是每个程序猿都要像DBA那样深刻理解数据库，知道如何用以及如何用好神器才是最关键的。

An index that contains all required information to resolve the query is known 
as a “Covering Index” – it completely covers the query.
Covering Index includes all the columns, the query refers to in the SELECT, JOIN,
and WHERE clauses.

接下来我们通过一个非常简单的sql来进行分析：

SELECT column1, column2 FROM tablename WHERE column3=xxx;

你能想象将sql的执行时间从1.8秒，降到1.2秒，继续压榨到0.5，0.2…..，酣畅淋漓，怎一个爽字了得。就跟排兵布阵一样，打胜仗固然重要，但得想出成本最低效果最好的阵法，定会收获满满的成就感。请注意，整个过程出现了两次查询，一次是查询索引，另一次查询结果的所需字段。

alter table table_name add index index_column3 (column3，column1，column2) ;

这样就可以直接通过索引就能查询出符合条件的数据，而不必像上面那样先去查索引，然后再去查数据的两个过程。光说不练那是假把式！小伙伴们可以用explain去试试上面的两种情况，如果执行复合索引后的情况，你会发现Extra里出现Using index。

2.STRAIGHT_JOIN

接下来给大家下另一个性能提升神器-STRAIGHT_JOIN，在数据量大的联表查询中灵活运用的话，能大大缩短查询时间。

STRAIGHT_JOIN is similar to JOIN, except that the left table is always read before the right table. 
This can be used for those (few) cases for which the join optimizer puts the tables in the wrong order.

意思就是说STRAIGHT_JOIN功能同join类似，但能让左边的表来驱动右边的表，能改表优化器对于联表查询的执行顺序。

select t1.*
from Table1 t1
inner join Table2 t2
on t1.CommonID = t2.CommonID
where t1.FilterID = 1

以上sql大数据量下执行需要30s，是不是很奇怪？明明Table1表的FilterID字段建了索引啊，Table1和Table2的CommonID也建了索引啊。通过explain来分析，你会发现执行计划中表的执行顺序是Table2->Table1。这个时候要略微介绍下驱动表的概念，mysql中指定了连接条件时，满足查询条件的记录行数少的表为驱动表；如未指定查询条件，则扫描行数少的为驱动表。mysql优化器就是这么粗暴以小表驱动大表的方式来决定执行顺序的。

select t1.*
from Table1 t1
where t1.FilterID = 1

或

select t1.*
from Table1 t1
inner join Table2 t2
on t1.CommonID = t2.CommonID

这个时候STRAIGHT_JOIN就派上用场，我们对sql进行改造如下：

select t1.*
from Table1 t1
STRAIGHT_JOIN  Table2 t2
on t1.CommonID = t2.CommonID
where t1.FilterID = 1

用explain进行分析，发现执行顺序为Table1->Table2，这时就由Table1来作为驱动表了，Table1中相应的索引也就用上了，执行时间竟然低于1s了。

分析到这里，必须要重点说下：

√STRAIGHT_JOIN只适用于inner join，并不使用与left join，right join。（因为left join，right join已经代表指定了表的执行顺序）

√尽可能让优化器去判断，因为大部分情况下mysql优化器是比人要聪明的。使用STRAIGHT_JOIN一定要慎重，因为啊部分情况下认为指定的执行顺序并不一定会比优化引擎要靠谱。

上面两个sql的优化技巧在数据量大的表中，起到的作用非常明显，但大家在使用的时候一定要灵活运用，使用不当就是画蛇添足，切记，切记，切记！

文章都看完了，点个赞再走吧