我熟悉SQL Server索引视图(或者Oracle物化视图)，我们在OLAP应用程序中使用它们。它们具有很酷的功能，即能够篡改执行计划并将其重新映射到索引视图，而无需更改现有代码。

IE。假设我有一个SPROC，这是一个非常昂贵的联接。

SELECT [SOME COLUMNS]

  FROM Table1 INNER JOIN Table2 [DETAILS]

  INNER JOIN Table3 [BUNCH MORE JOINS]
  ...

如果我创建了一个拥有相似结果集的索引视图，那么查询优化器很可能会将SPROC发送到我的索引视图(而不是基表)，并且性能会大大提高。

现在说我想在OLTP中使用索引视图！我的意思是大多数OLTP(如本站点)的阅读量相对较大，如果它们具有昂贵的连接，那么我们可以加快它们的速度，并有可能减少锁定争用(http://www.codinghorror.com/blog/archives/001166.html )。更好的是，我们无需更改任何代码，只需编写索引视图即可。

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

有没有人曾经使用索引视图来解决OLTP中的争用或者速度问题？我怎么从未见过这种用法呢？

解决方案

回答

我们使用物化视图来加快我工作的速度。最常用于针对OLTP系统的报告。我们的许多报告都是从数据仓库运行的，但是由于我们是在一夜之间刷新仓库的，因此直到数据必须来自OLTP表。

回答

物化视图对于根据OLTP进行报告很有用，特别是聚集了大量行以获取结果时。空间需求完全取决于要保存多少数据。将其视为缓存。

棘手的平衡是在报告中需要多长时间使用数据以及我们对OLTP性能的影响如何。如果有些陈旧的数据还可以，则可以在系统活动较少的时间内安排对视图的更新。

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

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