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