我熟悉SQL Server索引视图（或Oracle物化视图），我们在OLAP应用程序中使用它们。它们具有非常酷的功能，能够篡夺执行计划并将其重新映射到索引视图，而不必更改现有代码。
IE。假设我有一个非常昂贵的SPROC加入。
选择[某些栏目]
FROM Table1 INNER JOIN Table2 [DETAILS]
INNER JOIN表3 [BUNCH MORE JOINS] ...
如果我创建了一个包含类似结果集的索引视图，那么查询优化器很可能会将SPROC发送到我的索引视图而不是基表，并且我的性能会有很大提升。
现在说我想在 OLTP中使用索引视图！？我的意思是大多数OLTP（比如这个网站）相对阅读重，如果它们有昂贵的连接，那么我们可以加快它们的速度并可能减少锁定争用（http://www.codinghorror.com/blog/archives/001166.html）。更好的是你不必更改任何代码，只需编写索引视图。
但这也意味着数据库变得更大，因为我们需要在索引视图中保留这些数据的副本......
有没有人曾使用索引视图来解决OLTP中的争用或速度问题？为什么我从来没有见过这个？
答案 0 :(得分：5)
物化视图对于针对OLTP进行报告非常有用，尤其是聚合了大量行以获取结果。空间要求完全取决于您节省的数据量。把它想象成一个缓存。
棘手的平衡是在报告的数据需求最近之间，以及您可以对OLTP性能的影响程度。如果有些过时的数据没问题，您可以在系统活动较少的时候安排对视图的更新。
有一次我不能，并且需要非常新的数据，我最终使用了一些自定义开发。对基表的每次更新都触发了一个触发器，该触发器将记录写入事务表。该视图查看了缓存聚合以及存储在事务表中的增量。在允许系统资源的情况下，事务作为增量事务应用于聚合表。这使我获得了第二个数据，报告的良好性能（发生的唯一聚合是最近的事务）和数据库上相当少的负载（每次写入的大小只增加一倍，而不是每次都重新计算一个巨大的聚合）。
不幸的是，维护起来很复杂，并且没有使用简单的内置工具。如果您可以等待报告数据，通常最好使用内置的物化视图并推迟刷新。
答案 1 :(得分：2)
我们使用物化视图来加速我工作的地方。最常见的是针对OLTP系统的报告。我们的许多报告都是从数据仓库运行的，但是由于我们一夜之间刷新仓库，直到数据必须来自OLTP表。