假设您有一个具有类型 2 缓慢变化维度的表。
让我们按如下方式表达此表，其中包含以下列:
* [Key]
* [Value1]
* ...
* [ValueN]
* [StartDate]
* [ExpiryDate]
在此示例中，让我们假设 [StartDate] 实际上是系统知道给定 [Key] 的值的日期。所以我们的主键将由 [StartDate] 和 [Key] 组成。
当给定 [Key] 的一组新值到达时，我们将 [ExpiryDate] 分配给某个预定义的高代理值，例如“12/31/9999”。然后，我们为该 [Key] 设置现有的“最新”记录，使其 [ExpiryDate] 等于新值的 [StartDate]。基于连接的简单更新。
因此，如果我们总是想获得给定 [Key] 的最新记录，我们知道我们可以创建一个聚集索引，即:
* [ExpiryDate] ASC
* [Key] ASC
尽管键空间可能非常宽(例如，一百万个键)，但我们可以通过最初按 [ExpiryDate] 对它们进行排序来最小化读取之间的页数。由于我们知道给定 key 的最新记录的 [ExpiryDate] 始终为“12/31/9999”，因此我们可以利用这一点。
但是……如果我们想在给定时间获得所有 [Key] 的时间点快照怎么办？从理论上讲，整个 key 空间不会同时更新。因此，对于给定的时间点，[StartDate] 和 [ExpiryDate] 之间的窗口是可变的，因此按 [StartDate] 或 [ExpiryDate] 排序永远不会产生您要查找的所有记录的结果连续的。当然，您可以立即丢弃 [StartDate] 大于您定义的时间点的所有记录。
本质上，在典型的 RDBMS 中，哪种索引策略提供了最大限度减少读取次数的最佳方法，以检索给定时间点的所有键的值？我意识到我至少可以通过按 [Key] 对表进行分区来最大化 IO，但这当然不是理想的。
或者，是否有不同类型的缓慢变化维度以更高效的方式解决这个问题？
最佳答案
懒惰的DBA
您是在谈论带回维度表中的所有值吗？如果是这样，那么为什么不添加一个具有额外覆盖范围的非聚集索引，以便您只从索引本身中提取值，而不是从表中提取值？这样你就可以扫描带有一些附加“覆盖”值的 B 树，而不是潜在地执行表扫描？我不能保证相对性能，但是对于您显然正在处理的场景进行测试是值得的。
干杯
奥齐梅德斯
http://ozziemedes.blogspot.com/
关于sql - 如何索引具有类型 2 缓慢变化维度的表以获得最佳性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2030121/