MySQL 面试必问：存储用户密码，到底用 CHAR 还是 VARCHAR？
（答案确实出乎大多数人意料！2025~2026 年大厂面试中，这个题已经成了“经典陷阱题”）
大多数人张口就来：VARCHAR(255)（因为“密码可能很长”或“习惯用 varchar”）
面试官微微一笑：“错，推荐用 CHAR，而且长度要精确匹配你用的哈希算法！”
为什么答案出乎意料？（面试官最爱听的深度解释）
密码在数据库里从来不存明文，而是存哈希值（Hash）。
现代主流哈希算法输出的长度是完全固定的：
| 算法 | 输出长度（字符） | 推荐字段类型 | 说明 |
|---|---|---|---|
| MD5 | 32 | CHAR(32) | 老旧，不推荐（彩虹表攻击） |
| SHA-1 | 40 | CHAR(40) | 已不安全 |
| SHA-256 | 64 | CHAR(64) | 常用 |
| SHA-512 | 128 | CHAR(128) | 高安全 |
| bcrypt（最推荐） | 60 | CHAR(60) 或 BINARY(60) | 当前工业标准（带 salt + cost） |
| Argon2id | 通常 64~128 | CHAR(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 会 trim，VARCHAR 保留，但哈希里不会有空格）。
2026 年最推荐写法（直接背，面试无敌）
-- 最佳实践：使用 bcrypt（推荐！）
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(64) NOT NULL UNIQUE,
password CHAR(60) NOT NULL, -- bcrypt 固定 60 字符
email VARCHAR(255) NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
INDEX idx_username(username)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;更极致安全做法（面试加分）：
password BINARY(60) NOT NULL, -- 彻底二进制存储，避免 collation 问题
-- 或者
password CHAR(60) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,一句话总结（面试开场 15 秒版本）
“密码存的是哈希，不是明文。所有主流哈希算法输出长度固定，所以必须用 CHAR(精确长度)，而不是 VARCHAR(255)。这既节省空间（无长度前缀）、又提升索引和比较性能，还能避免变长字段的额外开销。很多人第一反应答 VARCHAR，就是因为没想过‘密码字段其实是定长’这个点。”
面试官追问概率极高：
- “不同算法长度不一样怎么办？” → 精确匹配，或统一用 CHAR(128) 兜底。
- “为什么不用 BINARY？” → 可以！BINARY(60) 更彻底，但 CHAR 更直观易读。
- “bcrypt 为什么 60 位？” → 格式是
$2b$10$...（2+2+2+53=59~60 字符）。
这个题背熟后，基本没人能难住你——因为 90% 的候选人都答错了，而你能说出“出乎意料”的正确答案。
需要我再给你：
- 完整 bcrypt + CHAR(60) 的 Java / Go / Node 插入示例
- 性能对比基准测试 SQL
- Argon2 / PBKDF2 的最新长度推荐
随时说～ 这题现在已经是 MySQL 密码安全专题的“杀手锏”了！
