SQL执行速度优化案例
本帖最后由 levycui 于 2022-9-6 18:06 编辑问题导读：
1、问题背景是什么？
2、如何进行问题分析？
3、疑问点排查及分析思路是什么？
4、有哪些优化点？
聊聊SQL优化分析过程。
技术人人都可以磨炼，但处理问题的思路和角度各有不同，希望这篇文章可以抛砖引玉。
以一个例子为切入点
一、问题背景
某业务模块反馈SQL慢，优化过程中的一些思考做个记录。
基础环境：
[*] 主机类型：阿里云
[*] 操作系统：CentOS release 7.4
[*] 存储：EMC
[*] 内存：64 G
[*] CPU型号：Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz ( 1 U * 8 core)
[*] CPU核数：16CORE
[*] 数据库环境：11.2.0.4
问题现象：
慢SQL
简单说明：
在很多应用场景中，SQL 的性能直接决定了系统的性能。此外，查询速度慢并不只是因为 SQL 语句本身，还可能是因为内存分配不佳、文件结构不合理、优化器判断异常等其他原因。
本文介绍一些通过调整 SQL 语句就能优化SQL的通用小技巧，优化 SQL 的方法不能解决所有的性能问题，但是却能处理很多因 SQL 写法不合理而产生的性能问题。
二、分析说明
[*] 通过分析定位慢SQL，分析慢SQL原因；
[*] 追溯SQL执行历史数据，分析关键指标在SQL多次执行的波动,这些关键指标可以用来做为SQL健康度参考指标。
[*] 用实际数据来验证推断，排除掉其它干扰因素，定位SQL慢的根本原因，帮助快速修复。
三、疑问点排查及分析思路
1、原SQL结构如下：
select ... from ...
where
(
(
order_creation_date>= to_date(20120208,'yyyy-mm-dd') and
order_creation_date<to_date(20120209,'yyyy-mm-dd')
)
or
(
send_date>= to_date(20120208,'yyyy-mm-dd') and send_date<to_date(20120209, 'yyyy-mm-dd')
)
)
andnvl(a.bd_id,0) = 1
业务需求我看了一下，还真不能怪开发小哥这么写。
2、SQL执行计划
从执行计划（Pstart、Pstop）中可以看出来，SQL涉及了一个分区表，扫描了所有分区。
3、如何改写？
找到了原因，下一步就是改写SQL了。
两个思路：
第一通过union all把原来的SQL拆分；
第二通过调整日期格式，使分区特性起效。
尝试改写为：
select ...
from ...
where
order_creation_date >= to_date(20120208,'yyyy-mm-dd') and
order_creation_date<to_date(20120209,'yyyy-mm-dd')
union all
select ...
from ...
where
send_date>= to_date(20120208,'yyyy-mm-dd') and
send_date<to_date(20120209,'yyyy-mm-dd') and
nvl(a.bd_id,0) = 5
改写后SQL执行计划如下：
效果还不错，缺点是扫描了两遍表，SQL性能得到了很大提升，执行时间从1个多小时缩减到1分钟。
总结
1、通过使用union all，简化条件判断。
2、规范SQL的写法：对于非标准的日期格式，Oracle在复杂逻辑判断的情况下分区特性会失效。这种情况下，会走全表扫描，结果是正确的，但是执行效率会很低。
作者：阿陶学长
来源：https://mp.weixin.qq.com/s/zvIjG1jgieE7WV2xm_kcZw
最新经典文章，欢迎关注公众号http://www.aboutyun.com/data/attachment/forum/201903/18/215536lzpn7n3u7m7u90vm.jpg
页:
[1]