MySQL无内置带盐哈希函数，必须应用层生成RANDOM_BYTES(16)作盐、Base64编码后拼接密码并用SHA256哈希，盐与哈希须分开安全存储。
MD5() 和 SHA2() 本身不支持加盐，MySQL 没有内置“带盐哈希”函数。你不能靠单条 SQL 表达式安全地完成加盐哈希——必须拆解为多步，并严格控制盐值生成、拼接顺序和存储方式。
为什么不能直接用 MD5(CONCAT(password, salt)) 就完事？
能算出来，但不安全。原因包括：
- 盐值若固定或可预测（比如写死在 SQL 里），彩虹表攻击依然有效
- 盐值长度太短（如 4 字符）或字符集受限（仅数字），熵值不足
- 拼接位置单一（只后缀）且无分隔符，
'ab' + 'cde'和'abc' + 'de'可能碰撞 -
MD5()本身已不适用于密码场景，即使加盐也挡不住现代 GPU 暴力穷举
RANDOM_BYTES() 是生成盐值的唯一可靠 MySQL 原生方式
MySQL 5.6+ 提供 RANDOM_BYTES(n)，返回 n 字节加密安全随机二进制数据，比 UUID() 或 FLOOR(RAND()*1000) 强得多。
实操建议：
- 盐长至少 16 字节（
RANDOM_BYTES(16)），对应 Base64 编码后约 22–24 字符 - 存入数据库时用
VARBINARY(32)或CHAR(32)（十六进制）或TEXT（Base64）字段，别用VARCHAR隐式截断 - 不要用
HEX(RANDOM_BYTES(16))后再拼接——这会把二进制盐转成纯十六进制字符串，实际熵没变，但后续处理易出错；推荐先转 Base64 再拼
示例（生成并编码盐）：
SELECT TO_BASE64(RANDOM_BYTES(16)) AS salt;
封装加盐 SHA256 的最小安全 SQL 模式
MySQL 不允许在函数定义中调用 RANDOM_BYTES()（因其含副作用），所以无法写成纯 SQL 函数。但可在应用层或存储过程中组合使用：
- 注册时：先查出用户唯一标识（如 username），用它派生盐（如
SHA2(username, 256)截取前 16 字节），再拼接密码 → 这叫“pepper”，非真盐，仅防批量撞库，仍需配合独立盐 - 更推荐做法：应用层生成
RANDOM_BYTES(16)→ 转 Base64 → 拼接密码 → 计算SHA2(CONCAT(password, salt), 256)→ 分开存 hash 和 salt 字段 - 若硬要全在 MySQL 侧做（如迁移脚本），可用如下模式（注意：仅限一次性操作，不可用于登录验证）：
SET @salt = TO_BASE64(RANDOM_BYTES(16));
SET @pwd = 'myPass123';
SET @hash = SHA2(CONCAT(@pwd, @salt), 256);
INSERT INTO users (username, password_hash, salt) VALUES ('alice', @hash, @salt);验证密码时，千万别在 SQL 里拼接再哈希
常见错误写法：
SELECT * FROM users WHERE username = 'alice' AND password_hash = SHA2(CONCAT(?, salt), 256);
问题在于：CONCAT(?, salt) 中的 ? 是参数占位符，MySQL 不会在执行时把应用传入的明文密码和查出的 salt 拼起来再哈希——它根本不会执行这个表达式，会报错或逻辑错乱。
正确路径只有一条：
- 先按 username 查出
salt和password_hash - 在应用层用相同逻辑（
SHA2(CONCAT(input_pwd, db_salt), 256)）计算哈希 - 用恒定时间比较函数（如 Python 的
hmac.compare_digest()）比对结果
MySQL 层面无法安全完成端到端加盐验证——这是设计限制，不是技巧问题。
最易被忽略的一点：盐值必须与哈希值一起持久化，且每次注册都用全新盐；重复使用同一盐值，等于没加。而 RANDOM_BYTES() 的调用时机、编码方式、字段类型，三者任一出错，都会让整个加盐失效。
