【发布时间】：2011-03-03 19:48:08
【问题描述】：
据我了解，数据将被“持久化”（物理存储，而不仅仅是在需要时检索）。它是否正确？
如果是这样，与仅使用表相比，使用索引视图有什么优势？
【问题讨论】：
标签： sql-server indexing views
【发布时间】：2011-03-03 19:48:08
【问题描述】：
我们使用索引视图来“预连接”几个在许多地方使用的常用表。
它们对于在 SQL Server 2008 之前实现过滤索引也很有用
不过，MSDN 上有一篇关于它们的文章：“Improving Performance with SQL Server 2005 Indexed Views”（顺便说一句，Google 上的第一击）
【讨论】：
索引视图可以通过以下方式提高查询性能：
- 可以预先计算聚合并将其存储在索引中，以最大限度地减少查询执行期间昂贵的计算。
- 可以预先加入表并存储生成的数据集。
- 可以存储连接或聚合的组合。
【讨论】：
您尝试比较一个索引视图，例如，只是另一个表。
如果您希望此其他表始终与系统中的其他表（即索引视图引用的表）保持一致，则必须为这些其他表编写许多触发器，以便工作。如果视图相当复杂（多个基表、复杂的 where 子句或聚合），则这些触发器可能难以编写和正确。
但您不必做这项工作，因为它已经作为索引视图内置到 SQL Server 中 - 只需将其视为 SQL Server 自动编写所有这些触发器，并在第一时间完成所有操作。
【讨论】：
让我们先从一个非常高的层次来看问题。关系是元组和逻辑值之间的映射（通常是 true、false 和 null，但理论上可以有更多）。
父/子关系将形式为 (person, person) 的元组映射到集合 {true, false, null}。
因此，在理想世界中，您可以向无所不知的实体（即神谕）询问任何父子对，并得到是/否/答案。
现在，计算机显然无法搜索所有可能的父子对的整个空间。您必须告诉从哪里开始搜索以及在放弃之前搜索多远。这就是“表”。我们传统上将表格视为集合，但实际上我们应该更明确地将它们视为搜索空间的界限。
如您所知，索引只是一种组织数据的方式，以便它可以更快地搜索表（进行更少的比较）。因此，索引是进一步缩小搜索空间的一种方式（但要视具体情况而定）。
现在，当您编写一个连接表 T_1、T_2、T_3...、T_n 的查询时，查询优化器会尝试排列它们，以便首先考虑搜索空间最小的表。此外，最终结果集将是可索引的（即搜索空间将是可收缩的），而组成表则不是（例如，您可能在 select 语句中连接字符串）
当您“索引”视图时，您所做的只是告诉 SQL Server 记住视图上索引的结构，以便将来它可以在其他类似的中使用它 em> 您创建的临时查询。
例如，作为一些大型复杂查询 (BCQ) 的一部分，您可能会在列 c1 和 c2 上连接字符串。这通常是一个相当大的搜索空间，但是对于索引视图，查询优化器会意识到它已经在 c1 + c2 形式的对象空间上拥有一个索引。此外，查询优化器可能能够将 BCQ 减少到一个或两个（或三个或...）视图。
【讨论】：