vlambda博客
学习文章列表

0、序言

本文我们来谈谈项目中常用的 20 条 MySQL 优化方法，效率至少提高 3倍！

具体如下：

1、使⽤ EXPLAIN 分析 SQL 语句是否合理

使⽤ EXPLAIN 判断 SQL 语句是否合理使用索引，尽量避免 extra 列出现：Using File Sort、Using Temporary 等。

2、必须被索引

重要SQL必须被索引：update、delete 的 where 条件列、order by、group by、distinct 字段、多表 join 字段。

3、联合索引

对于联合索引来说，如果存在范围查询，比如between、>、<等条件时，会造成后面的索引字段失效。

对于联合索引来说，要遵守最左前缀法则：举列来说索引含有字段 id、name、school，可以直接用 id 字段，也可以 id、name 这样的顺序，但是 name; school 都无法使用这个索引。所以在创建联合索引的时候一定要注意索引字段顺序，常用的查询字段放在最前面。

4、强制索引

必要时可以使用 force index 来强制查询走某个索引: 有的时候MySQL优化器采取它认为合适的索引来检索 SQL 语句，但是可能它所采用的索引并不是我们想要的。这时就可以采用 forceindex 来强制优化器使用我们制定的索引。

5、日期时间类型

对于非标准的日期字段，例如字符串的日期字段，进行分区裁剪查询时会导致无法识辨，依旧走全表扫描。

尽量使用 TIMESTAMEP 类型，因为其存储空间只需要 datetime 的一半。

6、禁止使用 SELECT *

SELECT 只获取必要的字段，禁止使用 SELECT *。这样能减少不必要的消耗（CPU、IO、内存、网络带宽），增加使用覆盖索引的可能性；当表结构发生改变时，表结构变更对前端程序基本无影响。

7、避免出现某些字段

SQL 中避免出现 now()、rand()、sysdate()、current_user() 等不确定结果的函数。在语句级复制场景下，引起主从数据不一致；不确定值的函数，产生的 SQL 语句无法使用 QUERY CACHE。

8、where 子句

避免在 where 子句中对字段进行 null 值判断：对于 null 的判断会导致引擎放弃使用索引而进行全表扫描。

避免在where子句中对字段进行表达式操作：因为对字段就行了算术运算，这会造成引擎放弃使用索引。

9、like

禁止使用 % 前导查询，例如：like “%abc”，⽆法利⽤到索引。

在日常中你会发现全模糊匹配的查询，由于 MySQL 的索引是 B+ 树结构，所以当查询条件为全模糊时，例如 %AB%、%AB，索引无法使用，这时需要通过添加其他选择度高的列或者条件作为一种补充，从而加快查询速度。仅AB%形式的可以避免通配符引起索引屏蔽。

10、用 IN 代替 OR

OR 两边的字段中，如果有一个不是索引字段，而其它条件也不是索引字段，会造成该查询不走索引的情况。很多时候都会使用 IN 进行替代，或者使用 union all 或者是 union（必要的时候）的方式来代替“or”也会得到更好的效果。但 SQL 语句中 IN 包含的值不宜过多，应少于 1000 个。过多会使随机 IO 增大，影响性能。

使用 IN 是因为 MySQL 对其做了相应的优化，即将 IN 中的常量全部存储在一个数组里面，而且这个数组是排好序的。但是如果数值较多，产生的消耗比较大。

再例如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了；再或者使用连接来替换。

11、禁止使⽤负向查询

禁止使⽤负向查询，例如：not in、!=、<>、not like。

12、范围查询

在对字符串类型的索引进行大于运算时，会导致全表扫描。所以应改为区间between区间范围运算。

13、order by/group by

另外 order by/group by 的 SQL 涉及排序，尽量在索引中包含排序字段，并让排序字段的排序顺序与索引列中的顺序相同，这样可以避免排序或减少排序次数。如果排序字段没有用到索引，就尽量少排序。

14、禁止使用 order by rand()

order by rand() 会为表增加几个伪列，然后用 rand() 函数为每一行数据计算 rand() 值，最后基于该行排序，这通常都会生成磁盘上的临时表，因此效率非常低。建议先使用 rand() 函数获得随机的主键值，然后通过主键获取数据。

15、尽量用union all代替union

union 和 union all 的差异主要是前者需要将结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的CPU运算，加大资源消耗及延迟。当然，union all 的前提条件是两个结果集没有重复数据。

16、减少与数据库交互

尽量采用批量 SQL 语句，减少与数据库交互次数。

获取⼤量数据时，建议分批次获取数据，每次获取数据少于 5000 条，结果集应⼩于 1M。

17、复杂查询还是简单查询？

不要用一个SQL解决所有事情，可以分步骤做，省时、易理解、优化。且 MySQL 也十分擅长处理短而简单的 SQL，总体耗时会更短，而且也不会产生臃肿的 SQL，让人难以理解和优化。

拆分复杂 SQL 为多个 小SQL，避免⼤事务。简单的 SQL 容易使用到 MySQL 的 QUERY CACHE；减少锁表时间特别是 MyISAM；可以使用多核 CPU。

18、删除全表数据

delete from table_name;会产生大量 undo 和 redo 日志，执行时间很长，可采用 TRUNCATE TABLE tablename;

19、字符集问题

col_utf8mb4 = col_utf8 关联类型都是 varchar ，但字符集不同，无法使用索引。使用过程中要特别注意。

20、count 优化

这也是一个被面试中经常会问到的问题，对于下面的四条 SELECT 语句：

select count(*) from table … ;

select count(1) from table … ;

select count(primary key) from table … ;

select count(index key) from table …;

哪一条的执行效率最高呢？这个问题需要具体问题具体分析，不能一概而论。这里举 SELECT count(1) 这条 SQL 为例。

优化前和优化后，执行效率相差2倍。就添加了一个索引。

「优化思路」 : 是选择索引 key_len 最短的二级索引效率高，不要使用全表扫描（PK 聚族索引会全表扫描），因为索引 key_len 越短，读取页面越少，进而 IO_COST 越小。

小结

• 大量的更新/删除操作需要控制频度，例如：每秒操作2000行以下
• 使用 prepared statement 和绑定变量，可以提升性能并避免 SQL 注入
• 程序应有捕获 SQL 异常的处理机制，必要时通过 rollback 显示回滚
• 尽量少使用 distinct、order by、group by、union 等 SQL，排序需求可以放到前端（分页的就不方便交给前端排序）。
• 大事务或者长查询的需求根据业务特点拆分
• 杜绝程序中在处理事务时夹杂 RPC，会造成资源长时间不释放。有很多锁超时、并发数上涨都是由于事务中有 RPC 造成的。
• 关注软件本身的优化同时，也需要关注硬件的性能指标和优化，以及硬件的发展方向。MySQL 属于 IO 密集型的应用，对存储硬件的 IO 性能要求比较高，在高并发的场景中，建议使用 PCI-e。

「重点总结一下」：SQL 的执行过程->查询优化器的工作原理->SQL 执行计划的解读->MySQL 慢查询日志和分析->SQL 常用的优化手段->SQL 编写规范->深入实际业务对数据库访问进行优化。

参考：

• 《数据库高效优化：架构、规范与SQL技巧》
• 《拉勾教育专栏：高性能MySQL实战》