当前位置：首页 > news >正文

SQL等价改写优化

news 2025/6/20 10:42:18

or 与 union all的优化
在SQL开发中，我们经常会遇到这样的情况：需要组合多个相似但略有不同的查询结果。大多数开发者本能地使用UNION/UNION ALL来解决，这种方式直观易懂，但在特定场景下却隐藏着巨大的性能浪费。

本案例将从执行原理层面，深入剖析为什么在某些情况下，OR条件能比UNION ALL带来质的性能提升。

第一部分：查询dcc_sys_log表中cause条件为"对端被关闭%"的记录
select peer_id 对端标识,
null 源域名,
null 目标域名,
alert_type 告警类型,
log_time 告警时间,
cause 告警内容,
deal_log 处理状态,
deal_staff 处理人,
deal_time 处理时间,
remark 备注
from dcc_sys_log
where action = ‘disconnect’
and cause like ‘对端被关闭%’
and deal_log = ‘deal_log’
and alert_type = ‘alert_type’
and log_time >= TO_DATE(‘2024-08-02’, ‘YYYY-MM-DD’)
and log_time < TO_DATE(‘2024-08-03’, ‘YYYY-MM-DD’) + 1
– 第二部分：查询dcc_ne_log表中result=0的记录
union
(select peer_id 对端标识,
origin_host 源域名,
dest_host 目标域名,
alert_type 告警类型,
log_time 告警时间,
cause 告警内容,
deal_log 处理状态,
deal_staff 处理人,
deal_time 处理时间,
remark 备注
from dcc_ne_log
where result = 0
and cause like ‘parser失败%’
and deal_log = ‘deal_log’
and alert_type = ‘alert_type’
and log_time >= TO_DATE(‘2024-08-02’, ‘YYYY-MM-DD’)
and log_time < TO_DATE(‘2024-08-03’, ‘YYYY-MM-DD’) + 1)
union
– 第三部分：查询dcc_ne_log表中result_code特定值的记录
(select peer_id 对端标识,
origin_host 源域名,
dest_host 目标域名,
alert_type 告警类型,
log_time 告警时间,
cause 告警内容,
deal_log 处理状态,
deal_staff 处理人,
deal_time 处理时间,
remark 备注
from dcc_ne_log
where result_code = ‘DIAMETER_UNABLE_TO_DELIVER’
and svcctx_id like ‘SR-Timeout%’
and deal_log = ‘deal_log’
and alert_type = ‘alert_type’
and log_time >= TO_DATE(‘2024-08-02’, ‘YYYY-MM-DD’)
and log_time < TO_DATE(‘2024-08-03’, ‘YYYY-MM-DD’) + 1)
union
– 第四部分：查询dcc_sys_log表中cause条件为"接收消息异常%"的记录
(select peer_id 对端标识,
null 源域名,
null 目标域名,
alert_type 告警类型,
log_time 告警时间,
cause 告警内容,
deal_log 处理状态,
deal_staff 处理人,
deal_time 处理时间,
remark 备注
from dcc_sys_log
where action = ‘disconnect’
and cause like ‘接收消息异常%’
and deal_log = ‘deal_log’
and alert_type = ‘alert_type’
and log_time >= TO_DATE(‘2024-08-02’, ‘YYYY-MM-DD’)
and log_time < TO_DATE(‘2024-08-03’, ‘YYYY-MM-DD’) + 1)

分析问题
这段SQL的执行过程实际上是：

四次独立的表扫描：

两次对dcc_sys_log表的完整扫描
两次对dcc_ne_log表的完整扫描

四次过滤操作：

每个子查询各自应用WHERE条件进行过滤

三次合并操作：

对四个结果集执行UNION操作，包含排序和去重

四次重复的公共条件判断：

deal_log = ‘deal_log’
alert_type = ‘alert_type’
相同的时间范围条件

这种写法的效率问题主要体现在：相同表被多次无谓地扫描，公共条件被重复判断，导致CPU和I/O资源的严重浪费。

精准优化：拆解和合并
经过分析，我们可以看到明显的优化空间：

相同表的查询合并：

第一部分和第四部分都查询dcc_sys_log表
第二部分和第三部分都查询dcc_ne_log表

差异点隔离：

dcc_sys_log表的差异仅在于cause条件
dcc_ne_log表的差异在于result/result_code/svcctx_id条件组合

将这些相似查询通过OR条件合并后的SQL：

– 第一部分：合并对dcc_sys_log的两次查询
select peer_id 对端标识,
null 源域名,
null 目标域名,
alert_type 告警类型,
log_time 告警时间,
cause 告警内容,
deal_log 处理状态,
deal_staff 处理人,
deal_time 处理时间,
remark 备注
from dcc_sys_log
where action = ‘disconnect’
and (cause like ‘对端被关闭%’ or cause like ‘接收消息异常%’)
and deal_log = ‘deal_log’
and alert_type = ‘alert_type’
and log_time >= TO_DATE(‘2024-08-02’, ‘YYYY-MM-DD’)
and log_time < TO_DATE(‘2024-08-03’, ‘YYYY-MM-DD’) + 1
union
– 第二部分：合并对dcc_ne_log的两次查询
select peer_id 对端标识,
origin_host 源域名,
dest_host 目标域名,
alert_type 告警类型,
log_time 告警时间,
cause 告警内容,
deal_log 处理状态,
deal_staff 处理人,
deal_time 处理时间,
remark 备注
from dcc_ne_log
where ((result = 0 and cause like ‘parser失败%’) – 第一个差异条件组合
or (result_code = ‘DIAMETER_UNABLE_TO_DELIVER’ and svcctx_id like ‘SR-Timeout%’)) – 第二个差异条件组合
and deal_log = ‘deal_log’
and alert_type = ‘alert_type’
and log_time >= TO_DATE(‘2024-08-02’, ‘YYYY-MM-DD’)
and log_time < TO_DATE(‘2024-08-03’, ‘YYYY-MM-DD’) + 1
实际应用中的注意事项

括号使用：在复杂OR条件组合中，正确使用括号确保逻辑正确

where ((result = 0 and cause like ‘parser失败%’)
or (result_code = ‘DIAMETER_UNABLE_TO_DELIVER’ and svcctx_id like ‘SR-Timeout%’))
and deal_log = ‘deal_log’
2. OR vs AND优先级：OR条件比AND优先级低，必要时使用括号明确优先级