Akh*_*hil 4 sql sql-server aggregate
通常我们会定期使用 SQL Job 将事务数据聚合到一张表中。现在客户需要实时数据，所以 1 小时或 1 小时太长了。团队建议创建一个视图，其中包含从事务表本身选择数据的逻辑，而不是在几分钟内运行作业。
但我的困惑是选择查询和视图之间任何与性能相关的差异。以周期性方式将数据放入聚合表中并从该聚合中进行选择很容易，因为 1. 它不会影响主表
直接事务表中的直接选择语句会影响频繁发生的插入操作。如果我创建一个视图，我认为这个概念与 select 语句相同。现在我们也从主表中进行选择。还是我的理解有误？
请提出最佳方法以及原因
如果我创建一个视图，我认为这个概念与 select 语句相同
正确的，最简单形式的视图只不过是保存的查询定义。当在查询中使用此视图时，定义将扩展到外部查询并进行相应优化。没有性能优势。当然，对于索引视图来说，情况并非如此，索引视图本质上成为它自己的表，并且使用NOEXPAND查询提示将停止扩展定义，而只是从视图的索引中读取。由于这是一个聚合查询，尽管我怀疑索引视图甚至不可能，更不用说可行的解决方案了。
关于使用表来存储聚合的下一部分更难回答。是的，这可以提高性能，但代价是没有最新的数据，并且还必须维护表。这是否是合适的解决方案完全取决于您的需求、数据需要的最新程度、需要的频率、(a) 填充报告表 (b) 自行运行查询需要多长时间。
例如，如果运行查询需要 20 秒，但每天只需要两次，那么每小时运行此查询来维护报告表来协助每天运行两次的查询是没有意义的。
另一种选择可能是通过触发器维护此报告表，即当插入/更新行时，将更改级联到报告表，然后，这将使报告表保持最新，但同样，如果您要插入数百万行一天交易并运行几次报告，您必须权衡触发器造成的额外开销是否值得。
READ UNCOMMITTED您可以通过使用 的事务隔离级别来减少对写入操作的影响SELECT，但与汇总表选项一样，这会以获取第二个准确信息为代价，因为您将读取未提交的事务。
最后一个选项可能是中间选项，每天创建一个汇总表，并按日期对主表进行分区/索引，然后您可以从每天创建的表中的历史数据中获取汇总，并将其与今天的数据合并使用正确的索引相对较快。