在MySQL中将十六进制值存储为二进制

Question

我在想我是如何在我的数据库中存储密码的:在CHAR(40)字段中适当加盐的SHA1字符串.但是,由于其中的字符数据实际上只是160位数的十六进制表示,我认为将它存储为BINARY(20)可能更好.

CREATE TABLE users (
    password BINARY(20)
    /* snip */
);

INSERT INTO users (password) VALUES (UNHEX(SHA1('mypassword'));

正如我所看到的,这种方法的一个好处是它将该区域的大小减半,但我可以想象也可能存在一些缺点.

你怎么看？

Answer 1

我们在数据库中使用二进制文件来存储大量不同的ID以节省空间,因为我们的大部分数据都包含这些ID.因为它似乎不需要节省空间(因为它只是密码,而不是其他大型项目),我认为没有任何理由在这里使用二进制文件.

我们遇到的最大问题是不断地,令人讨厌的是,在控制台中显示二进制数据(每次键入select*你都会听到一百万次哔声),你必须总是选择HEX()或插入UNHEX(),这是痛苦

最后,如果你混合和匹配(错误地)二进制和HEX/UNHEX并加入这个值,你可以匹配你从未想过的记录.

Answer 2

这是我的细分:

1. 如果使用字符串而不是二进制,请使用固定长度字段.由于散列算法都输出固定长度,你可以在那里节省一些空间.
2. 由于您只进行相等比较,因此不需要索引.二进制字段没有排序规则类型或字符集.
3. BINARY列类型没有像BLOB那样奇怪的存储警告.
4. 每个十六进制字符代表它消耗的8(或7)位中的4位.这意味着二进制存储的效率是其两倍.
5. 最重要的是:除非您在每个字节都很重要的嵌入式系统中工作,否则不要这样做.具有字符表示将允许您更好地调试.此外,每次开发人员正在处理这样的问题时,我都不知道为什么.像这样的每个架构决策都有权衡,这似乎不会为您的项目增加价值.
6. 您可以随后使用简单的SQL脚本转换为BINARY.

简而言之,使用固定长度的文本字段.在当前世界中计算字节没有任何好处,特别是在易于实现变化时.

希望这可以帮助.