通常我们会定期使用SQL作业将事务数据聚合到一个表。现在，客户需要实时数据，因此1小时或者1小时过高。团队建议创建一个包含从事务表本身选择数据的逻辑的视图，而不是在几分钟之内运行任务。选择查询VS视图
但我的困惑是选择查询和视图之间的任何性能相关的区别。以周期性方式将数据放入聚合表中并从中选择容易，因为 1.它不影响主表
直接事务表中的直接选择语句会影响插入操作，因为它会频繁发生。如果我创建一个视图，我认为这个概念与选择语句相同。现在我们也从主表中进行选择。或者我的理解错了？
请建议这样做的最好的办法，为什么
如果我创建一个视图，我认为这个概念是一样的select语句
正确的，在其最简单形式的观点是无非是保存的查询定义。在查询中使用此视图时，定义将扩展到外部查询并进行相应优化。没有性能优势。当然索引视图并不是真的，视图本质上变成了它自己的表格，并且使用NOEXPAND查询提示将停止定义展开，并且将简单地从视图的索引中读取。由于这是一个聚合查询，尽管我怀疑索引视图是不可能的，所以不要介意一个可行的解决方案。
关于有一个表来存储聚合的下一部分更难回答。是的，这可能会使性能受益，但代价是没有达到最新的数据，并且不得不维护表格。这是否是一个合适的解决方案完全取决于您的需求，数据需要的最新情况，需要多长时间，需要多长时间（a）填充报告表（b）自行运行查询。
例如，如果运行查询需要20秒，但每天仅需要两次，那么每小时都不会运行此查询以维护报表以帮助每天运行两次的查询。
另一个选择是通过触发器来维护这个报表，例如，当插入/更新行时，将更改级联到报表中，然后这会使报表更新，但是如果您每天插入数百万次交易并运行报告几次，您必须权衡由触发器引起的额外开销是否值得。
你可以通过使用READ UNCOMMITTED为SELECT事务隔离级别降低写入操作的影响，但与汇总表选项，这是以具有多达第二精确信息的成本，因为你会读取未提交的交易。
最终选项可能是一个中间选项，每天创建一个汇总表，然后按日期对主表进行分区/索引，然后您可以从每天创建的表中获取历史数据的汇总，并将其与仅当今数据应该与正确的索引相对较快。
一个好的方法是创建视图和配置您的数据库。是的，检查视图是否是一个好的解决方案的最好方法是创建它并测试结果。
类似的问题在这里问： Is a view faster than a simple query?
k我明白了。对我来说，我是在shiftwise中汇总数据。所以我使用工作来运行每个班次或8个小时。对于我使用View的实时数据 – Akhil