MySQL 8.0.4+才支持REGEXP_REPLACE脱敏；低版本需用CONCAT+SUBSTR替代，并确认regexp_engine已启用，手机号、身份证、邮箱等须用边界锚定正则，避免误匹配，且不可在WHERE中使用以防全表扫描。
MySQL 8.0.4+ 才能用 REGEXP_REPLACE 安全脱敏；低于这个版本会直接报错 FUNCTION xxx.REGEXP_REPLACE does not exist，别硬试。
确认 MySQL 版本是第一道门槛
不是所有 8.0 都行——必须是 8.0.4 或更高。低版本（比如 8.0.1）虽标称 8.0，但没实现该函数。
- 运行
SELECT VERSION();看真实版本号，别信安装包名字 - 如果返回类似
8.0.3，REGEXP_REPLACE调用必失败，得换CONCAT+SUBSTR拼接方案 - 升级前先查兼容性：某些云厂商的 MySQL 8.0 实例默认关正则支持，需手动开
regexp_engine配置项
手机号和身份证号的正则模式不能只写数字长度
用 [0-9]{11} 匹配手机号？大概率误伤订单号、时间戳、流水 ID。真正要防的是“上下文无关的裸数字”。
- 手机号（11 位、以 1 开头）推荐：
(^|\s)1[3-9][0-9]{9}($|\s)，捕获前后边界再还原，避免吞掉空格或换行 - 身份证号（18 位，末位可为 X）用分组更稳：
([0-9]{6})[0-9]{8}([0-9Xx]{4})→\1********\2，不依赖全局匹配，也不怕中间有横线或空格 - 邮箱用户名部分必须锚定
@：([^@]+)@替换为****@，别用.*@，否则贪婪匹配可能跨字段
千万别在 WHERE 或 JOIN 条件里调用 REGEXP_REPLACE
它是个逐行计算的标量函数，不走索引。一旦写进过滤条件，MySQL 就只能全表扫描。
- 错误写法：
WHERE REGEXP_REPLACE(phone, '1[3-9]\d{9}', '****') = '****'→ 强制扫全表 - 正确做法：原始字段（如
phone）保留不动用于查询，脱敏仅出现在SELECT列表，例如：SELECT id, name, REGEXP_REPLACE(phone, ...) - 真需要按脱敏后内容筛选（比如“姓张的用户”），要么在应用层处理，要么建
STORED生成列并加索引，别指望函数实时算
中文名和 emoji 场景下，别迷信正则匹配汉字
MySQL 对 [\u4e00-\u9fa5] 这类 Unicode 范围的支持不稳定，不同小版本行为可能不一致，且 emoji 占 4 字节但正则按字符计数，容易错位。
- 姓名脱敏优先用固定长度逻辑：
REGEXP_REPLACE(name, '^.(.{2,})$', '*\1')—— 取首字后所有字符，首字变*，不碰 Unicode 范围 - 确保连接和表字符集是
utf8mb4，否则 emoji 会被截断成乱码，脱敏结果不可控 - 所有脱敏表达式都加
IFNULL(..., '')包一层，防止 NULL 字段导致整行脱敏列变 NULL
最常被忽略的一点：脱敏逻辑写进视图后，必须显式回收用户对基表的 SELECT 权限。视图不自动隔离，权限漏一条，原始数据就裸奔。这不是语法问题，是权限模型的刚性约束。
