SQL Server哈希索引

好的,2分。
SQL校验和函数不生成哈希值。它实际上计算一个CRC值。它不是一个很好的基于哈希检查的候选者,因为会有相对大量的冲突。如果需要哈希函数,应该检查hash_bytes函数。
其次,您实际上并没有创建哈希索引。您正在哈希值上创建一个普通的B-树,因此查找时间将与相同大小数据类型上的任何其他B-树索引的查找时间完全相同。
有可能通过使用长varchar值的crc或hash来允许比较较小的字节数,从而获得一点性能,但是字符串比较只检查所需的字节数,最多检查不匹配的第一个字符,如果匹配哈希值,则需要加倍check实际值。因此,除非您有许多非常相似的字符串,否则最终可能会使用哈希(或CRC)比较更多的字节。

简而言之,我不认为这是一个明智的计划,但是就像所有的优化一样,你应该在特定的情况下测试它,然后再决定。如果你愿意邮寄的话,我想看看你的结果。我不相信有比使用聚集索引更快的方法来定位SQL Server中的行。

如果您愿意,Ingres(通过CA)可以创建散列索引,然后实现O(1)。可能还有其他RDBM也支持真正的哈希索引。

我认为SQL Server本机没有基于哈希表的索引。这个 BOL documentation 正在讨论根据计算值建立标准(树)索引。这和 Linear Hash Table 这是一些DBMS平台上可用的索引结构,但不是SQL Server(Afaik)。

使用中描述的技术可能会获得一些好处。 this blog post 散列大字符串值(如url)以加快查找速度。但是,底层索引仍然是一个树结构,是O(log n)。

您可以尝试设置事物以使用哈希联接,您可以查看执行计划以验证是否实际使用了哈希联接。使用哈希联接时,SQL Server仍将首先构建哈希表,作为执行单个查询的一部分。我相信索引永远不会存储为哈希,只存储为树。

一般来说,我不会创建一个人工散列,除非您对潜在的大型字符串或二进制blob进行精确匹配(如Pipthegeek提到的)。我只是想补充一下,有时这是必要的,因为字符串可能太大,无法放入索引键。我认为对于SQL Server,索引键的大小是有限制的。

当然,在您的连接中,您需要包含哈希列和源列,以解决哈希产生的任何模糊性。

如果ID字段是int,那么在ID字段上搜索索引校验和与聚集索引相比没有优势,因为两者都将执行聚集索引搜索。此外,int列的校验和总是返回与该列相同的值(即,校验和(535)=535)。但是,如果ID是长字符列,校验和查找通常会执行得更好。