在哪里执行？SSRS或SQL

Question

当我创建一个SSRS报告,我一直有一个关于"如何创建具有最少的生成时间可能报告"的窘境.

通常,生成时间(或执行时间)分为两个主要部分:

1. SQL查询.
2. 报告组件(表达式,组等).

如您所知,SSRS中正在执行的一些事情可以在SQL查询中完成,反之亦然.

例如:

• 我可以Group by在SQL中使用子句,但在使用带有组定义的表时也可以这样做.
• 我可以使用Casting它来比较SQL中的两个值,也可以直接在表达式中.

还有很多...

我的问题是:

A.哪个部分(SQL查询或SSRS)花费更多时间(假设可以在SSRS和SQL中进行任务)？

B.如果有任何指导原则,我应该根据哪个执行特定情况做出决定？

Answer 1

与性能问题一样:

• 不要过早优化.如果SSRS中的某些内容更简单,那么就在那里进行.只有在出现问题时才考虑交易清晰度(可能是将代码移到SQL端).
• 测量.使用ExecutionLog2视图可以全面了解瓶颈的位置.做更多的测量和测试,这样你就可以确保你花时间提高重要的比特性能.

底线:让代码清晰指导您解决特定问题的位置,并在性能成为问题时有选择地进行优化.

Eric Lippert写了一篇关于何时以及如何担心性能的博客文章.上下文是C#,但基本思想也适用于其他情况,例如SSRS/SQL.

顺便说一下,如果你看一下上面提到的ExecutionLog2视图,你会发现实际上你应该知道三个性能组件:

1. 数据检索(SQL)
2. 报告模型(将数据集转换为内部模型)
3. 渲染(将模型转换为XLS,PDF等)

了解瓶颈所处的位置是了解如何解决性能问题的关键.

最后根据我的经验提出建议:

根据经验,如果您担心性能,尤其是聚合,则首选SQL而不是SSRS .如果需要,还可以考虑调整数据库(索引等).

如果我可以通过事实和研究进行支持,这种经验法则是最好的.唉,我没有.我可以说,根据我自己的经验,大多数情况下,当我遇到报告的性能问题时,将聚合和计算从SSRS移动到SQL将有助于解决此问题.