不能只靠REPLACE做脱敏，因其不识别语义、不校验长度、不区分上下文，易致格式错误、乱码或SQL注入；应优先用SUBSTRING+CONCAT组合并加长度校验与正则防护。
直接用 REPLACE 和 SUBSTRING 写存储过程做脱敏，性能高但极易出错——它只适合静态、格式高度统一的字段（如11位手机号、18位身份证），且无法逆向还原，也不防SQL注入式绕过。
为什么不能只靠 REPLACE 做脱敏
REPLACE 是纯字符串替换函数，不识别语义、不校验长度、不区分上下文。比如对身份证字段执行 REPLACE(id_card, SUBSTRING(id_card, 5, 8), '********')，一旦某条数据是15位旧证或含字母校验码，就可能切错位置，导致脱敏后变成 1101**X777 这类非法格式，后续业务解析直接报错。
常见错误现象：
- 脱敏后字段长度突变（如原11位手机号变成12位）
- 正则未覆盖边界情况（如带括号或空格的手机号
138-1234-5678） - 多字节字符被截断（如中文姓名用
SUBSTRING按字节切，出现乱码）
SUBSTRING + CONCAT 组合更可控
比起盲目 REPLACE，显式控制起始/结束位置的拼接方式更可靠，尤其适合掩码类脱敏。MySQL 中推荐写法：
CONCAT(LEFT(mobile, 3), '****', RIGHT(mobile, 4))
该写法隐含了长度校验逻辑：若 mobile 不足11位，RIGHT(mobile, 4) 会返回全部剩余字符，不会报错，但结果明显异常（如 138****34），便于快速发现脏数据。
使用场景限制：
- 仅适用于已知固定长度且格式规整的字段（如标准手机号、银行卡BIN+尾号）
- 不能用于可变长字段（如地址、备注），否则掩码位置漂移
- 不适用于需要保留校验逻辑的字段（如身份证第17位奇偶校验，脱敏后校验失效）
存储过程中必须加的防护层
裸写 SUBSTRING 很危险，必须包裹校验和兜底逻辑：
- 用
CASE WHEN LENGTH(mobile) = 11 THEN ... ELSE mobile END防长度不符 - 对身份证加
REGEXP '^[0-9]{17}[0-9Xx]$'判断是否合规，再决定是否脱敏 - 避免在
WHERE条件中对脱敏字段做模糊匹配（如LIKE '%****%'），会导致索引失效 - 如果字段允许 NULL，所有字符串函数前必须
IFNULL(mobile, '')，否则整个表达式返回 NULL
真正要警惕的不是函数，而是调用时机
存储过程里用 SUBSTRING 脱敏，本质仍是「静态脱敏」：数据一入库就是脱敏态，原始值永久丢失。这意味着：
- 审计时无法追溯原始值（除非额外存加密列）
- 跨系统同步时，对方系统若需原始手机号做实名核验，只能返工重传
- 开发查问题时看到的全是
138****5678，无法确认是真实数据还是脱敏逻辑误伤
所以，哪怕语法再简洁，也得先确认业务是否真的接受不可逆——很多合规场景要求「可逆加密存储 + 动态解密展示」，这时候硬上 SUBSTRING 就是埋雷。
