MySQL面试必问：存储用户密码，char还是varc...

大家好，最近有个朋友面试MySQL的岗位，被问了一个看似很简单的问题，结果直接翻车。面试官问他：如果要存储用户的密码散列，你会用什么字段？朋友脱口而出："varchar"。没想到面试官微微一笑，追问：为什么是varchar？为什么不是char？你考虑过不同散列算法的长度吗？朋友当场就愣住了。

其实这个问题看似小儿科，背后却藏着很深的门道。我们平时设计用户表，密码绝对不能明文存储，而是要存储散列值。什么意思？比如用户的密码是123456，直接存到数据库里，一旦被拖库，所有人的账户就等于裸奔。

正确的做法是用算法把它散列成一串看似乱码的字符串，比如SHA-256之后会得到六十四个字符，这样即使泄露出去，黑客也很难反推出原始密码。

那问题来了，散列值到底要多长？不同算法其实有固定的输出，像MD5是三十二个字符，SHA-256是四十个，SHA-256是六十四个，SHA-512是一百二十八个，bcrypt固定六十个，而argon2通常在九十五个左右。

换句话说，这些都是定长的，不需要随便给一个varchar那么大。这时候选择char还是varchar就很关键了，char是定长字段，查询更快，空间更紧凑，非常适合存储这种定长散列。varchar是可变长的，如果用来存散列其实有点浪费。

举个例子，如果你项目里用了SHA-256，最合理的字段就是char。如果你未来可能升级算法，那可以选择char或者varchar，给自己留点扩展空间。

除此之外，还得考虑安全里一个重要的概念，就是加盐。所谓的盐就是在密码前后拼接一段随机字符串，再去散列。这样就算两个用户用了一样的密码，散列结果也完全不同，大大增加了破解难度。

那盐存哪？答案是盐也要存在数据库里，一般跟散列分开保存。常见做法是一个字段存散列，另一个字段存盐。我自己当年也踩过坑，第一次写用户表的时候，直接上了varchar，结果用户量一大，问题就出来了，索引效率下降，空间浪费。后来想换算法还得改表结构，真是麻烦得要命。从那之后我再也不乱写varchar了，而是严格根据算法来定长度。