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

psy7585

已于 2022-03-08 10:38:52 修改

阅读量893

点赞数 2

CC 4.0 BY-SA版权

分类专栏：调优 HANA 文章标签：数据库 sql database

于 2022-03-07 14:38:08 首次发布

本文链接：https://blog.csdn.net/psy7585/article/details/123328715

HANA 同时被 2 个专栏收录

11 篇文章

订阅专栏

调优

8 篇文章

订阅专栏

本文详细记录了一次SQL查询优化的过程，通过分析和实验，发现在使用add_seconds函数与数据库时间进行比较时存在性能瓶颈。经过调整，将时间格式化后再进行比较，成功将执行时间从800ms至1s降低到2ms。优化后的SQL语句显著提高了查询效率，揭示了在处理时间比较时的潜在优化策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

select count (*) from ME_WIP.ACTIVITY_LOG
where DATE_TIME > add_seconds(localtoutc(now()), -1800)

这条语句的目标是查看最近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)

执行时间为2ms，比之前800ms至1s的执行时间获得大幅提高。
关于原因，目前的猜测是add_seconds所返回的时间可能是比较复杂的，格式化之后可以进行更快速的比较。

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

至此，语句优化的方式和原因都已找到。这种情况还是比较普遍的，在查询最近几天，几小时的条目时，这样潜在的调优点都会存在。