视图比简单的查询快吗?

是的，视图可以分配了一个聚集索引，当它们这样做时，它们将存储临时结果，可以加快结果查询。

微软自己的文档非常清楚地表明，Views可以提高性能。

首先，人们创建的大多数视图都是简单的视图，并且不使用此特性，因此与直接查询基表没有区别。简单视图在适当的位置展开，因此不直接有助于性能改进 -这是正确的。然而,索引视图可以戏剧性的提高性能。

让我直接看文档:

在视图上创建了唯一的聚集索引之后，视图的结果集将立即物化，并持久化在数据库的物理存储中，从而节省了在执行时执行这一昂贵操作的开销。

其次，这些索引视图可以工作即使它们没有被另一个查询直接引用，因为优化器会在适当的时候使用它们来代替表引用。

同样，文档:

索引视图可以以两种方式在查询执行中使用。查询可以直接引用索引视图，或者更重要的是，如果查询优化器确定该视图可以在成本最低的查询计划中替代部分或全部查询，则可以选择该视图。在第二种情况下，使用索引视图代替底层表及其普通索引。不需要在查询中引用视图，查询优化器就可以在查询执行期间使用它。这允许现有应用程序从新创建的索引视图中获益，而无需更改这些应用程序。

此文档以及演示性能改进的图表可以在在这里中找到。

更新2:的答案已经被批评的基础上，它是"索引"提供性能优势，而不是“视图”;然而，这很容易被反驳。

假设我们是一个小国的软件公司;我将以立陶宛为例。我们在全球销售软件，并将我们的记录保存在SQL Server数据库中。我们非常成功，所以，在几年内，我们有100多万张唱片。然而，出于纳税的目的，我们经常需要报告销售额，我们发现我们在国内只销售了100份软件。通过创建立陶宛记录的索引视图，我们可以将需要的记录保存在MS文档中描述的索引缓存中。当我们运行2008年立陶宛销售的报告时，我们的查询将搜索深度仅为7的索引(Log2(100)，其中有一些未使用的叶子)。如果我们在没有VIEW的情况下做同样的事情，而只是依赖于表中的索引，我们必须遍历一个搜索深度为21的索引树!

显然，视图本身会比单独使用索引提供性能优势(3倍)。我试图使用一个现实世界的例子，但您会注意到，立陶宛销售的简单列表会给我们带来更大的优势。

注意，在我的例子中，我只是使用了一个直b树。虽然我相当确定SQL Server使用了b-树的一些变体，但我不知道细节。尽管如此，这一点还是成立的。

关于索引视图是否只使用底层表上的索引的问题出现了。换句话说:“索引视图只是一个标准索引的等价物，它没有提供任何新的或独特的视图。”当然，如果这是真的，那么上面的分析就是不正确的!让我引用微软文档中的一段话来说明为什么我认为这种批评是不正确的:

使用索引来提高查询性能并不是一个新概念;然而，索引视图提供了使用标准索引无法实现的额外性能优势。

加上上面关于物理存储中数据的持久性和文档中关于如何在视图上创建索引的其他信息的引用，我认为可以安全地说，索引视图是不，只是一个缓存的SQL Select，恰好使用了在主表上定义的索引。因此，我继续坚持这个答案。

编辑:我错了，你应该看到标记上面的答案

我不能从SQL 服务器的经验来说，但对于大多数数据库来说，答案是否定的。在性能方面，使用视图获得的唯一潜在好处是它可能基于查询创建一些访问路径。但是使用视图的主要原因是简化查询或标准化访问表中某些数据的方式。一般来说，您不会获得性能上的好处。不过，我可能错了。

我会举一个稍微复杂一点的例子，自己计时看看。

如果你创建一个物化视图(与模式绑定)可能会更快。非物化视图的执行就像常规查询一样。

我的理解是，在过去，视图会更快，因为SQL Server可以存储执行计划，然后直接使用它，而不是试图在飞行中找出一个。我认为现在的性能增益可能没有以前那么大，但我不得不猜测使用视图会有一些边际改进。

我希望这两个查询的执行是相同的。视图只不过是一个存储的查询定义，视图没有缓存或存储数据。当您运行第一个查询时，优化器将有效地将其转换为第二个查询。

没有实际的区别，如果你读BOL，你会发现你的普通旧SQL SELECT * FROM X确实利用了计划缓存等。

至少在SQL Server中，基于查询/视图参数，查询计划存储在视图和普通SQL查询的计划缓存中。对于这两种查询，当它们没有使用足够长一段时间并且需要空间用于其他新提交的查询时，它们就会从缓存中删除。在此之后，如果发出相同的查询，则重新编译该查询，并将计划放回缓存中。因此，没有区别，因为您以相同的频率重用相同的SQL查询和相同的视图。

显然，在一般情况下，一个视图，根据它的本质(有人认为它被经常使用，使它成为一个视图)通常比任何任意的SQL语句更有可能被“重用”。

存储执行计划应该会有一些微不足道的好处，但可以忽略不计。

视图的目的是一遍又一遍地使用查询。为此，SQL Server、Oracle等通常会提供视图的“缓存”或“编译”版本，从而提高其性能。一般来说，这应该比“简单”查询执行得更好，但如果查询确实非常简单，好处可能可以忽略不计。

现在，如果您正在执行一个复杂的查询，请创建视图。

对于SQL Server来说，视图肯定比嵌套查询要好。在不知道为什么它更好的情况下(直到我读到Mark Brittingham的文章)，我已经运行了一些测试，在使用视图和嵌套查询时，我经历了几乎惊人的性能提升。在连续运行查询的每个版本数百次之后，查询的视图版本在一半的时间内完成。我得说这对我来说已经足够了。

一般来说，没有。视图主要用于方便和安全，(它们自己)不会产生任何速度上的好处。

也就是说，SQL Server 2000及以上版本确实有一个名为索引视图的特性，可以极大地提高了性能，但有一些注意事项:

1. 不是每个视图都可以被做成索引视图;它们必须遵循一套具体的指导方针，这(在其他限制中)意味着你不能包含常见的查询元素，如COUNT， MIN， MAX，或TOP。
2. 索引视图使用数据库中的物理空间，就像表上的索引一样。

本文描述了附加的索引视图的好处和限制:

你可以…

属性中的一个或多个表 李相同数据库。< / >
• 一旦创建了唯一的聚集索引，额外的非聚集索引 可以根据视图创建索引
• 你可以更新底层表中的数据-包括插入， 更新，删除，甚至截断

你不能…

• 视图定义不能引用其他视图或表
.在其他数据库中
• 不能包含COUNT, MIN, MAX, TOP，外部连接或其他一些参数
.关键字或元素
• 不能修改底层表和列。观点是
.使用with SCHEMABINDING选项创建 你不能总是预测查询优化器会做什么。如果你 使用企业版，它会自动考虑唯一 聚集索引作为查询的一个选项-但如果它找到一个“更好的” 索引，它将被使用。方法可以强制优化器使用 index通过WITH NOEXPAND提示-但在使用any时要谨慎 李暗示。< / >

在我的发现中，使用视图比普通查询要快一些。我的存储过程大约花了25分钟(使用不同的更大的记录集和多个连接)，在使用视图(非集群)后，性能稍微快了一点，但并不显著。我不得不使用一些其他的查询优化技术/方法来做出巨大的改变。

这要视情况而定。索引视图比普通视图或查询快，但不能在镜像数据库环境(MS SQL)中使用索引视图。

任何类型的循环中的视图都会导致严重的减速，因为每次在循环中调用视图时都会重新填充视图。与查询相同。在这种情况下，使用#或@来保存要循环的数据的临时表比视图或查询更快。

所以这要视情况而定。

从视图或表中选择没有太大意义。

当然，如果视图没有不必要的连接、字段等。您可以检查用于提高View性能的查询、连接和索引的执行计划。

您甚至可以为更快的搜索需求在视图上创建索引。http://technet.microsoft.com/en-us/library/cc917715.aspx

但是如果你搜索'%…SQL引擎将不能从文本列上的索引中获益。如果你能强迫你的用户进行类似“……比那快多了

参考asp论坛上的回答: https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+or+Table+ < / p >

出乎意料的是，在某些情况下，视图会慢得多。

我最近发现这一点，当我从Oracle中提取的数据出现问题时，需要将其按摩成另一种格式。也许有2万行源行。一张小桌子。为此，我们尽可能地将oracle数据导入到一个表中，然后使用视图提取数据。 我们在这些观点的基础上提出了次要观点。可能有3-4层视图。< / p >

最后一个查询可能提取了200行，需要45分钟以上!该查询基于视图级联。可能有3-4层深。

我可以使用每个视图，将其sql插入到一个嵌套查询中，并在几秒钟内执行它。

我们甚至发现，我们甚至可以将每个视图写入临时表和查询，以代替视图，这仍然比简单地使用嵌套视图快得多。

更奇怪的是，性能一直很好，直到我们达到了将源行拉入数据库的限制，性能在几天内急剧下降——只需要多几行源行就可以了。

因此，使用从视图中提取的查询比嵌套查询慢得多，这对我来说毫无意义。

我无意中看到了这个帖子，只是想分享Brent Ozar的这篇文章，作为使用可用性组时的考虑。

Brent Ozar bug报告

不。View只是实际的长SQL查询的一种简短形式。但是，你可以说实际查询比视图命令/查询更快。

首先视图查询将转换为简单查询，然后执行，因此视图查询将比简单查询执行更多的时间。

当您使用连接b/w多个表时，可以使用sql视图，以简单的方式一次又一次地重用复杂的查询。