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

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

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

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

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

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

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

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

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

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

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

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