我熟悉 SQL Server 索引 View (或 Oracle 实体化 View )，我们在 OLAP 应用程序中使用它们。它们具有非常酷的功能，能够篡改执行计划并将其重新映射到索引 View ，而无需更改现有代码。
即。假设我有一个 SPROC，这是一个非常昂贵的连接。
SELECT [SOME COLUMNS]
FROM Table1 INNER JOIN Table2 [DETAILS]
INNER JOIN Table3 [BUNCH MORE JOINS] ...
如果我创建了一个包含类似结果集的索引 View ，那么查询优化器很可能会将 SPROC 发送到我的索引 View 而不是基表，这样我的性能就会大大提高。
现在说我想在 OLTP!? 中使用索引 View 并可能减少锁定争用(http://www.codinghorror.com/blog/archives/001166.html)。更好的是，您不必更改任何代码，只需编写索引 View 即可。
但这也意味着数据库会变大，因为我们需要在索引 View 中保留这些数据的副本...
有没有人使用过索引 View 来解决 OLTP 中的争用或速度问题？为什么我从未见过有人使用它？
最佳答案
物化 View 可用于针对 OLTP 进行报告，尤其是聚合大量行以获得结果时。空间要求完全取决于您保存的数据量。将其视为缓存。
棘手的平衡点在于报告需要多新的数据，以及您可以对 OLTP 性能造成多大的影响。如果有些陈旧的数据没有问题，您可以在系统事件较少的时候安排对 View 的更新。
有一次我做不到，而且需要非常最新的数据，所以我最终使用了一些定制开发。对基表的每次更新都会触发一个触发器，该触发器将一条记录写入事务表。该 View 查看缓存的聚合，以及存储在事务表中的增量。在系统资源允许的情况下，事务作为增量事务应用于聚合表。这让我获得了第二个数据，良好的报告性能(唯一发生的聚合是最近的事务)和相当小的数据库负载(每次写入的大小只加倍，而不是每次都重新计算一个巨大的聚合)。
不幸的是，它维护起来很复杂，而且没有使用简单的内置工具。如果您可以等待报告数据，通常最好使用内置的物化 View 并推迟刷新。
关于sql-server - OLTP 中的索引 View ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57406/