人生倒计时
- 今日已经过去小时
- 这周已经过去天
- 本月已经过去天
- 今年已经过去个月
温馨提示：本文约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优化问题；
最后用一个例子，从分析开始，逐步完成慢查询语句的优化。查看执行计划是优化过程中最后的操作，大家一定要掌握。
如果这篇文章对你有帮助，别忘了点赞、转发和评论。下次见！
结束
