Sql server OLTP中的索引视图？

我熟悉SQL Server索引视图（或Oracle物化视图），我们在OLAP应用程序中使用它们。它们有一个非常酷的特性，可以篡夺执行计划并将其重新映射到索引视图，而不必更改现有代码

比如说，我参加了一个非常昂贵的狂欢节

选择[某些列]
从表1内部连接表2[详细信息]
内部联接表3[多组联接]

如果我编写了一个包含类似结果集的索引视图，那么查询优化器很可能会将存储过程发送到我的索引视图，而不是基表，这样我的性能会大大提高

现在假设我想在OLTP！中使用索引视图我的意思是，大多数OLTP（如本站点）的读取量相对较大，如果它们有昂贵的连接，那么我们可以将它们的速度提高很多，并可能减少锁争用（）。更好的是，您不必更改任何代码，只需编写索引视图

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

---

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

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

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

在报告所需的数据更新时间和OLTP性能的影响之间，需要进行微妙的平衡。如果有点陈旧的数据还可以，您可以在系统活动较低的时候安排视图的更新

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

---

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

这些物化视图是在OLTP中创建的还是存储在其他位置？如果它们是在OLTP中创建的，它会如何影响数据库大小和性能。在放下物化视图之前，这些OLTP中是否有任何一个处于重载状态？它们在OLTP中。主要是因为将所有东西都推到网络上的DBLink甚至比将它们放在OLTP上更糟糕。它的使用越来越糟糕，这就是我们建造它们的原因。他们就位后情况好多了。