标签：语句 seconds HANA 条目 add 调优 SQL 执行 select

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

标签：语句,seconds,HANA,条目,add,调优,SQL,执行,select
来源： https://www.cnblogs.com/csjoz/p/16095032.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。