如何使用类型2缓慢变化的维度索引表以获得最佳性能

Question

假设您有一个具有类型2缓慢变化维度的表。

让我们按如下方式表达此表，其中包含以下列：

* [Key]
* [Value1]
* ...
* [ValueN]
* [StartDate]
* [ExpiryDate]

在这个例子中，假设[StartDate]实际上是系统已知给定[Key]的值的日期。 所以我们的主键将由[StartDate]和[Key]组成。

当一组新值到达给定[Key]时，我们将[ExpiryDate]分配给某个预定义的高代理值，例如'12 / 31/9999'。 然后，我们为[Key]设置现有的“最新”记录，使[ExpiryDate]等于新值的[StartDate]。 基于连接的简单更新。

---

因此，如果我们一直希望获得给定[Key]的最新记录，我们知道我们可以创建一个聚簇索引：

* [ExpiryDate] ASC
* [Key] ASC

虽然键空间可能非常宽（例如，一百万个键），但我们可以通过[ExpiryDate]最初对它们进行排序来最小化读取之间的页数。 由于我们知道给定密钥的最新记录将始终具有[12/31/9999]的[ExpiryDate]，因此我们可以将其用于我们的优势。

但是......如果我们想在给定时间获得所有[Key] s的时间点快照怎么办？ 从理论上讲，整个键空间并非全部同时更新。 因此，对于给定的时间点，[StartDate]和[ExpiryDate]之间的窗口是可变的，因此[StartDate]或[ExpiryDate]的排序永远不会产生一个结果，其中您要查找的所有记录都是连续的。 当然，您可以立即丢弃[StartDate]大于您定义的时间点的所有记录。

---

从本质上讲，在典型的RDBMS中，什么索引策略提供了最佳方法来最小化读取次数以检索给定时间点的所有键的值？ 我意识到我可以通过[Key]对表进行分区来最小化IO，但这肯定不太理想。

或者，是否存在一种不同类型的缓慢变化的维度，以更高效的方式解决这个问题？

Answer 1

懒惰的DBA

您是否在谈论恢复维度表中的所有值？ 如果是这样，那么为什么不添加一个具有额外覆盖率的非聚集索引，以便您只从索引本身而不是从表中提取值？ 这样你就可以使用一些附加的“覆盖”值来扫描B树，而不是可能执行表扫描？ 我无法保证相对性能，但是值得测试你正在研究的场景。

干杯

Ozziemedes http://ozziemedes.blogspot.com/

Answer 2

如果这确实是一个“缓慢变化的维度”表，我会考虑一个聚簇列存储索引。 我知道当你问这个问题时这不可用，但无论如何。 你会在这里找到一些很棒的文档：“ https://msdn.microsoft.com/en-us/library/gg492088.aspx ”和这里“ http://www.nikoport.com/2013/07/05/clustered -columnstore-indexes-part-1-intro / “。

现在，如果你想坚持使用行存储索引，如果你按顺序在表中插入数据，那么我过去所做的就是利用一个标识字段。 您的查询将是这样的：

    declare @id;
    select @id = min(ID) from table where date = '12/31/9999';
    select fields from table where key = 112 and id > @id;