OLTP中的索引视图？

我熟悉SQL Server索引视图(或Oracle物化视图),我们在OLAP应用程序中使用它们.它们具有非常酷的功能,能够篡夺执行计划并将其重新映射到索引视图,而不必更改现有代码.

IE浏览器.假设我有一个非常昂贵的SPROC加入.

从表1中选择[某些列]
INNER JOIN表2 [DETAILS] INNER JOIN表3 [BUNCH MORE JOINS] ...

如果我创建了一个包含类似结果集的索引视图,那么查询优化器很可能会将SPROC发送到我的索引视图而不是基表,并且我的性能会有很大提升.

现在说我想在OLTP中使用索引视图!？我的意思是大多数OLTP(比如这个网站)相对阅读重,如果它们有昂贵的连接,那么我们可以加快它们的速度并可能减少锁定争用(http://www.codinghorror.com/blog/archives/001166.html).更好的是你不必更改任何代码,只需编写索引视图.

但这也意味着数据库变得更大,因为我们需要在索引视图中保留这些数据的副本...

有没有人曾使用索引视图来解决OLTP中的争用或速度问题？为什么我从来没有见过这个？

物化视图对于针对OLTP进行报告非常有用,尤其是聚合了大量行以获取结果.空间要求完全取决于您节省的数据量.将其视为缓存.

棘手的平衡是在报告的数据需求最近之间,以及您可以对OLTP性能的影响程度.如果有些过时的数据没问题,您可以在系统活动较少的时候安排对视图的更新.

有一次我不能,并且需要非常新的数据,我最终使用了一些自定义开发.对基表的每次更新都触发了一个触发器,该触发器将记录写入事务表.该视图查看了缓存聚合以及存储在事务表中的增量.在允许系统资源的情况下,事务作为增量事务应用于聚合表.这使我获得了第二个数据,报告的良好性能(发生的唯一聚合是最近的事务)和数据库上相当少的负载(每次写入的大小只增加一倍,而不是每次都重新计算一个巨大的聚合).

不幸的是,维护起来很复杂,并且没有使用简单的内置工具.如果您可以等待报告数据,通常最好使用内置的物化视图并推迟刷新.