我们在数据库中有大量的聚合查询，用于制定（有时是实时的）业务决策。不幸的是，呈现这些聚合的页面是最常被调用的页面，并且SP是页面传递的参数。查询本身已被调整，但不幸的是每个SP都会生成少数聚合字段。
我们正在进行一些性能调优，其中一项任务是重新完成这些聚合的完成方式。
我们的想法是可能创建执行其中某些操作的SP并将它们存储在表中。然后页面可以在表上运行更简单的选择查询，仍然使用参数将其限制为正确的数据集。它不会像＃34;实时＆＃34;，但可能足够频繁。
另一个建议的解决方案是在我们的DWH中执行聚合查询，并且（通过）SSIS将数据传递回Prod db中的表。我们的DWH数据库的流量显着减少，因此它可以轻松应对繁重的工作。
关于简化查询和呈现通常会被考虑的内容的方法有哪些想法＆＃34;报告＆＃34; Prod环境中的数据？目前的SP每天可能被称为几千次。是否将DWH数据推回到针对BI最佳实践的Prod数据库？这是在CLR Proc（不熟悉CLR）中做得更好吗？
答案 0 :(得分：1)
要使用预先汇总的计算并仍然回答NRT中的所有问题，您可以这样做：
计算每分钟/小时/天的聚合，并将其作为聚合值存储在数据库中。然后，如果对数据库进行了查询，则使用这些聚合。对于聚合中不存在的时间，您使用在最后一个聚合的最终时间戳之后插入的原始数据。它需要更多的编码，但这是最终的解决方案。
答案 1 :(得分：0)
我没有看到将汇总报告数据从数据仓库推送回prod数据库以进行交付时没有任何问题，但作为一名评论者提到，您本身会引入一个可能无法接受的实时延迟'决定。
另一个选项，只要聚合的性质相对简单，就是索引视图。实质上，您使用报告所需的聚合级别创建源表视图，然后在其上放置索引。索引意味着SQL服务器实际上预先计算了视图并将其作为真实表存储在磁盘上，因此当您执行报告查询时，它实际上不需要读取源表的完整详细信息并将其聚合。
SQL可以对索引视图执行的另一个巧妙的技巧是“聚合感知”，这意味着即使您查询源表，如果规划器实现它可以更快地从索引视图中获得答案，那么它将会。您甚至不需要为他们更新现有的触发器以获得好处。
这可能听起来好得令人难以置信，并且在某些方面确实如此，因为存在几个巨大的缺点：
您可以在视图中使用的SQL语法存在大量限制，例如，虽然您可以使用sum和count_big，但您不能使用max / min（这显然很奇怪） 。你可以做内部连接而不是外部连接。您无法使用窗口功能。名单继续......
此外，在向视图引用的表中写入时，显然会有性能成本，因为视图必须更新。因此，您需要在生成此类内容之前使用典型工作负载测试环境中的性能。