5
我想知道查询和视图在性能方面有什么区别。如果视图成本高昂，除了查询之外还有什么可以提高性能？查询与查看
Q
查询与查看
A
回答
1
在简单情况下，视图和即席查询在性能方面几乎相同。如此一来，当您用视图编程时，您应该将其视为视图定义的文本被剪切并粘贴到父查询中。
HLGEM在他的回答中指出，某些版本的SQL Server允许您“索引”视图 - 在这种情况下，SQL Server在后台维护与表格背后相同的结构，制作索引视图和表格在性能方面非常相似。
在SQL Server中，虽然通常可以相当宽松地嵌套视图而不会遇到性能问题，但它可能使事情变得更难以理解和调试。
0
如果您指的是网络性能，那么从本地缓存工作（与使用ADO.Net DataSets一样）将减少网络流量 - 但可能会导致锁定问题。只是一个想法。
1
如果他们执行完全相同的事情，则视图在第一次执行时可能会稍微快一点，因为数据库服务器将为其执行预编译的执行计划。取决于你的服务器。
Empasis的威力和咯...
+0
只是为了从Oracle角度阐明，视图在该平台上没有与它们相关联的存储执行计划。视图定义被合并到查询中并且整个查询被优化。 – 2008-12-04 19:36:27
0
视图仍然是一个查询，它只是抽象的某些部分，使您的查询可以简化（如果他们这样做类似的东西），并最大限度地重用。
1
视图促进了代码重用，可以抽象出数据库的复杂性，以提供更一致的“业务”数据模型。然而，它们几乎没有可调节性。您可能会发现自己处于需要提供联合提示或其他低级别优化的位置，并且许多与之合作的DBA不喜欢将它们应用于视图，因为它们可能会在许多查询中重用，意见是这些尽可能少地使用提示类型。我喜欢自己使用视图。
2
在SQL Server中，我认为视图和查询之间的性能差异可以忽略不计。我建议用来提高性能的方法是创建另一个表格来保存视图的结果。您可以创建一个临时表，其中保存新数据，然后可以以某个时间间隔运行存储过程，以使用新信息填充工作表。触发器可能对此有好处。根据您的应用要求，这种设计可能适用，也可能不适合。如果您正在处理接近实时的数据，这种方法将导致并发性问题...
另一个需要研究的问题是要确保您用于构建视图的基表被编入索引正确，并且查询本身已经过优化。最后，我相信在SQL Server企业中可以创建索引视图，尽管我之前没有使用它们。
+0
手动维护的“具体化查询表”通常很难做到，而且在性能方面非常昂贵，无法精确维护，甚至忽略了磁盘空间的成本。 – 2008-11-27 17:28:01
1
对于计算机来说，查看勉强比写出查询花费更昂贵。一个视图可以节省程序员/用户很多时间，一次又一次地写出相同的查询，并且弄错了，等等。如果视图也用于强制对基础表执行授权（访问控制），则视图也可能是访问数据的唯一方法。
如果查询不能很好地执行，则需要查看查询是如何形成的以及这些表是否都具有适当的索引。如果您的系统需要精确的统计数据以使优化器表现良好，那么您最近是否足够更新了这些统计数据？
很久以前，我遇到了一个查询生成器创建了一个查询的系统，该查询在单个FROM子句中列出了十七个表，其中包括与其自身表的几个LEFT OUTER JOIN。事实上，更仔细的审查表明，其中一些“表”实际上是多表视图，其中一些还涉及自外连接，并且它们本身涉及视图的自外连接。说“可怕”是轻描淡写。可以通过很多清理来提高查询的性能 - 消除不必要的外连接，自连接等等。 （它实际上是SQL-92的明确加入符号的预先注明 - 我很久以前说过 - 所以外连接语法是DBMS特有的。）
3
我不能说所有的数据库，但是在SQL Server中除非您有企业版本，否则无法为视图编制索引。未经索引的视图在性能方面可能会比查询更差，特别是如果您正在编写针对它的查询以在条件中添加一些查询。索引视图通常可以很好地执行。索引视图也可以针对不同表中的多个字段，并且可以提高特定查询的性能。 （它可能不会，在性能调整中，您必须始终针对您的特定情况进行测试。）
反对意见的一点是它们不允许运行时选择哪里标准。通常你最终会看到一个视图和一个查询。
视图可以更容易维护（只需在联接中添加新表，并且访问财务报表的所有内容都可用），但它们对性能调整要困难得多。这部分是因为它们往往是过度泛化的，因此比仅仅返回最小必需量的对应物慢。是的，正如乔纳森所说，你可以非常容易地将报告的观点融合在一起，这些混乱与同一张大桌子连接的次数比需要的次数多得多，而且速度很慢。
两个地方，虽然意见闪耀，但： 确保复杂的关系总是正确描述。这是报告撰写者倾向于赞成他们的原因之一。 限制对记录子集的访问
对于特殊查询或存储过程视图副作用可以完成的查询类型也有限制。例如，您不能使用if语句（或其他过程类型代码，如循环），或者如上所述，您无法为where条件提供运行时值。
一个地方的意见往往显着较慢是当他们打电话给其他意见。底层视图需要在某些数据库中完全实现，因此您可能需要调用4,459,203条记录来查看您最终感兴趣的10个记录。开始将其叠加多次，并且速度非常慢，速度非常快;调用意见的观点只是一种不好的做法。
除非他们没有。现在有这个问题。即时查询的速度比转换为View的同一查询快几个数量级。所以总是三思。 – DanMan 2011-04-29 13:09:55
@丹曼除非你能解释这种情况，否则这不是一个真正有用的评论。 – 2013-06-27 19:35:32