MySQL存储密码哈希：选TEXT还是调哈希长度？解决VARCHAR超限问题

嗨，我来给你拆解下这个密码哈希存储的问题，几个实用方案供你参考：

首先你得知道，MySQL里VARCHAR的65535字符上限是没错的，但你之前的字段只设了255字符，这才是问题所在。你需要存的加密后哈希是512字符、盐是344字符，完全在VARCHAR的支持范围内。

你可以直接修改字段类型：

• 如果哈希和盐的长度是固定的（比如加密后总是512和344字符），用CHAR(512)（哈希字段）和CHAR(344)（盐字段）更合适，固定长度类型在匹配查询时性能略优。
• 要是担心后续加密规则调整导致长度变化，直接设成VARCHAR(1024)（留足余量）就好，完全不用担心超出上限。

如果不想纠结长度设置，TEXT类型是个省心的选择。MySQL的基础TEXT类型就能存65535字符，完全覆盖你的需求。虽然有人说TEXT在查询性能上略逊于VARCHAR/CHAR，但对于密码哈希这种“存一次、偶尔查一次匹配”的场景，性能差异几乎可以忽略不计，用起来非常方便。

除非有极其特殊的业务限制，否则绝对不建议修改pbkdfSync的输出长度。哈希算法的输出长度直接关联安全性，缩短长度会降低抗碰撞能力，给密码存储带来安全隐患。加上你还要对哈希和盐做二次加密，缩短输出只会让风险更高，这个方案直接pass掉。

总结建议 #

优先选方案1，根据哈希和盐的固定长度设置对应CHAR类型，或者用带余量的VARCHAR，兼顾性能和灵活性；如果嫌麻烦，方案2的TEXT类型也完全没问题，不用纠结细节就能搞定。

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