mysql存储过程不适合精细化脱敏，无法响应用户身份或环境变化；唯一可靠掩码方式是concat(left(phone,3),'**',right(phone,4))，需配合正则过滤脏数据。
MySQL 存储过程不适合做“精细化”脱敏——它无法响应用户身份、环境或字段长度变化，强行封装只会掩盖真实问题。
存储过程根本不能动态判断脱敏强度
你写不出 IF CURRENT_USER() = 'admin' THEN SELECT phone ELSE SELECT CONCAT(LEFT(phone,3),'****',RIGHT(phone,4)) END IF 这种逻辑。MySQL 存储过程不允许在同一个过程里返回结构不同的结果集；更关键的是，CURRENT_USER() 在过程体中无法参与列级条件分支，也不会被优化器识别为确定性上下文。所谓“按角色脱敏”，必须靠视图 + 表权限 + 应用层路由来实现，不是靠存储过程硬塞。
LEFT+RIGHT+CONCAT 是唯一靠谱的掩码组合
别信网上搜到的 MASK() 或 REPLACE(phone, '1', '*')——前者根本不存在，后者会把所有数字 1 都干掉。真正在生产中跑得稳的，只有显式切段：
-
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))：适用于固定 11 位手机号 -
CONCAT(LEFT(id_card, 6), REPEAT('*', GREATEST(0, CHAR_LENGTH(id_card) - 12)), RIGHT(id_card, 4))：兼容 15/18 位身份证，GREATEST防止负数导致空串 - 必须加
WHERE phone REGEXP '^[0-9]{11}$'或id_card IS NOT NULL AND CHAR_LENGTH(id_card) IN (15, 18)，否则LEFT(NULL, 3)返回NULL，脱敏结果直接消失
REGEXP_REPLACE() 看似灵活，实则陷阱密集
MySQL 8.0.4+ 才支持 REGEXP_REPLACE()，5.7 用户直接报错 FUNCTION REGEXP_REPLACE does not exist。即使版本够，也得注意：
- 在
WHERE中使用会导致全表扫描——WHERE REGEXP_REPLACE(phone, '^(\d{3})(\d{4})(\d{4})$', '\1****\3') = '138****1234'彻底失效索引 - 身份证末位
X、手机号带括号或空格，简单正则会漏匹配；必须先REPLACE(REPLACE(phone, ' ', ''), '-', '')清洗再处理 - 反斜杠要双写：
'^(\d{3})'，否则 MySQL 当成普通字符
真正该用存储过程的场景极少
只在满足全部以下条件时才考虑：
- 脱敏规则永久不变（比如测试库批量清洗手机号）
- 目标是更新原表，而非查询时掩码（
UPDATE users SET phone = CONCAT(LEFT(phone,3),'****',RIGHT(phone,4)) WHERE ...） - 不依赖任何运行时参数（如当前登录人、环境标识）
- 已加
WHERE phone REGEXP '^[0-9]{11}$'过滤脏数据，避免LEFT('138',3)这类静默截断
绝大多数情况下，用生成列 + 视图组合更轻量、可索引、可复用，且不会因版本或权限问题突然崩掉。
