MySQL 面试必问存储用户密码到底用 CHAR 还是 VARCHAR答案确实出乎大多数人意料2025~2026 年大厂面试中这个题已经成了“经典陷阱题”大多数人张口就来VARCHAR(255)因为“密码可能很长”或“习惯用 varchar”面试官微微一笑“错推荐用 CHAR而且长度要精确匹配你用的哈希算法”为什么答案出乎意料面试官最爱听的深度解释密码在数据库里从来不存明文而是存哈希值Hash。现代主流哈希算法输出的长度是完全固定的算法输出长度字符推荐字段类型说明MD532CHAR(32)老旧不推荐彩虹表攻击SHA-140CHAR(40)已不安全SHA-25664CHAR(64)常用SHA-512128CHAR(128)高安全bcrypt最推荐60CHAR(60)或BINARY(60)当前工业标准带 salt costArgon2id通常 64~128CHAR(128)最新内存硬哈希scrypt固定或可配CHAR(对应长度)-核心原因为什么必须用 CHAR 而不是 VARCHAR长度 100% 固定→ 所有值长度完全一样CHAR 是定长MySQL 直接分配固定空间不需要额外 1~2 字节存长度前缀VARCHAR 的 overhead。查询、索引、比较时更快固定宽度字段在行存储中对齐CPU 友好。性能实测差异面试官常追问在索引列上CHAR 比 VARCHAR 快约 10~20%尤其是高并发登录场景。VARCHAR 会多出长度字节 变长处理开销。空间上亿级用户表用 CHAR 反而更省无长度前缀。VARCHAR 的坑你写VARCHAR(255)实际每行多存 1~2 字节长度信息纯属浪费。容易被人误以为“密码长度可变”但哈希根本不变长。尾空格处理也不同CHAR 会 trimVARCHAR 保留但哈希里不会有空格。2026 年最推荐写法直接背面试无敌-- 最佳实践使用 bcrypt推荐CREATETABLEusers(idBIGINTPRIMARYKEYAUTO_INCREMENT,usernameVARCHAR(64)NOTNULLUNIQUE,passwordCHAR(60)NOTNULL,-- bcrypt 固定 60 字符emailVARCHAR(255)NOTNULL,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,INDEXidx_username(username))ENGINEInnoDBDEFAULTCHARSETutf8mb4COLLATEutf8mb4_unicode_ci;更极致安全做法面试加分passwordBINARY(60)NOTNULL,-- 彻底二进制存储避免 collation 问题-- 或者passwordCHAR(60)CHARACTERSETlatin1COLLATElatin1_binNOTNULL,一句话总结面试开场 15 秒版本“密码存的是哈希不是明文。所有主流哈希算法输出长度固定所以必须用 CHAR(精确长度)而不是 VARCHAR(255)。这既节省空间无长度前缀、又提升索引和比较性能还能避免变长字段的额外开销。很多人第一反应答 VARCHAR就是因为没想过‘密码字段其实是定长’这个点。”面试官追问概率极高“不同算法长度不一样怎么办” → 精确匹配或统一用 CHAR(128) 兜底。“为什么不用 BINARY” → 可以BINARY(60) 更彻底但 CHAR 更直观易读。“bcrypt 为什么 60 位” → 格式是$2b$10$...2225359~60 字符。这个题背熟后基本没人能难住你——因为 90% 的候选人都答错了而你能说出“出乎意料”的正确答案。需要我再给你完整 bcrypt CHAR(60) 的 Java / Go / Node 插入示例性能对比基准测试 SQLArgon2 / PBKDF2 的最新长度推荐随时说 这题现在已经是 MySQL 密码安全专题的“杀手锏”了