SQL Server中的Hashset相当于

我想创建一个总是由唯一键访问的大型表（大约450亿行）。SQL Server中的Hashset相当于

在数据库之外，最好的结构是一个Dictionary或一个HashSet，但是当然由于数据的大小，在数据库之外不可能这样做。

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

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

（在Oracle中相当于散列簇）

感谢您的帮助。

来源

2012-04-04 user1044169

没有这样的事情在SQL服务器。你唯一的选择是索引。如果您打算请求给定键的所有列，则应使用聚集索引。如果你只打算被请求的一个子集，你应该使用一个非聚集索引只包括你想要这样的列：

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

这将是非常有效的。

来源

2012-04-04 18:06:34

遍历一个b-tree的效率可能不如生成一个散列值那么有效，并且在SQL Server中聚簇索引非常重要的原因是数据行存储在叶级别。因此，为您的索引键命中b树叶的读取也读取该键的数据行 – Rick 2012-04-04 18:17:51

此答案正确。中间索引级别将很小并且完全缓存。基本上，任何通过PK进入这样的表格最多只需要一个IO。与使用磁盘哈希表相比，您甚至可以从关键位置获益。 – usr 2012-04-04 20:34:00

随机推荐 - 如果你真的真的100％只做键值查找，而不是任何类型的关系查询，也许SQL不是你的答案？查看Redis - 它不可思议的快速，事务性，一致性，磁盘持久性，易于设置 - 听起来似乎更适合。 http://redis.io – 2012-04-04 20:46:02

根据我的基准，最好的方法是为密钥创建哈希列。 Details。

来源

2013-01-29 11:09:46 user2019014

SQL Server中的Hashset相当于

回答

相关问题