今天查看expensive statement的时候发现了一些监控语句，执行时间大于1秒钟，语句如下：

select count (*) from ME_WIP.ACTIVITY_LOG
where DATE_TIME > add_seconds(localtoutc(now()), -1800)
1
2
这条语句的目标是查看最近30分钟生成的日志条目数。重复试了几次，执行时间在800ms到1秒钟上下。

这条语句不复杂，似乎没什么调优空间。先尝试直接执行 select count (*) from ME_WIP.ACTIVITY_LOG，结果发现只需要1ms，说明这个where语句还是有相当大的改进空间的。

再执行 select add_seconds(localtoutc(now()), -1800) from dummy
这条语句在300us左右，说明add_seconds这条计算时间的函数和localtoutc这条将时间标准化为UTC的函数都没有性能问题。
再尝试：select count (*) from ME_WIP.ACTIVITY_LOG where DATE_TIME > ‘20220307050101’
这种写法是直接固定时间的时分秒，结果发现只需要2ms。
通过以上信息，说明问题点在于使用add_seconds与条目中的时间做比较时的优化，可以尝试通过to_varchar函数将add_seconds中的时间格式进行转化。
基于以上信息，把语句改为这样后执行：

select count (*) from ME_WIP.ACTIVITY_LOG 
where DATE_TIME > 
(select to_varchar(add_seconds(localtoutc(now()), -1800),'YYYYMMDDHHMMSS') from dummy)
1
2
3
执行时间为2ms，比之前800ms至1s的执行时间获得大幅提高。
关于原因，目前的猜测是add_seconds所返回的时间可能是比较复杂的，格式化之后可以进行更快速的比较。

通过比较执行计划可以看到区别：

可以看到，第一种写法会把DATE_TIME中的条目进行LONGDATE转化后进行比较，对于数据本身的调整将会严重影响执行效率，而第二种是直接进行比较，效率自然也高得多。执行计划的对比也佐证了之前的猜测。

至此，语句优化的方式和原因都已找到。这种情况还是比较普遍的，在查询最近几天，几小时的条目时，这样潜在的调优点都会存在。
————————————————
版权声明：本文为CSDN博主「psy7585」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/psy7585/article/details/123328715