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

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

首先，人们创建的大多数视图都是简单视图，不使用此特性，因此与直接查询基表没有区别。简单视图是在适当的地方进行扩展的，因此不会直接促进性能的提高——这是事实。然而，索引视图可以显著提高性能。

让我直接看文档:

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

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

同样，文档:

The indexed view can be used in a query execution in two ways. The query can reference the indexed view directly, or, more importantly, the query optimizer can select the view if it determines that the view can be substituted for some or all of the query in the lowest-cost query plan. In the second case, the indexed view is used instead of the underlying tables and their ordinary indexes. The view does not need to be referenced in the query for the query optimizer to use it during query execution. This allows existing applications to benefit from the newly created indexed views without changing those applications.

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

更新2:这个答案受到了批评，因为提供性能优势的是“索引”，而不是“视图”。然而，这很容易被反驳。

Let us say that we are a software company in a small country; I'll use Lithuania as an example. We sell software worldwide and keep our records in a SQL Server database. We're very successful and so, in a few years, we have 1,000,000+ records. However, we often need to report sales for tax purposes and we find that we've only sold 100 copies of our software in our home country. By creating an indexed view of just the Lithuanian records, we get to keep the records we need in an indexed cache as described in the MS documentation. When we run our reports for Lithuanian sales in 2008, our query will search through an index with a depth of just 7 (Log2(100) with some unused leaves). If we were to do the same without the VIEW and just relying on an index into the table, we'd have to traverse an index tree with a search depth of 21!

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

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

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

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

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

编辑:我错了，你应该在上面看到马克斯的回答。

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

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

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

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

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

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

In SQL Server at least, Query plans are stored in the plan cache for both views and ordinary SQL queries, based on query/view parameters. For both, they are dropped from the cache when they have been unused for a long enough period and the space is needed for some other newly submitted query. After which, if the same query is issued, it is recompiled and the plan is put back into the cache. So no, there is no difference, given that you are reusing the same SQL query and the same view with the same frequency.

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

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

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

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

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

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

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

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

本文描述了索引视图的其他优点和局限性:

You Can… The view definition can reference one or more tables in the same database. Once the unique clustered index is created, additional nonclustered indexes can be created against the view. You can update the data in the underlying tables – including inserts, updates, deletes, and even truncates. You Can’t… The view definition can’t reference other views, or tables in other databases. It can’t contain COUNT, MIN, MAX, TOP, outer joins, or a few other keywords or elements. You can’t modify the underlying tables and columns. The view is created with the WITH SCHEMABINDING option. You can’t always predict what the query optimizer will do. If you’re using Enterprise Edition, it will automatically consider the unique clustered index as an option for a query – but if it finds a “better” index, that will be used. You could force the optimizer to use the index through the WITH NOEXPAND hint – but be cautious when using any hint.

在我的发现中，使用视图比普通查询要快一些。我的存储过程大约花了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+

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

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

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

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

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

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

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

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

布伦特·欧扎尔报道

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

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

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