使用哈希码帮助数据库是一种好习惯

时间:2014-11-28 08:34:45

标签: sql-server indexing varchar

我只是设计一个带有电子邮件地址的数据库(用于取消订阅选项)。因为IMHO索引一个更大的varchar字段并不是一个好主意所以我正在考虑创建一个int hashcode字段,用电子邮件地址的哈希码填充它并在这个字段上创建索引而不是直接在email字段中创建索引。这样,数据库中的查找将如下所示:

SELECT TOP 1 NULL FROM tbUnsub WHERE emailhash=-5421215 AND emailaddress='just.a@sample.com'

问题是,如果它需要更少的数据(因为在较大的varchar字段上缺少索引),并且由于在int字段中搜索它将更快地工作。

提前感谢您的帮助!

2 个答案:

答案 0 :(得分:0)

所以,经过短暂的测试后:

数据存储 - 如果数据库中有近1000000条记录:

没有哈希字段的表:31.641MB数据,36.742 MB索引 - 一起68,383 MB 带有哈希字段的表:35.367 MB数据,16.859 MB索引 - 一起52,226 MB

因此,即使你必须为另外一个字段存储数据,它也需要更少的存储空间,因为int字段索引所需的空间更少。

在数据库中搜索时的效果

如果您主要关注现有或未存在的记录,则存在很大差异:

0现有,2000不存在:18.678 s没有哈希, 6.620 s有哈希

1000现有,1000不存在:10.815 s无哈希,5.054 s哈希

2000现有,0不存在: 1.782 s无哈希,2.909 s哈希

因此,如果您正在寻找大多数现有记录,那么您最好的选择是内置的,不要花时间玩哈希。如果您主要查看数据库中没有的数据,那么它可以是一个选项。

只是一个有趣的事情:在数据库中直接查看sql中的哈希值更快,并检查本地应用程序中的电子邮件地址是否相等(时间:2.286,1.972,2.070)

答案 1 :(得分:0)

一般来说,这不是一个好主意,因为哈希不能保证是唯一的。因此,如果仅通过哈希值查询,则存在选择多个条目或错误条目的风险。有关简短说明,请参阅this question。您有50%的可能性在大约54,000条记录(对于整数键)复制密钥,这可能是一个令人惊讶的低数字。