MySQL存储过程不适合通用脱敏，仅适用于规则固定、不依赖身份且需批量写回的极少数场景；生产中应优先采用视图+生成列或应用层处理。
MySQL 存储过程不适合做通用脱敏，它只能用于规则固定、不依赖运行时身份、且需批量写回原表的极少数场景。真正在生产中安全可用的脱敏方式，是视图 + 生成列，或应用层处理。
存储过程里硬编码脱敏逻辑会报错或失效
MySQL 不允许在存储过程中根据用户角色动态返回不同结构的结果集。比如写 IF CURRENT_USER() = 'admin'@'%' THEN SELECT phone ELSE SELECT CONCAT(LEFT(phone,3),'****',RIGHT(phone,4)) END IF，这根本无法通过语法检查——存储过程不能在同一个 SELECT 中切换列定义。更常见的是误以为能用会话变量控制掩码长度，但 @mask_len 无法直接参与字符串函数计算，除非拼 SQL 字符串再 PREPARE/EXECUTE，而这极易引入 SQL 注入风险。
UPDATE 批量脱敏比存储过程游标快一个数量级
如果你只是想把测试库里的手机号全改成 138****1234 这种格式并写回原表，别写循环游标。直接用单条 UPDATE：
UPDATE users
SET phone = CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))
WHERE phone REGEXP '^[0-9]{11}$';
这个写法比存储过程里逐行 FETCH 快得多，也更容易加索引和条件过滤。漏掉 WHERE 中的正则校验，遇到空值或短字符串时 LEFT(phone, 3) 会静默截断，导致数据错位。
真要用存储过程，必须绕过列名参数化陷阱
如果业务强制要求“传入表名和字段名”，MySQL 不支持 SELECT @col_name FROM @tbl_name 这种写法。你只能走动态 SQL，但必须满足：
- 表名和字段名从白名单表中查出，而非直接拼接用户输入
- 脱敏逻辑封装成独立函数，如
f_mask_phone(s VARCHAR(11))，再在动态 SQL 中调用 - 用
CONCAT_WS('', ...)替代CONCAT()，避免任意字段为NULL导致整段结果变NULL - 创建时显式声明
SQL SECURITY DEFINER，否则调用者可能因权限不足而失败
视图才是 MySQL 脱敏的正确起点
绝大多数所谓“需要存储过程脱敏”的需求，其实只需要一个带 CASE WHEN 的视图：
CREATE VIEW v_users_masked AS
SELECT id, name,
CASE WHEN phone IS NOT NULL AND phone REGEXP '^1[3-9]\d{9}$'
THEN CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))
ELSE '****'
END AS phone,
CASE WHEN id_card IS NOT NULL AND id_card REGEXP '^\d{17}[\dXx]$'
THEN CONCAT(LEFT(id_card, 6), '******', RIGHT(id_card, 4))
ELSE '********'
END AS id_card
FROM users;
建完视图后立刻执行 REVOKE SELECT ON users FROM 'app_user'@'%'，再 GRANT SELECT ON v_users_masked TO 'app_user'@'%'。这才是可控、可审计、不改源表的脱敏基础。存储过程在这里毫无存在必要。
