MD5不适合真正脱敏，仅用于低安全校验；生产环境必须用SHA2(str, 256)，因其抗碰撞强、输出64字符十六进制，但不可用于密码字段，且哈希值无法索引或JOIN，需配合trim、统一编码等输入一致性控制。
MD5 不适合做真正的数据脱敏，仅可用于低安全要求的校验或统计场景；生产环境必须改用 SHA2()，且严禁用于密码字段。
为什么不能直接用 MD5() 做脱敏
它输出 32 位小写十六进制字符串，碰撞概率虽低但可被暴力破解或查彩虹表反推——手机号、邮箱、身份证号等低熵值输入，几秒内就能还原。金融、政务类系统明确禁止使用。
-
MD5()不加盐、无随机性，相同输入永远产出相同哈希，等于给攻击者提供了稳定字典 - MySQL 的
MD5()对NULL返回NULL，而空字符串''会生成固定哈希'd41d8cd98f00b204e9800998ecf8427e'，混用会导致脱敏结果不一致 - 字段含前导/尾随空格时，
MD5('13812345678 ')≠MD5('13812345678')，业务侧若未统一 trim，比对永远失败
SHA2() 替代 MD5() 的实操要点
优先用 SHA2(str, 256)，返回 64 字符十六进制字符串，抗碰撞性强得多。但注意它不是“更安全的 MD5”，而是换用合规基线。
- 存储字段类型必须是
VARCHAR(64)或CHAR(64)，不能用BINARY(32)——SHA2()默认输出文本，不是二进制 - 别在
WHERE条件里对哈希列做函数运算：WHERE SHA2(phone, 256) = 'xxx'会强制全表扫描；应先算好哈希再查原始值 - 手机号脱敏建议组合使用：
CONCAT('138****', SUBSTR(SHA2(phone, 256), -4))，既保留可读性，又避免哈希值直接暴露 - 身份证号慎用纯哈希：末位
X大小写敏感，SHA2('110101199003072XXX', 256)和SHA2('110101199003072xxx', 256)结果不同
视图封装脱敏逻辑时的关键限制
用视图统一管理脱敏规则是对的，但 MySQL 视图不允许非确定性函数，否则创建会报错 ERROR 1356。
- 视图定义中禁用：
CURRENT_USER()、NOW()、RAND()、MD5()（虽然它确定，但官方文档明确列为禁止项） - 允许用：
SHA2()、CONCAT()、SUBSTR()、LEFT()等确定性函数 - 正确示例：
CREATE VIEW user_masked AS SELECT id, name, CONCAT(LEFT(phone,3),'****',RIGHT(phone,4)) AS phone_mask FROM users; - 错误示例：
CREATE VIEW user_admin AS SELECT *, IF(CURRENT_USER()='admin', phone, SHA2(phone,256)) FROM users;—— 直接失败
哈希值无法用于索引和 JOIN 的硬伤
无论 MD5() 还是 SHA2()，只要字段参与函数计算，就自动脱离索引能力。这是最容易被忽略的性能雷区。
- 想按脱敏后手机号查用户？别建
INDEX ON SHA2(phone,256)—— MySQL 不支持函数索引（8.0.13+ 才有函数索引，且仅限确定性函数 + 表达式索引，SHA2()被排除） - 需要关联脱敏表？必须保留原始字段并控制权限，用原始
phone做JOIN，脱敏列只作展示 - 高频检索场景下，
WHERE phone LIKE '138%'可走索引；但WHERE SHA2(phone,256) = 'xxx'必然触发全表扫描
真正难的不是调用函数，而是确保输入完全一致：是否 trim、如何处理 NULL、字段编码是否 UTF8、大小写是否统一。漏掉任意一环，两次哈希就对不上——这在跨库同步、ETL 校验时会直接导致数据不一致。
