我有一个要求是创建一个正在杀死处理器并花费很长时间运行的报告。SQL Server索引查看问题
我想我可以通过创建一个索引视图来显着提高速度，该视图可以将所有这些数据保存在一个地方，使查询/报告变得非常容易。这个观点不仅仅用于报告，因为我认为它会在数据层的很多领域受益。
索引视图可能会包含500万以上的记录，我似乎无法找到任何关于索引视图不再推荐的指导。我认为在SQL第一次启动时，这个大小的索引视图需要花费相当多的时间来构建，但是我希望在这之后维护它的代价将会很小。
有什么样的最佳实践指南，何时使用索引视图，何时不使用它们？在每次服务器重新启动后，视图会重建吗？还是将它保存在磁盘的某个位置？
无论何时对索引中的任何列进行更新，与索引视图关联的索引都会更新。
大量的更新很可能会损害您的收益。如果它主要是读取，那么它会正常工作。
索引视图的真正好处是当您的聚合实时计算过于昂贵时。
请参阅：Improving Performance with SQL Server 2008 Indexed Views：
索引视图可以提高查询以下列方式 性能：
- 聚合可以预先计算和存储在索引查询 过程中，尽量减少 昂贵的计算执行。
- 可以预先加入表格并存储结果数据集。
- 可以存储连接或聚合的组合。
查询优化器会考虑索引只 观点与平凡 费用查询。这避免了 在查询优化期间尝试匹配各种索引视图 成本 以上的情况，这比由 索引视图使用率实现的节省更多。索引视图是 很少用于查询，成本为 小于1。
应用从 落实索引视图 受益包括：
- 决策支持工作负载。数据集市。
- 数据仓库。
- 联机分析处理（OLAP）存储和来源。
- 数据挖掘工作负载。
从视图的查询类型和模式点 ，有益应用 可以表征为那些含有 ：
- 联接和大表的聚合。
- 重复的查询模式。
- 对相同或重叠的一组列进行重复聚合。
- 在相同的键上重复连接相同的表。
- 以上的组合。
我不知道任何关于索引视图大小的指导。它实际上是一个独立的表，每次更新它所依赖的基表时，它都会“自动”更新，所以我倾向于将它视为一个单独的表。
对于您在建立索引时的问题 - 它存储在磁盘上，与其他索引相同，因此在服务器重新启动期间不会重建（除了由于事务没有进行而发生的任何修复在重启之前完成）。
索引视图（又名物化视图）由SQL Server的每一个变化到基础表（一个或多个）之后保持。不用说，你不应该有一个流量表的索引视图。
对于您的问题，一个更好的解决办法是运行查询，并将其存储在自己的表，如：
select * into CachedReport from YourView
这会给你的索引视图的性能，同时可以当决定刷新它。例如，您可以通过每晚运行计划作业的select into查询来刷新它。
何时使用表或物化视图没有硬行数限制。 但是，作为指导，避免在易失性表上进行物化视图 - 负载可能会导致服务器死机。
首先，蒂莫西建议检查基础表上的索引，然后统计。您的查询优化工具可能因缺少/过期统计信息而处于完整状态。
如果这无助于性能检查，那么从视图中确实需要哪些数据，因为我的猜测是a）行数和b）行大小是将整个视图加载到临时表中并通过I/O争用来运行它。
发布缓慢的SQL和表defs – TFD 2010-02-09 11:31:19