选择Query

Question

通常，我们使用SQL定期将事务数据聚合到一个表中。现在客户需要实时数据，所以1小时或1小时太高了。团队建议创建一个包含从事务表本身中选择数据的逻辑的视图，而不是在几分钟内运行作业。

但是我的困惑是select查询和View之间与性能有关的任何差异。以周期性的方式将数据放入聚合表并从中选择是很容易的，因为1.它不影响主表。

直接事务表中的直接select语句影响插入操作，因为它经常发生。如果我创建一个视图，我认为这个概念与select语句是相同的。现在，我们也从主表中进行选择。还是我的理解错了？

请提出最好的方法和原因。

Answer 1

如果我创建一个视图，我认为这个概念与select语句相同。

正确，视图最简单的形式不过是保存的查询定义。当在查询中使用此视图时，定义将展开到外部查询中，并相应地进行优化。没有性能效益。当然，对索引视图来说不是这样，因为视图本质上是它自己的表，使用NOEXPAND查询提示将停止扩展定义，只需从视图的索引(Es)中读取。因为这是一个聚合查询，尽管我怀疑索引视图甚至是不可能的，更不用说一个可行的解决方案了。

关于有一个表来存储聚合的下一部分更难回答。是的，这可能对性能有好处，但代价是不需要多达分钟的数据，而且还必须维护表。这是否是一个合适的解决方案完全取决于您的需求、数据的最新需要、所需的频率、(a)填充报表表(b)自己运行查询所需的时间。

例如，如果运行查询需要20秒，但每天只需要运行两次，那么就没有必要每小时运行此查询来维护一个报表，以帮助每天运行两次的查询。

另一种选择可能是通过触发器维护此报告表，即当插入/更新一行时，将更改级联到报告表，然后，这将使报告表更新，但同样，如果您每天插入数百万个事务并运行报告几次，则必须权衡触发器引起的额外开销是否值得。

您可以通过为READ UNCOMMITTED使用事务隔离级别SELECT来减少对写操作的影响，但与汇总表选项一样，这是以获得最多第二个准确信息为代价的，因为您将读取未提交的事务。

最后一个选项可以是一个中间选项，每天创建一个汇总表，并按日期对主表进行分区/索引，然后您可以从每天创建的表中获取历史数据，并将其与今天的数据结合起来，这些数据应该相对较快地与正确的索引结合起来。

Answer 2

一种很好的方法是创建视图并分析您的DB。是的，检查视图是否是一个好解决方案的最好方法是创建视图并测试结果。

这里提出了一个类似的问题：Is a view faster than a simple query?