视图比简单查询快吗？

Question

是一个

select *  from myView

比查询本身更快地创建视图（为了具有相同的结果集）：

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

?

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

原文由 JohnIdol 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

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

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

首先，人们创建的大多数视图都是 简单 视图，不使用此功能，因此与直接查询基表没有什么不同。简单视图在原地扩展，因此 不会直接促进性能改进- 确实如此。 但是， 索引视图可以 显着 提高性能。

让我直接进入文档：

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

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

再次，文档：

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

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

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

假设我们是一个小国家的软件公司；我将以立陶宛为例。我们在全球范围内销售软件并将我们的记录保存在 SQL Server 数据库中。我们非常成功，因此在几年内，我们拥有超过 1,000,000 条记录。但是，出于税收目的，我们经常需要报告销售额，并且我们发现我们在本国仅售出了 100 份我们的软件。通过创建仅立陶宛记录的索引视图，我们可以将我们需要的记录保存在索引缓存中，如 MS 文档中所述。当我们运行 2008 年立陶宛销售报告时，我们的查询将搜索深度仅为 7 的索引（Log2(100) 和一些未使用的叶子）。如果我们要在没有 VIEW 的情况下做同样的事情，而只依赖表中的索引，我们将不得不遍历搜索深度为 21 的索引树！

显然，与单独使用索引相比，视图本身将为我们提供性能优势（3 倍）。我尝试使用真实世界的示例，但您会注意到，立陶宛销售的简单列表会给我们带来更大的优势。

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

更新 3： 关于索引视图是否仅使用放置在基础表上的索引的问题出现了。也就是说，套用一句话：“索引视图相当于标准索引，它没有提供任何新的或独特的视图。”如果这是真的，那上面的分析当然是不正确的！让我引用 Microsoft 文档中的一段话来说明为什么我认为这种批评是无效或不正确的：

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

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

原文由 Mark Brittingham 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

不，视图只是您实际长 sql 查询的一种简短形式。但是，是的，您可以说实际查询比查看命令/查询要快。

第一个视图查询将转换为简单查询然后执行，因此视图查询将比简单查询花费更多时间来执行。

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

原文由 Billu 发布，翻译遵循 CC BY-SA 4.0 许可协议