优先用 SHA2(phone, 256) 而非 MD5 做不可逆脱敏，禁用裸哈希密码字段；视图统一封装脱敏逻辑但不可含非确定性函数；正则替换慎用且导致索引失效；动态脱敏应交由中间层或专业工具链处理。
用 MD5() 或 SHA2() 做不可逆脱敏，但别碰密码字段
直接哈希敏感字段（比如手机号、身份证号）是最轻量的脱敏方式，适合只做统计或比对、不需还原的场景。但MD5() 碰撞风险高，生产环境优先用 SHA2(phone, 256)；注意它返回的是十六进制字符串，长度固定（64 字符），别拿它和原始字段做等值 JOIN——类型和长度都不匹配。
常见错误：把 MD5(id_card) 当作唯一标识用，结果不同身份证号哈希后偶然相同（虽概率低，但金融类系统必须规避）；还有人给密码字段也套 SHA2()，这等于放弃合规要求的加盐哈希流程，属于严重误用。
- 身份证号脱敏示例：
SELECT name, SHA2(id_card, 256) AS id_card_mask FROM users; - 手机号可截取+哈希组合：
CONCAT('138****', SUBSTR(SHA2(phone, 256), -4))，兼顾可读与不可逆 - 禁止对密码列使用任何裸哈希函数，必须走专用加密流程（如
bcrypt+ 盐）
用视图封装脱敏逻辑，避免应用层硬编码
把脱敏规则写死在应用 SQL 里，等于把策略散落在各处，改一个手机号格式就得翻十几处代码。用视图统一收口，既隔离变化，又让下游查询保持简洁。
关键点在于：视图定义里不能依赖会话变量或用户上下文（比如 CURRENT_USER()），否则权限控制会失控；另外，MySQL 视图不支持参数，所以“按角色显示不同精度”这种需求得靠应用层拼 SQL 或用存储过程兜底。
- 基础脱敏视图示例：
CREATE VIEW user_safe AS SELECT id, name, CONCAT(LEFT(phone,3),'****',RIGHT(phone,4)) AS phone, '***' AS email FROM users;
- 别在视图里用
IF(CURRENT_USER() = 'admin', phone, CONCAT(...))—— MySQL 不允许在视图中使用非确定性函数 - 视图查询性能取决于底层表索引，脱敏字段（如
CONCAT()结果）无法走索引，高频检索字段仍要保留原始列并控制访问权限
REPLACE() 和正则替换（REGEXP_REPLACE()）适用边界很窄
MySQL 8.0+ 才有 REGEXP_REPLACE()，5.7 只能靠嵌套 REPLACE() 拼凑，维护成本高且易出错。它适合固定格式字段（如银行卡号每 4 位加空格），但遇到身份证号末位 X、手机号带括号或分隔符时，规则立刻变脆弱。
更麻烦的是：这些字符串函数在 WHERE 条件中使用会导致全表扫描——比如 WHERE REGEXP_REPLACE(phone, '[0-9]', '*') = '138****1234'，永远无法命中 phone 列上的索引。
- 简单掩码可用：
REPLACE(REPLACE(phone, SUBSTR(phone,4,4), '****'), '-', '')，但仅限格式绝对规范的场景 - 身份证脱敏慎用正则：末位可能是 X，
[0-9]{17}[0-9X]这种模式在REGEXP_REPLACE()中需转义，容易漏掉大小写处理 - 只要 WHERE 里出现脱敏函数，就默认放弃该字段的索引能力，查千万级表时延迟会跳变
真正需要动态脱敏？别硬扛，换专业工具链
当需求变成“同一张表，DBA 看全量，业务员只能看本部门数据+手机号打码”，MySQL 原生能力就到头了。视图做不到行级+列级混合策略，权限系统也不支持字段级条件表达式。
这时候硬加存储过程或触发器，只会让数据库变重、慢、难审计。真实项目里更常见的解法是：在中间层（如 ProxySQL、ShardingSphere-JDBC）做 SQL 改写，或者用 Apache Ranger 这类平台统管脱敏策略。
最容易被忽略的一点：脱敏不是加一层函数就完事。日志、备份、从库、ETL 导出文件——所有数据出口都得同步覆盖，否则脱敏形同虚设。而这些环节，MySQL 自己根本管不了。
