sql - 在哪里执行？ SSRS 或 SQL

Question

当我创建一个 SSRS 报告时，我总是有一个关于“如何以尽可能少的生成时间创建报告”的困境。

一般来说，生成时间(或性能时间)分为两个主要部分:

SQL 查询。

报告组件(表达式、组等)。

如您所知，SSRS 中执行的某些操作可以在 SQL 查询中完成，反之亦然。

例如:

我可以用 Group by SQL 中的子句，但在使用带有组定义的表时也可以这样做。

我可以用 Casting为了比较 SQL 中的两个值，也可以直接在表达式中进行比较。

还有很多...

我的问题是:

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

B. 当遇到在何处执行给定情况的困境时，我应该根据哪些指导方针(如果有)做出决定？

Answer 1

与性能问题一样:

不要过早地优化。 如果 SSRS 中的某些事情更简单，那么就在那里进行。只有在出现问题时才考虑为性能而交易清晰度(可能通过将代码移动到 SQL 端)。

措施。 使用 ExecutionLog2以大致了解您的瓶颈在哪里。进行更多的测量和测试，以确保您投入时间来提高重要位的性能。

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

埃里克·利珀特写道 a nice blog post关于何时以及如何担心性能。上下文是 C#，但基本思想也适用于其他情况，例如 SSRS/SQL。

顺便说一句，如果你看看上面提到的 ExecutionLog2查看，您会注意到实际上您应该了解性能的三个组成部分:

数据检索 (SQL)

报表模型(将数据集转换为内部模型)

渲染(将模型转换为 XLS、PDF 等)

知道瓶颈位于哪一部分是了解如何解决性能问题的关键。

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

根据经验， 比 SSRS 更喜欢 SQL 如果您担心性能，尤其是聚合。如果需要，还可以考虑调整您的数据库(索引等)。

如果我能用事实和研究来支持它，这条经验法则将是最好的。唉，我没有。我可以说，根据我自己的经验，当我在将聚合和计算从 SSRS 迁移到 SQL 的报告中遇到性能问题时，通常会帮助解决这个问题。