OLTP中的索引视图？

Question

我熟悉Server索引视图(或Oracle物化视图)，我们在OLAP应用程序中使用它们。它们有一个真正酷的特性，即能够篡夺执行计划，并将其重新映射到索引视图w/out，需要更改现有代码。

即。假设我有一个SPROC，这是一个非常昂贵的加入。

选择某些列

从Table1内部联接Table2详细信息

内部加入Table3束更多的连接..。

如果我编写了一个包含类似结果集的索引视图，那么查询优化器很可能会将SPROC发送到我的索引视图，而不是基表，这样我就可以获得很大的性能提升。

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

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

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

Answer 1

物化视图对于针对OLTP进行报告非常有用，尤其是为了获得结果而聚合了大量行。空间需求完全取决于您正在保存的数据。把它想象成一个缓存。

棘手的平衡是报告所需的最近数据，以及对OLTP性能有多大影响。如果有些陈旧的数据是可以的，您可以在系统活动较少的时候安排对视图的更新。

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

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

Answer 2

我们使用物化的视图来加快我工作的速度。通常用于针对OLTP系统的报告。我们的许多报告都是从数据仓库运行的，但是由于我们在一夜之间刷新了数据仓库，所以数据必须从OLTP表中获得。