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