mysql存储过程无法实现真正的动态脱敏与加密协同，因其不支持按用户身份切换脱敏强度，且sql层无法安全加解密传输；唯一可行的是left+right+concat等标量掩码函数，需严格过滤数据并避免高频查询。
MySQL 存储过程无法实现真正意义上的“动态脱敏”与“加密”协同——它既不能根据用户身份实时切换脱敏强度，也不能在 SQL 层完成安全的加解密传输。所谓“存储过程中做动态脱敏”，多数是误解或强行封装导致逻辑失控、权限混乱、甚至数据错位。
为什么 CURRENT_USER() + IF 在存储过程中做脱敏会失败
你写不出类似 IF CURRENT_USER() = 'admin'@'%' THEN SELECT phone ELSE SELECT CONCAT(LEFT(phone,3),'****',RIGHT(phone,4)) END IF 这样的逻辑，原因很实在：
- MySQL 存储过程不允许同一个
SELECT语句中返回结构不同的结果集（列数/类型不一致），THEN和ELSE分支若选不同字段，直接语法报错 -
CURRENT_USER()是非确定性函数，MySQL 视图和存储过程优化器不会将其视为上下文变量；它在过程体中只能用于判断，但无法驱动列级输出策略 - 即使绕过语法，用动态 SQL（
PREPARE/EXECUTE）拼接不同SELECT，也会引入 SQL 注入风险，且无法被权限系统有效拦截
这不是技巧问题，是 MySQL 架构限制。
LEFT+RIGHT+CONCAT 是唯一能落地的掩码组合
别信 MASK()、REPLACE(phone, '1', '*') 或 REGEXP_REPLACE() 做主力脱敏——前者根本不存在，后者在 5.7 不可用、8.0+ 用错就全表扫描。
生产中真正跑得稳的写法只有显式切段：
- 手机号（11位）：
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) - 身份证（兼容15/18位，含末位X）：
CONCAT(LEFT(id_card, 6), REPEAT('*', GREATEST(0, CHAR_LENGTH(id_card) - 12)), RIGHT(id_card, 4)) - 必须加过滤：
WHERE phone REGEXP '^[0-9]{11}$'或id_card IS NOT NULL AND CHAR_LENGTH(id_card) IN (15, 18)，否则LEFT(NULL, 3)返回NULL，整行脱敏结果消失
这些函数全是标量计算，不走索引，高频查询时性能敏感，别把它当查询主干字段用。
加密不是存储过程该干的事
HASHBYTES（SQL Server）、AES_ENCRYPT()（MySQL）这类函数只适合“落地前预处理”，比如密码存盐哈希、手机号哈希后做关联比对。它们不是为“传输加密”设计的：
- 哈希不可逆，无法还原原始值，不适用于需要展示部分明文的脱敏场景（如 138****1234）
-
AES_ENCRYPT()需要密钥管理，MySQL 没有安全密钥存储机制，硬编码密钥等于裸奔 - 所谓“过程内加密再传出去”，本质仍是明文落库 + 网络层无防护；防窃听必须靠 TLS/SSL，不是靠 SQL 函数
如果你真需要加密传输，配置数据库连接的 require_secure_transport=ON，让客户端走 SSL 连接——这才是有效防线。
真正该用存储过程的场景极少
只有同时满足以下全部条件时，才考虑用存储过程做脱敏：
- 规则永久不变（比如测试库批量清洗手机号，永远都是 138****1234 格式）
- 目标是
UPDATE写回原表，而非查询时动态掩码 - 不依赖任何运行时参数（当前用户、环境标识、租户ID等）
- 已加
WHERE phone REGEXP '^[0-9]{11}$'过滤脏数据，避免LEFT('138',3)这类静默截断
绝大多数需求，应该用视图封装（CREATE VIEW v_users_masked AS ...）或把脱敏逻辑前移到应用层（Python/Java 处理后再进 SQL）。存储过程不是万能胶，粘错了地方，修起来更费劲。
