SQL优化是有技巧与套路的，阅读完本文你将学会

温馨提示：本文约3000字，阅读时间为5分钟。

很多人在遇到需要优化的慢查询sql时，会感到不知所措。

其实SQL优化是有技巧有套路的。看完本文，你将学会这些优化套路，让你成为别人眼中的数据库高手！

确定问题SQL

判断SQL是否有问题时，可以从两个表象来判断：

您可以使用sar命令和top命令查看当前系统状态。

您还可以使用 , 等监控工具来观察服务器状态。 （有兴趣可以看我之前的文章）

冗长的 SQL 很容易理解。如果一条 SQL 太长，可读性肯定会变差，出现问题的频率肯定会更高。进一步判断SQL问题，必须从执行计划入手，如下图：

执行计划告诉我们这个查询已经完成了全表扫描。 type=ALL，行数很大()，基本可以判断这是一条“有品味”的SQL。

获取问题SQL

不同的数据库有不同的获取方式。以下是目前主流数据库的慢查询SQL获取工具

大萌数据库SQL编写技巧

SQL 编写有以下通用技巧：

• 合理使用指数

没有索引，查询很慢；

索引越多占用空间越大，在执行增删改语句时需要动态维护索引，影响高选择性（少重复值）的性能，经常被where引用，需要建立B树索引；

一般连接列需要索引；

全文索引对于复杂的文档类型查询更有效；

索引的建立要兼顾查询和DML性能；

创建复合索引时，注意基于非前导列的查询

• 使用 UNION ALL 代替 UNION

UNION ALL的执行效率比UNION高，执行过程中需要重新加载UNION；

UNION 需要对数据进行排序

• 避免 * 拼写

优化器在执行SQL时需要将*转换成特定的列；

每次查询都要返回表oracle数据库优化方法，不能使用覆盖索引。

• 推荐使用 JOIN 字段进行索引

一般的 JOIN 字段是提前编入索引的

• 避免复杂的 SQL 语句

提高可读性；避免查询慢的概率；

可以转换成多个短查询，由业务方处理

• 避免写在 1=1 的地方

• 避免使用 rand() 编写类似的 order

RAND() 导致数据列被扫描多次

SQL 优化执行计划

要完成SQL优化，必须先阅读执行计划。执行计划会告诉你哪里效率低，哪里需要优化。我们以MYSQL为例，看看执行计划是什么。 （每个数据库的执行计划不同，需要自己去了解）sql

字段说明

身份证

每个要执行的操作都独立地标识了对象被操作的顺序。 id值越大，最先被执行。如果相同，则执行顺序是从上到下

查询中每个子句的类型

表格

被操作对象的名称，通常是表名，但也有其他格式

匹配分区信息（非分区表为NULL）

类型

连接操作的类型

可能的索引

键

优化器实际使用的索引（最重要的列） 连接类型从最好到最差是 const、ref、range、index 和 ALL。当ALL出现时oracle数据库优化方法，说明当前的SQL有“坏味道”

优化器选择的索引键的长度，以字节为单位

参考

表示该行正在操作的对象的引用对象，如果没有引用对象，则为NULL

行

查询执行扫描的元组数（对于这个值，这个值是一个估计值）

条件表中数据被过滤的元组百分比

额外的

执行计划的重要补充信息。当Using 、Using 出现在此栏中时要小心。很有可能是SQL语句需要优化

接下来，我们用一个实际的优化案例来说明SQL优化的过程和优化技巧。

优化案例

总结

本文首先让大家了解慢查询的出现，让大家可以通过一些工具识别慢查询语句；

然后告诉大家一些常见的SQL优化套路，掌握这些套路可以解决至少80%的SQL优化问题；

最后用一个例子，从分析开始，逐步完成慢查询语句的优化。查看执行计划是优化过程中最后的操作，大家一定要掌握。

如果这篇文章对你有帮助，别忘了点赞、转发和评论。下次见！

结束