SQL Server存储固定长度130位SHA512密码哈希的最优数据类型选择

最优选择是 char(130)。

排除其他可选类型的原因 #

你关于“哈希值仅包含ASCII字符，使用nvarchar会造成存储空间浪费”的判断完全正确：SHA512哈希转成带0x前缀的十六进制字符串后，仅包含0-9、A-F和开头的0x标识，全是ASCII字符，用双字节存储的nvarchar系列会平白浪费一倍存储空间，完全没必要选。

• nvarchar(max)/nvarchar(130)：属于Unicode双字节类型，存130个字符需要占用260字节，是单字节类型的两倍，直接排除。
• 未指定长度的varchar：SQL Server中不写长度的varchar默认仅能存储1个字符，会直接导致哈希截断报错；就算指定长度为varchar(130)，也不是当前场景的最优解。
• 所有max类大字段类型：不管是varchar(max)还是nvarchar(max)，都是为超过8000字节的大文本/二进制块设计的，不仅有额外的存储指针开销，还会限制索引创建（比如无法作为唯一索引、主键的完整键值），完全不适合固定长度的哈希存储。

为什么char(130)是最优选择 #

• 它是单字节非Unicode类型，刚好匹配全ASCII的哈希内容，每个字符占1字节，总存储空间固定为130字节，无任何冗余。
• 这个哈希的长度是绝对固定的，你测试得到的130长度不存在任何波动：SHA512原始输出为512位二进制（共64字节），转成带0x前缀的十六进制字符串后，长度永远是2 + 64*2 = 130，没有任何长短变化，完全契合定长类型的使用场景。
• 对比可变长度的varchar(130)：varchar每行需要额外占用2字节存储实际数据长度，而对于永远满130长度的字段，定长char没有可变长度的额外开销，每行长度完全一致，读写性能略好，也不会出现页分裂问题。
• 如果未来有可能调整哈希算法导致字符串长度变化，可以退而求其次选varchar(130)，但当前固定长度场景下char(130)是最优解。

补充说明 #

如果你不需要保留哈希的字符串展示格式，也可以直接用binary(64)存储HASHBYTES返回的原始二进制值，存储空间更小（仅64字节），但这不属于你当前给出的可选类型范围。

内容的提问来源于stack exchange，提问作者Viktor Fursov