19 个让 MySQL 效率提升 3 倍的 SQL 优化技巧

优化成本:

硬件>系统配置>数据库表结构>SQL及索引

优化效果:

硬件<系统配置<数据库表结构<SQL及索引

 

本文咱们就来谈谈 MySQL 中经常使用的 SQL 优化方法，利用好这些方法会让你的 MySQL 效率提升提高至少 3 倍。

一、EXPLAIN

作 MySQL 优化，咱们要善用 EXPLAIN 查看 SQL 执行计划。

•Type 列，链接类型。一个好的 SQL 语句至少要达到 Range 级别。杜绝出现 All 级别。

•Key 列，使用到的索引名。若是没有选择索引，值是 NULL。能够采起强制索引方式。

•Key_Len 列，索引长度。

•Rows 列，扫描行数。该值是个预估值。

•Extra 列，详细说明。注意，常见的不太友好的值，以下：Using filesort，Using temporary。

二、SQL 语句中 IN 包含的值不该过多

MySQL 对于 IN 作了相应的优化，即将 IN 中的常量所有存储在一个数组里面，并且这个数组是排好序的。可是若是数值较多，产生的消耗也是比较大的。

再例如：Select Id From T where Num IN (1,2,3) 对于连续的数值，能用 Between 就不要用 IN 了；再或者使用链接来替换。

三、Select 语句务必指明字段名称

Select * 会增长不少没必要要的消耗（如：CPU、IO、内存、网络带宽等）, 增长了使用覆盖索引的可能性。

当表结构发生改变时，前断也须要更新。因此要求直接在 Select 后面接上字段名。

四、当只须要一条数据的时候，使用 Limit 1

这是为了使 EXPLAIN 中 Type 列达到 Const 类型。

五、若是排序字段没有用到索引，就尽可能少排序

六、若是限制条件中其余字段没有索引，尽可能少用 OR

OR 两边的字段中，若是有一个不是索引字段，而其余条件也不是索引字段，会形成该查询不走索引的状况。不少时候使用 Union All 或者是 Union（必要的时候）的方式来代替 OR 会获得更好的效果。

七、尽可能用 Union All 代替 Union

Union 和 Union All 的差别主要是前者须要将结果集合并后再进行惟一性过滤操做，这就会涉及到排序，增长大量的 CPU 运算，加大资源消耗及延迟。固然，Union All 的前提条件是两个结果集没有重复数据。

八、不使用 ORDER BY RAND()

Select Id From `dynamic` Order By rand() Limit 1000;

上面的 SQL 语句，可优化为：

Select Id From `dynamic` T1 Join (Select rand() * (Select Max(Id) From `dynamic`) as nid) T2 on T1.Id > T2.nidlimit 1000

九、区分 IN 和 Exists、Not In 和 Not Exists

Select * From 表A Where Id IN (Select Id From 表B)

上面 SQL 语句至关于

Select * From 表A Where Exists(Select * From 表B Where 表B.Id=表A.Id)

区分 IN 和 Exists 主要是形成了驱动顺序的改变（这是性能变化的关键）。若是是 Exists，那么之外层表为驱动表，先被访问，若是是 IN，那么先执行子查询。因此 IN 适合于外表大而内表小的状况，Exists 适合于外表小而内表大的状况。

关于 Not IN 和 Not Exists，推荐使用 Not exists。这不只仅是效率问题，Not IN 可能存在逻辑问题。

如何高效的写出一个替代 not in 的 SQL 语句？

原 SQL 语句：

Select Colname … From A 表 Where A.id Not IN (Select B.id From B表)

高效的 SQL 语句：

Select Colname … From A表 Left join B表 ON Where A.id = B.id Where B.id is Null

十、使用合理的分页方式以提升分页的效率

Select Id,Name From Product Limit 866613, 20

使用上述 SQL 语句作分页的时候，可能有人会发现，随着表数据量的增长，直接使用 Limit 分页查询会愈来愈慢。

优化的方法以下：能够取前一页的最大行数的 Id ，而后根据这个最大的 Id 来限制下一页的起点。好比：此列中，上一页最大的 Id 是 866612。SQL 能够采用以下的写法：

Select Id,Name From Product Where Id> 866612 Limit 20

十一、分段查询

在一些用户选择页面中，可能一些用户选择的时间范围过大，形成查询缓慢。主要的缘由是扫描行数过多。这个时候能够经过程序，分段进行查询，循环遍历，将结果合并处理进行展现。

十二、避免在 Where 子句中对字段进行 Null 值判断

对于 Null 的判断会致使引擎放弃使用索引而进行全表扫描。

1三、不建议使用 % 前缀模糊查询

例如：Like "%name" 或者 Like "%name%" ，这种查询会致使索引失效而进行全表扫描。可是可使用 Like "name%"。那如何要查询 %name% 呢？

1四、避免在 Where 子句中对字段进行表达式操做

好比下面这个例子：

Select user_id,user_project from user_base Where age*2=36;

在上述 SQL 中对字段就好了算术运算，这会形成引擎放弃使用索引，建议改为：

Select user_id,user_project from user_base where age=36/2;

1五、避免隐式类型转换

Where 子句中出现 Column 字段的类型和传入的参数类型不一致的时候发生的类型转换，建议先肯定 Where 中的参数类型。

1六、对于联合索引来讲，要遵照最左前缀法则

举列来讲：索引含有字段 id、name、school，能够直接用 id 字段，也能够 id、name 这样的顺序，可是 name，school 都没法使用这个索引。因此在建立联合索引的时候必定要注意索引字段顺序，经常使用的查询字段放在最前面。

1七、必要时可使用 Force Index 来强制查询走某个索引

有的时候 MySQL 优化器采起它认为合适的索引来检索 SQL 语句，可是可能它所采用的索引并非咱们想要的。这时就能够采用 Force index 来强制优化器使用咱们制定的索引。

1八、注意范围查询语句

对于联合索引来讲，若是存在范围查询，好比 Between、>、< 等条件时，会形成后面的索引字段失效。

1九、关于 JOIN 优化

LEFT JOIN A 表为驱动表，INNER JOIN MySQL 会自动找出那个数据少的表做用驱动表，RIGHT JOIN B表为驱动表。

注意：

•MySQL 中没有 Full Join ，能够用如下方式来解决：

Select * from A left join B on B.name = A.namewhere B.name is nullunion allselect * from B;

•尽可能使用 Inner Join，避免 Left Join

参与联合查询的表至少为 2 张表，通常都存在大小之分。若是链接方式是 Inner Join，在没有其余过滤条件的状况下 MySQL 会自动选择小表做为驱动表。可是 Left Join 在驱动表的选择上遵循的是左边驱动右边的原则，即 Left join 左边的表名为驱动表。

•合理利用索引

被驱动表的索引字段做为 ON 的限制字段。

•利用小表去驱动大表

从原理图可以直观的看出若是可以减小驱动表的话，减小嵌套循环中的循环次数，以减小 IO 总量及 CPU 运算的次数。

•巧用 STRAIGHT_JOIN
Inner Join 是由 MySQL 选择驱动表，可是有些特殊状况须要选择另外的表做为驱动表。好比：Group By、Order By 等 「Using filesort」、「Using temporary」时。

STRAIGHT_JOIN 用来强制链接顺序，在 STRAIGHT_JOIN 左边的表名就是驱动表，右边则是被驱动表。在使用 STRAIGHT_JOIN 有个前提条件是该查询是内链接，也就是 Inner Join。其余链接不推荐使用 STRAIGHT_JOIN，不然可能形成查询结果不许确。

原文做者：https://mp.weixin.qq.com/s/XlBOTUGmAk54IU_HnsvxLQ