Sql 视图比简单查询快吗？

是一个

创建视图的速度比查询本身快（以便获得相同的结果集）：

?

---

我并不完全清楚视图是否使用了某种缓存，使其比简单查询更快

是，视图可以指定聚集索引，当它们指定聚集索引时，它们将存储临时结果，从而加快结果查询的速度

更新：至少有三个人在这个问题上投票反对我。恕我直言，我认为他们错了；Microsoft自己的文档非常清楚地表明，视图可以提高性能

首先，简单视图被适当地扩展，因此不会直接促进性能的提高——这是事实但是，索引视图可以显著提高性能

让我直接转到文档：

在视图上创建唯一的聚集索引后，视图的结果集将立即具体化并保存在数据库的物理存储中，从而节省了在执行时执行此代价高昂的操作的开销

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

同样，文件：

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

可以找到此文档以及演示性能改进的图表

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

我们可以说，我们是一个小国的软件公司；我将以立陶宛为例。我们在全球范围内销售软件，并将记录保存在SQL Server数据库中。我们非常成功，因此，在几年内，我们有1000000多个记录。然而，出于税务目的，我们经常需要报告销售额，我们发现我们的软件在我们的祖国只销售了100份。通过创建立陶宛记录的索引视图，我们可以将所需的记录保存在索引缓存中，如MS文档中所述。当我们在2008年运行立陶宛销售报告时，我们的查询将搜索深度仅为7的索引（Log2（100），其中有一些未使用的叶子）。如果我们在没有视图的情况下也这样做，并且仅仅依赖于表中的索引，那么我们必须遍历搜索深度为21的索引树

显然，视图本身将为我们提供一个性能优势（3倍），而不仅仅是简单地使用索引。我试着用一个真实的例子，但你会注意到一个简单的立陶宛销售清单会给我们带来更大的优势

请注意，我只是使用了一个直b-树作为示例。虽然我相当肯定SQLServer使用了某种b树的变体，但我不知道细节。尽管如此，这一点仍然成立

更新3:问题是，索引视图是否只使用放置在基础表上的索引。也就是说，换言之：“索引视图只是标准索引的等价物，它没有为视图提供任何新的或独特的内容。”当然，如果这是真的，那么上述分析就不正确了！请允许我引用Microsoft文档中的一段话，说明我认为这一批评无效或不正确的原因：

使用索引来提高查询性能并不是一个新概念；但是，索引视图提供了其他性能好处，而这些好处无法使用标准索引实现

---

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

编辑：我错了，你应该看到

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

---

我会提出一个稍微复杂一些的例子，自己来看看。

如果创建一个物化视图（，使用模式绑定）可能会更快。非物化视图的执行与常规查询一样。

我的理解是，不久前，视图会更快，因为SQL Server可以存储一个执行计划，然后直接使用它，而不是试图动态地找出一个执行计划。我认为现在的性能提升可能没有以前那么大了，但我不得不猜测使用视图会有一些微小的改进。

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

select *  from myView

select * from ([query to create same resultSet as myView])