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

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

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

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

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

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

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

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

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

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

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

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

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

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