MySQL 8.0+才支持REGEXP_REPLACE()，5.7及更早版本会报“FUNCTION does not exist”错误；该函数在WHERE中使用会导致索引失效，脱敏应仅用于SELECT输出，且需注意X、括号、空格等边界情况及反斜杠双写转义。
MySQL 8.0+ 才能用 REGEXP_REPLACE()，5.7 及更早版本直接报错
你写完 REGEXP_REPLACE(phone, '[0-9]{4}', '****') 却提示 FUNCTION REGEXP_REPLACE does not exist？不是语法错，是版本不支持。MySQL 官方直到 8.0.4 才引入该函数，5.7 用户只能退回到嵌套 REPLACE() 或改用应用层处理。Percona Server 5.7 虽有部分兼容补丁，但行为不稳定，不建议在生产环境依赖。
REGEXP_REPLACE() 在 WHERE 中使用 = 全表扫描，索引彻底失效
脱敏逻辑如果写进查询条件，比如 WHERE REGEXP_REPLACE(id_card, '\d{8}', '********') = '110101********34'，MySQL 无法利用 id_card 列上的索引——因为函数作用于字段本身，优化器判定无法做索引查找。真实场景中，这类语句会让慢查询陡增 3–5 倍。正确做法是：脱敏只用于 SELECT 输出，WHERE 条件必须基于原始字段（如 WHERE id_card LIKE '110101%'）或预计算的生成列。
正则脱敏易踩的三个坑：X、括号、空格
身份证末位可能是 X（大写），手机号可能带 (010)1234-5678 或空格分隔，而简单正则 'd{11}' 会漏匹配。常见错误现象包括：脱敏后出现 138****-5678 或 110101********X（末位 X 未被掩码）。实际应分步处理：
- 先统一清洗格式：用
REPLACE(REPLACE(phone, '-', ''), ' ', '')去掉干扰符 - 再正则匹配数字段：
REGEXP_REPLACE(cleaned_phone, '(^\d{3})(\d{4})(\d{4}$)', '\1****\3') - 注意转义：MySQL 中反斜杠需双写，
'\d'才表示数字字符类
存储过程中调用 REGEXP_REPLACE() 需显式声明 SQL SECURITY DEFINER
如果你把脱敏逻辑封装进存储过程，但执行时提示 Access denied for function REGEXP_REPLACE，大概率是权限或安全上下文问题。MySQL 默认以 INVOKER 模式执行，而函数权限检查受调用者权限限制。解决方式是在创建时明确指定：
CREATE DEFINER='admin'@'%' PROCEDURE sp_mask_user_data()
SQL SECURITY DEFINER
BEGIN
SELECT name, REGEXP_REPLACE(phone, '(^\d{3})(\d{4})(\d{4})', '\1****\3') AS phone_mask
FROM users;
END;
否则即使用户有 SELECT 权限，也可能因缺少函数执行权而失败。另外，DEFINER 账户必须真实存在且具备对应函数权限。
正则脱敏看着灵活，但每加一层嵌套或一个边界 case，维护成本就翻倍；真正稳定的脱敏，往往靠预清洗 + 确定性函数组合，而不是指望一条正则通吃所有格式变体。
