MySQL 密码存储字段选型：char与varchar的抉择，筑牢系统安全基石

看似简单的字段选型，为何成了面试 “拦路虎”

在后端开发岗位的 MySQL 专项面试中，“存储用户密码散列应使用 char 还是 varchar 字段” 是一道典型的区分度题目。许多开发者的第一反应是使用 varchar (255)，认为其具备足够的灵活性可适配各类场景，但当面试官追问 “散列算法的输出长度特性”“char 与 varchar 的底层存储差异” 时，多数人却无法给出专业且全面的回答，最终错失 offer。

在实际项目中，也存在大量开发者盲目使用 varchar 存储密码散列的情况，这一操作不仅会造成数据库存储空间的浪费，还会降低索引查询效率，甚至在后续切换密码散列算法时，因字段长度适配问题引发系统迁移故障，影响业务稳定性。

密码存储的底层逻辑与散列值特性

1. 密码存储的核心原则：优先存储散列值

在用户系统设计中，明文存储密码是绝对禁止的操作。明文密码一旦遭遇数据库泄露，用户账号安全将直接暴露，等同于将金库钥匙放置在金库门外。而通过 SHA-256、bcrypt、argon2 等散列算法处理后的密码散列值，具备不可逆性，即便数据泄露，攻击者也难以逆推原始密码，能有效保障用户信息安全。

2. 密码散列值的关键属性：定长输出

不同散列算法的输出长度具有明确的固定标准，不存在 “可变长度” 的情况：

MD5 算法输出 128 位，对应 32 个十六进制字符；
SHA-256 算法输出 256 位，对应 64 个十六进制字符；
bcrypt 算法（内置加盐）固定输出 60 个字符；
SHA-512 算法输出 512 位，对应 128 个十六进制字符。
这一特性为字段选型提供了核心依据，也决定了 char 字段在该场景下的适配性。

3. char 与 varchar 的底层存储差异

char：属于固定长度字符类型，不足指定长度时会自动填充空格，其存储结构规整，数据库在进行数据定位和索引查询时效率更高，适合存储长度固定的字符串；
varchar：属于可变长度字符类型，会额外存储字符长度信息，虽能节省部分存储空间，但在处理定长数据时，其存储结构的不规整性会降低查询效率，且存在存储空间浪费的潜在问题。

密码散列存储的专业字段设计方案

结合密码散列的定长特性与 MySQL 字段的存储逻辑，可根据不同业务场景制定针对性方案：

1. 基础场景方案：单一算法的精准适配

若项目明确使用某一固定散列算法，可直接匹配对应长度的 char 字段，实现性能与空间的最优平衡：

使用 SHA-256 算法：设置password_hash CHAR(64) NOT NULL；
使用 bcrypt 算法：设置password_hash CHAR(60) NOT NULL；
使用 SHA-512 算法：设置password_hash CHAR(128) NOT NULL。

2. 进阶安全方案：散列值与盐值的分离存储

为提升密码安全性，需在散列计算前为密码添加随机盐值，此时提议将盐值与散列值分开存储，保障数据管理的规范性，示例如下：

CREATE TABLE user_auth (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) NOT NULL UNIQUE,
    password_hash CHAR(64) NOT NULL,
    salt CHAR(16) NOT NULL,
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

该方案中，盐值采用 char (16) 存储，既能满足随机字符串的长度需求，也能保持与散列值字段的存储一致性。

3. 可扩展方案：适配算法迭代的字段设计

若思考未来切换更安全的散列算法（如从 SHA-256 升级为 argon2），可采用 “散列值 + 算法标识” 的组合设计，预留扩展空间：

CREATE TABLE user_auth (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) NOT NULL UNIQUE,
    password_hash VARCHAR(200) NOT NULL,
    algorithm VARCHAR(20) NOT NULL COMMENT '存储散列算法名称，如SHA-256、argon2',
    salt VARCHAR(50) NULL,
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);