MySQL面试必问：存储用户密码，char还是varchar？答案出乎意料！

大家好呀，我是小米，一个31岁依旧在代码世界里乐此不疲的技术“打怪升级者”。最近又遇到一位小伙伴吐槽：去面试MySQL相关岗位，面试官抛了一个看似“很小”的问题，结果他翻车了。问题是这样的：

“如果要存储用户的密码散列，应该使用什么字段进行存储？”

小伙伴一听，心想：这不就是 varchar 吗？我平时不都是这么写吗？于是胸有成竹地答道：varchar(255)。

结果面试官微微一笑，说：“能不能解释下，为什么是 varchar，为什么不是 char？散列长度你考虑过没？不同算法存储上有什么区别？”

小伙伴瞬间石化。

于是，他面试挂了，回头来找我诉苦。听完之后，我忍不住乐了：

这其实是一个面试官用来区分‘只会CRUD’和‘真正懂数据存储细节’的好问题。

今天，我就借着这个故事，带大家一起深入拆解这道题。保证你看完后，不仅能搞清楚存储密码散列的最佳实践，还能顺带复盘一堆关于MySQL字段设计的底层知识。

为什么密码要存储“散列值”？

先别急着讨论字段类型，我们得先弄清楚为什么要存储“密码散列”。

很多小伙伴做项目的时候，图省事，喜欢把用户密码直接存数据库，比如：

这就相当于把银行金库的钥匙，直接放在金库门口。只要库被拖走，所有用户的密码就等于裸奔。

正确做法：存储的是密码的 散列值（hash），例如通过 SHA-256、bcrypt、argon2 之类的算法处理后再入库。这样，即便数据库泄露，攻击者拿到的也是一堆“乱码”，想逆推出原始密码的难度极高。

所以，数据库中真正要存储的，不是 123456，而是像这样的一串散列：