SQL Server 中的 Hashset 等效项答案

【问题标题】：Hashset equivalent in SQL ServerSQL Server 中的 Hashset 等效项
【发布时间】：2012-04-04 18:02:26
【问题描述】：

我想创建一个始终由唯一键访问的大表（大约 450 亿行）。

在 DB 之外，保存它的最佳结构是 Dictionary 或 HashSet，但当然由于数据的大小，不可能在数据库之外执行此操作。

SQL Server 是否提供针对键值访问优化的结构？我知道聚集键非常快，但它仍然是一个索引，因此会有一些与遍历索引页相关的额外磁盘读取。我想从 SQL Server 获得的是一种“本机”结构，它将数据存储为键值对，然后可以根据键访问值。

换句话说，我的问题是如何在 SQL Server 中存储 450 亿行并在没有索引的情况下有效地访问它们，无论是集群还是非集群，因为读取索引非叶页可能会导致大量 IO，并且由于每个值都可以通过唯一的键访问，应该可以有一个结构，其中键的哈希解析为值的物理位置。要获得 1 个值，我们需要进行 1 次读取（除非存在哈希冲突）。

（Oracle 中的等价物是 Hash Cluster）

感谢您的帮助。

【问题讨论】：

标签： sql sql-server hash cluster-computing hashset

【解决方案1】：

在 SQL Server 中没有这样的东西。您唯一的选择是索引。如果要请求给定键的所有列，则应使用聚集索引。如果您只请求一个子集，则应使用非聚集索引，仅包含您想要的列，如下所示：

  create index IX_MyBigTable on MyBigTable(keyColumn) include (col1, col2, col3youneed);

这将非常有效。

【讨论】：

遍历 b 树的效率可能并不比生成哈希值低多少，聚集索引在 SQL Server 中如此重要的原因是数据行存储在叶级别。因此，命中索引键的 b 树叶的读取也会读取该键的数据行
这个答案是正确的。中间索引级别将很小并且完全缓存。基本上，任何通过 PK 进入此类表的操作都最多需要一个 IO。与使用磁盘上的哈希表相比，您甚至可以从关键位置中受益。
随机建议——如果你真的、真的、100% 只做键值查找，而不是任何类型的关系查询，也许 SQL 不是你的答案？看看 Redis - 它速度快、事务性、一致、持久到磁盘、易于设置 - 听起来它可能更合适。 redis.io
感谢您的所有反馈。我将首先使用集群 PK 进行更多测试。

【解决方案2】：

根据我的基准，最好的方法是为键创建一个哈希列。 Details.

【讨论】：