SQL Server哈希索引

当使用CHECKSUM列类型人为地创建哈希索引时,查找实际上是O(1)还是它仍然是O(lg n),就像它是聚簇索引一样？我有一个表,我将根据其ID列进行选择,我需要尽可能快地查找,因此聚簇索引是最快的选项吗？我正在寻找能提供O(1)性能的东西.

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

简而言之,我认为这不是一个合理的计划,但与所有优化一样,您应该在特定情况下对其进行测试,然后再做出决定.如果您愿意发布它们,我会很有兴趣看到您的结果.而且我不相信在SQL服务器中找到行的方法比使用聚簇索引更快.

如果你关心,Ingres(由CA)可以创建哈希索引,然后获得O(1).可能还有其他RDBM也支持真正的哈希索引.

我不认为SQL服务器本身有一个基于哈希表的索引.在BOL文档都在谈论一个计算值建立一个标准(树)指数.这与线性哈希表不同,后者是某些DBMS平台上可用的索引结构,但不是SQL Server(AFAIK).

使用此博客文章中描述的技术来散列大字符串值(例如URL)可以获得一些好处,以便更快地查找.但是,底层索引仍然是树结构,并且是O(Log N).