每个哈希值20个字节（假设为二进制存储）真的太多了吗？如果你目前使用十六进制编码，切换到二进制可以节省20个字节。Base64比十六进制节省大约10个字节。
如果你只是简单地截断一个加密哈希，它仍然是一个好的加密哈希，但是减少了输出大小。你需要什么样的输出大小取决于你的应用程序。
针对随机变化的完整性检查可以使用32-64位的短得多的散列，并且不需要加密散列函数。
如果你需要唯一性，你应该在你的散列中有>>2*log_2(entries)位（参见birthday paradox）。在120位左右，它类似于GUID/UUID（GUID有一个基于sha1的生成模式）
如果你想要加密强度，我会避免低于128位。

不，SHA-1散列的定义是160位，我强烈怀疑散列的大小会是个问题;我想你的数据库里还有其他的数据吧？很可能，你会发现数据的其他部分对数据库大小的贡献更大。你希望这些哈希值有多少行？
然而，将哈希存储为字符串（这将占用至少40个字节，具体取决于字符串编码）和将其存储为二进制数据（这将占用20个字节）之间存在大小差异。
正如其他人所指出的，您可以切换到另一种算法，但从安全Angular 来看，这可能不是一个好选择-散列算法的输出长度越短，它就越弱。

如果你减少它，它就不再是SHA1：）。你必须想一个不同的算法

要在MySQL数据库中存储SHA1哈希，我们需要一个CHAR(40)。

尺寸缩小

但是，我们可以通过选择BASE64编码将大小减少27%。列类型将是CHAR(29)。
示例：
SHA1-〉摘要十六进制-〉40个字符：5d41402abc4b2a76b9719d911017c575
SHA1-〉摘要基64-〉29个字符：XUFAKrxLKna5cZ2REBfFdQ==

性能提升

为了保证在读取（尤其是使用PRIMARY、INDEX、UNIQUE ...或使用JOIN）时**更高的性能，BINARY（20）更合适。
有必要使用十六进制形式的散列（a-z/0 - 9），并在插入过程中应用MySQL的UNHEX（）函数。

INSERT INTO my_table (
    id, 
    my_hash
) VALUES (
    1, 
    UNHEX('5d41402abc4b2a76b9719d911017c575')
);

它也可以用X'...'的简短语法编写，如下所示：

INSERT INTO my_table (
    id, 
    my_hash
) VALUES (
    1, 
    X'5d41402abc4b2a76b9719d911017c575'
);