sql-server – SQL Server哈希索引
发布时间：2020-12-12 08:26:42 所属栏目：MsSql教程 来源：网络整理
导读：当使用CHECKSUM列类型人工创建散列索引时,查找实际上是O(1)还是仍然是O(lg n),就像聚类索引一样？我有一个表,我将根据其ID列选择,我需要查找尽可能快,聚集索引是最快的可能选项吗？我正在寻找可以提供O(1)性能的东西. 解决方法 好的,2分. SQL CHECKSUM函数不
当使用CHECKSUM列类型人工创建散列索引时,查找实际上是O(1)还是仍然是O(lg n),就像聚类索引一样？我有一个表,我将根据其ID列选择,我需要查找尽可能快,聚集索引是最快的可能选项吗？我正在寻找可以提供O(1)性能的东西.
解决方法好的,2分.SQL CHECKSUM函数不产生哈希值.它实际上计算CRC值.基于哈希检查不是一个非常好的候选人,因为会有相对大量的碰撞.如果你想要哈希函数,你应该检查hash_bytes函数. 其次,您实际上并没有创建一个散列索引.您正在哈希值上创建一个正常的B树,因此查找时间将与类似大小的数据类型上的任何其他b-tree索引完全相同. 有一个机会,您可以通过使用一个长的varchar值的CRC或哈希来获得一点表现,以允许比较较少的字节数,但字符串比较只能检查尽可能多的字节,第一个不匹配的字符,如果您使用散列值匹配,则需要双重检查实际值.所以除非你有很多非常相似的字符串,否则可能会使用哈希(或CRC)来比较更多的字节. 简而言之,我不认为这是一个明智的计划,但是与所有优化一样,您应该在具体情况下对其进行测试,然后决定.如果您愿意发布,我将有兴趣查看您的结果.而且我不认为在SQL Server中找到一行比使用聚簇索引有更快的方法. 如果你关心,Ingres(通过CA)可以创建哈希索引,然后将O(1).可能还有其他RDBM也支持真正的哈希索引. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |