Java教程

HANA通过时间筛选条目时的SQL调优

本文主要是介绍HANA通过时间筛选条目时的SQL调优,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

今天查看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

这篇关于HANA通过时间筛选条目时的SQL调优的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!