4

在创建 SSRS 报告时，我总是对“如何以尽可能少的生成时间创建报告”感到两难。

一般来说，生成时间（或执行时间）分为两个主要部分：

  1. SQL 查询。
  2. 报告组件（表达式、组等）。

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

例如：

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

还有很多...

我的问题是：

A.哪个部分（SQL 查询或 SSRS）花费更多时间（假设该任务可以在 SSRS 和 SQL 中完成）？

B.当遇到在哪里执行给定情况的两难选择时，我应该根据哪些指导方针（如果有）做出决定？

4

2 回答 2

6

与性能问题一样：

  • 不要过早优化。如果 SSRS 中的某些事情更简单，那么就在那里进行。只有在出现问题时才考虑用清晰度换取性能（可能通过将代码移动到 SQL 端）。
  • 措施。使用ExecutionLog2视图可以大致了解您的瓶颈在哪里。进行更多的测量和测试，以确保您正在投入时间来提高重要位的性能。

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

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

顺便说一句，如果您查看提到的ExecutionLog2视图，您会注意到实际上您应该了解三个性能组件：

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

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

最后根据我的经验提出一个建议：

根据经验，如果您担心性能，尤其是聚合方面，请首选 SQL 而不是 SSRS 。 如果需要，还可以考虑调整您的数据库（索引等）。

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

于 2013-02-01T12:01:51.387 回答
2

重要的是要记住 SSRS 很聪明，并且会在您需要时保存异常。如果您正在导出，那么它将提取所有数据。此外，如果您正在在线查看并且您有展开和折叠行，则在您想要查看之前不会执行它们。根据该理论，首选基本 SQL。

最好将聚合留给 SSRS，因为无论如何报告都会尝试在 tablix 中聚合。至于图表，除非您也有 tablix，否则最好汇总。

至于简单的计算，应该在SQL中完成，比如比较等。

请记住，SSRS比您更聪明;) 并且最简单的 SQL 可以使此服务发挥最佳效果，并且此服务主要用于显示。

如果您将 MS SQL 服务器用于数据集，则该服务将发挥最佳作用。

于 2013-02-02T00:12:41.477 回答