我需要创建一个杀死处理器并花费很长时间才能运行的报告。
我认为我可以通过创建索引视图来显着提高速度，该视图将所有这些数据保存在一个地方，使得查询/报告变得非常容易。这个观点不仅仅用于报告，因为我认为它将使数据层中的很多领域受益。
索引视图可能包含500万条+记录，我似乎无法找到关于在何时不再推荐索引视图的任何指导。我假设在SQL首次启动时，这个大小的索引视图需要相当长的时间来构建，但我希望在此之后维护它的成本将是最小的。
关于何时使用索引视图以及何时不使用它们，是否有任何最佳实践指南？在每次服务器重启后视图是否会重建，或者它是否存储在磁盘上的某个位置？
答案 0 :(得分：2)
只要对索引中的任何列进行更新，就会更新与索引视图关联的索引。
大量更新很可能会造成损失。如果它主要是读取，那么它将正常工作。
索引视图的真正好处是，如果您的聚合实时计算成本太高，无法实现。
请参阅：Improving Performance with SQL Server 2008 Indexed Views：
索引视图可以增加查询 通过以下方式表现：
- 聚合可以预先计算并存储在索引中以最小化 查询期间昂贵的计算 执行。
- 可以预先连接表格并存储结果数据集。
- 可以存储联接或聚合的组合。
查询优化器认为是索引的 只查看非常重要的查询 成本。这避免了这种情况 尝试匹配各种索引视图 在查询优化成本期间 超过了节省的成本 索引视图用法。索引视图是 很少用于查询费用 不到1个。
受益于的应用程序 索引视图的实现 包括：
- 决策支持工作量。
- 数据集市。
- 数据仓库。
- 在线分析处理（OLAP）商店和来源。
- 数据挖掘工作负载。
从查询类型和模式点 看来，受益的应用程序 可以表征为那些 含有：
- 加入和汇总大型表格。
- 重复查询模式。
- 对相同或重叠的列集重复聚合。
- 在相同的键上重复连接相同的表。
- 以上的组合。
答案 1 :(得分：1)
在对基础表进行每次更改后，SQL Server都会维护索引视图（也称为物化视图）。不用说，您不应该在具有流量的表上建立索引视图。
对于您的问题，更好的解决方案是运行查询并将其存储在自己的表中，如：
select * into CachedReport from YourView
这将为您提供索引视图的性能，同时您可以决定何时刷新它。例如，您可以通过每晚从预定作业运行select into查询来刷新它。
答案 2 :(得分：0)
我不知道有关索引视图大小的任何指导。它实际上是一个单独的表，每当它所依赖的基表被更新时，它就会被“自动”更新，所以我倾向于把它看作一个单独的表。
关于构建索引的问题 - 它存储在磁盘上，与其他索引相同，因此在服务器重启期间不会重建（除了由于事务未完成而发生的任何修复）在重新启动之前）。
答案 3 :(得分：0)
何时使用表格或物化视图没有硬行数限制。 但是，作为指导线避免对易失性表格进行物化视图 - 负载可能会导致服务器终止。
首先，Timothy建议检查基础表上的索引，然后检查统计数据。由于缺少/过时统计信息，您的查询优化工具可能只是在完整的轨道上。
如果这对性能没有帮助，请检查视图中真正需要哪些数据，因为我的猜测是a）行数和b）行大小是杀死服务器将整个视图加载到临时表和通过I / O争用运行它。