SQL Server索引视图问题

Question

我有一个需求需要创建一份报告，但这个报告会占用大量处理器资源并且运行时间很长。

我认为可以通过创建索引视图来显著提高速度，将所有数据放在一个地方，使查询/报告变得更加容易。这个视图不仅仅用于报告，因为我认为它还可以在数据层的许多领域中受益。

索引视图可能包含500万条以上的记录，我找不到任何指导，说明何时不再推荐使用索引视图。我认为这样大小的索引视图在SQL首次启动时构建需要相当长的时间，但我希望在此之后维护它的成本会很小。

是否有任何关于何时使用索引视图和何时不使用它们的最佳实践指南？视图会在每次服务器重启后重新构建吗？还是存储在磁盘的某个地方？

- Gavin

---

发布慢 SQL 和表定义。 - TFD

Answer 1

与您的索引视图相关联的索引将在索引中的任何列进行更新时进行更新。

大量更新很可能会破坏受益。如果主要是读取，那么它的工作就很好。

索引视图的真正好处在于当您拥有的聚合太昂贵而无法实时计算时。

请参阅：使用SQL Server 2008索引视图提高性能：

索引视图可以通过以下方式提高查询性能：

• 聚合可以预先计算并存储在索引中，以最小化在查询执行期间的昂贵计算。
• 表可以预连接并存储结果数据集。
• 可以存储连接或聚合的组合。

查询优化器仅在具有非平凡成本的查询中考虑索引视图。这避免了在查询优化期间尝试匹配各种索引视图导致的成本超过索引视图使用所实现的节省的情况。索引视图很少用于成本低于1的查询。

受益于实施索引视图的应用程序包括：

• 决策支持工作负载。
• 数据集市。
• 数据仓库。
• 在线分析处理（OLAP）存储和源。
• 数据挖掘工作负载。

从查询类型和模式的角度来看，受益应用程序可以被描述为包含以下内容：

• 大型表的连接和聚合。
• 重复查询模式。
• 在相同或重叠列集上重复进行聚合。
• 在相同键上多次连接同一张表。
• 上述组合。

- Mitch Wheat

Answer 2

索引视图（又称物化视图）在每次对基础表进行更改后由SQL Server维护。不用说，您不应该在具有流量的表上拥有索引视图。

对于您的问题，更好的解决方案是运行查询并将其存储在自己的表中，例如：

select * into CachedReport from YourView

这将为您提供索引视图的性能，同时您可以决定何时刷新它。例如，您可以通过每晚从计划作业运行select into查询来刷新它。

- Andomar

---

在500万条以上的记录上这样做是一个糟糕的想法。 - Timothy Khouri

为什么这是个不好的想法呢？我曾在更大的表格上（100M+行）使用过这种技术，效果非常好。它肯定比每次更新基础表时重建一个5,000,000行索引视图要好 :) - Andomar

在这种情况下，数据需要实时更新，因此我认为索引视图是最好的选择。 - Gavin

将所需的列和行插入一个未定义索引的空表非常快。这基本上是查询优化器使用tempdb的方式。因此，建立一个临时表，在需要时添加索引（不应该需要），然后进行报告。如果报告可以缓存，则可以将此表保留为缓存一段时间。 - TFD

Answer 3

我不知道关于索引视图大小的任何指导方针。它实际上是一个“自动更新”的单独表，每当其依赖的基本表被更新时，它就会被更新，因此我倾向于将其视为单独的表。

至于您关于索引构建的问题 - 它存储在磁盘上，与其他索引一样，因此它不会在服务器重新启动时重新构建（除了由于事务在重新启动之前未完成而进行的任何修复）。

- Damien_The_Unbeliever

Answer 4

在何时使用表格或物化视图时没有硬性的行数限制。 然而，作为一个指南，避免在易变表上使用物化视图-负载可能会使您的服务器崩溃。

首先像Timothy建议的那样检查基础表上的索引，然后是统计信息。由于缺失/过期的统计信息，您的查询优化器可能只是完全跟踪。

如果这不能提升性能，请检查实际上从视图中需要什么数据，因为我猜测a）行数和b）行大小是导致您的服务器负载整个视图到临时表并通过I/O争用运行的原因。

- KMB