查询与视图

Question

我想知道查询和视图在性能方面有什么区别。如果视图代价高昂，除了查询之外还可以做些什么来提高性能？

Answer 1

我无法代表所有数据库，但在SQL Server中，除非您拥有企业版，否则无法索引视图。未经索引的视图在性能方面可能明显比查询差，特别是如果您正在编写查询以添加某些条件。索引视图通常可以很好地执行。索引视图也可以针对多个字段，这些字段位于不同的表中，并且可以提高性能而不是即席查询。 （在性能调整中，您可能必须始终根据您的特定情况进行测试。）

反对意见的一点是，它们不允许运行时选择标准。因此，您通常会同时使用视图和查询。

可以更轻松地维护视图（只需在连接中添加新表，并且访问财务报表的所有内容都可用）但是它们在性能调整上要困难得多。这部分是因为它们往往过于概括，因此比仅返回必要的最小值的对应物慢。是的，正如乔纳森所说，你可以很容易地将报告加入到一个混乱的视图中，这种混乱加入到相同的大表中的次数比需要的多很多次并且非常慢。

观点闪耀的两个地方是： 确保始终正确描述复杂关系。这是报告编写者倾向于支持它们的一个原因。 限制对记录子集的访问

对于视图副，即时查询或存储过程，可以执行的查询类型也存在限制。例如，您不能使用if语句（或其他过程类型代码，如循环），或者如上所述，您无法为where条件提供运行时值。

视图通常明显较慢的地方是他们调用其他视图时。底层视图需要在某些数据库中完全实现，因此您可能需要调用4,459,203条记录才能看到您最终感兴趣的10条记录。开始分层不止一次，它可以变得非常慢，非常快;调用视图的视图只是一种糟糕的做法。

Answer 2

在SQL Server中，我认为视图和查询之间的性能差异可以忽略不计。我建议用来提高性能的是创建另一个包含视图结果的表。您可以创建一个临时表，其中保存新数据，然后可以在某个时间间隔运行存储过程，该时间间隔使用新信息填充工作表。触发器可能有助于此目的。根据您的应用要求，此设计可能适合也可能不适合。如果您正在处理近实时数据，这种方法将导致并发问题......

另一个需要注意的是，要确保用于构建视图的基表已正确索引，并且查询本身已经过优化。最后，我相信在SQL Server企业中可以创建索引视图，尽管我之前没有使用它们。

Answer 3

如果它们执行完全相同的操作，则第一次执行时视图可能会稍快一些，因为数据库服务器将为其预先编译执行计划。取决于你的服务器。

可能而且稍微有点......

Answer 4

视图促进了代码重用，可以抽象出数据库复杂性，从而提供更加连贯的“业务”数据模型。然而，它们几乎不可调。您可能会发现自己处于需要提供联接提示或其他低级优化的位置，而且我曾与之合作的许多DBA不喜欢将它们应用于视图，因为它们可能会在许多查询中重复使用，其意见是这些应尽可能少地使用提示类型。我喜欢自己使用观点。

Answer 5

在简单的情况下，视图和临时查询在性能方面几乎相同。因此，当您使用视图进行编程时，您应该将其视为剪切并粘贴到父查询中的视图定义文本。

HLGEM在他的回答中指出，SQL Server的某些版本允许您“索引”视图 - 在这种情况下，SQL Server维护与基础相同的结构，使得索引视图和表非常性能相似。

在SQL Server中，尽管通常可以非常自由地嵌套视图而不会遇到性能问题，但它可能会使事情变得更难以理解和调试。

Answer 6

对于计算机来说，视图比直接写出查询要贵得多。一个视图可以节省程序员/用户很多时间，一次又一次地编写相同的查询，并且出错，等等。如果视图也用于对基础表执行授权（访问控制），则视图也可能是访问数据的唯一方法。

如果查询效果不佳，则需要查看查询的形成方式，以及表中是否都有相应的索引。如果您的系统需要准确的统计信息以使优化器运行良好，那么您最近是否更新了这些统计信息？

很久以前，我遇到了一个系统，其中查询生成器创建了一个查询，该查询在单个FROM子句中列出了17个表，包括表自身的几个LEFT OUTER JOIN。事实上，更仔细的审查表明，几个“表”实际上是多表视图，其中一些还涉及自外连接，并且它们本身也参与了视图的自外连接。说“ ghastly ”是轻描淡写的。可以进行大量清理以提高查询的性能 - 消除不必要的外连接，自连接等。 （它实际上早于SQL-92的显式连接符号 - 我很久以前说过 - 所以外连接语法是特定于DBMS的。）

Answer 7

如果您的意思是网络性能，那么从本地缓存（与ADO.Net DataSet一样）工作会减少网络流量 - 但可能会导致锁定问题。只是一个想法。

Answer 8

视图仍然是一个查询，它只是抽象它的某些部分，以便您的查询可以简化（如果他们做类似的事情）并最大化重用。