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