MySQL 8.0.4+ 支持 REGEXP_REPLACE 脱敏，低版本需用 CONCAT+SUBSTR 模拟；须加边界锚点防误脱、禁在 WHERE/JOIN 中使用以防全表扫描；中文与 emoji 需统一 utf8mb4 字符集并谨慎写正则。
REGEXP_REPLACE 在 MySQL 8.0+ 中能直接脱敏，但不支持低版本
MySQL 5.7 及更早版本没有 REGEXP_REPLACE 函数，强行调用会报错 FUNCTION xxx.REGEXP_REPLACE does not exist。必须确认版本：运行 SELECT VERSION();，只有 8.0.4 及以上才可用该函数。若无法升级，得改用 CONCAT + SUBSTR 拼接模拟，但逻辑复杂、难维护。
手机号、身份证号的正则模式要写准，否则会漏脱或误脱
常见错误是正则太宽泛，比如用 '[0-9]{11}' 匹配手机号，可能把订单号、时间戳里的 11 位数字也替换了。应加边界锚点和上下文限制：
- 手机号（11 位，以 1 开头）：
REGEXP_REPLACE(phone, '(^|\s)1[3-9][0-9]{9}($|\s)', '\1****\2')—— 保留前后空格或行首/尾位置 - 身份证号（18 位，末位可能是 X）：
REGEXP_REPLACE(id_card, '([0-9]{6})[0-9]{8}([0-9Xx]{4})', '\1********\2')—— 分组捕获前后段，中间用 * 替换 - 邮箱用户名部分（@ 前）：
REGEXP_REPLACE(email, '([^@]+)@', '****@')—— 注意不能写成.*@，否则贪婪匹配会跨行或吞掉整个字段
脱敏字段参与 JOIN 或 WHERE 时性能会明显下降
REGEXP_REPLACE 是逐行计算的标量函数，无法利用索引。如果在查询条件里写 WHERE REGEXP_REPLACE(name, '.*', '***') = '***'，MySQL 必须全表扫描；同样，用它做 JOIN 条件也会强制嵌套循环。实际使用中应遵守：
- 只在 SELECT 列表中用于输出脱敏，不在 WHERE / ON / ORDER BY 中调用
- 敏感字段本身仍需保留原始列用于查询，脱敏列仅作展示用途
- 如需按脱敏后形态筛选（例如“查所有姓张的用户”），应在应用层处理，或建生成列（MySQL 5.7+ 支持 STORED generated column）预计算脱敏值并建索引
中文字符、emoji 和多字节符号容易导致截断错位
MySQL 默认字符集为 utf8mb4 时，一个 emoji 占 4 字节，但 SUBSTR 类函数按字符计数，REGEXP_REPLACE 的正则引擎也按 Unicode 字符处理——这点没问题。真正出问题的是：当正则表达式里混用字面量中文和 . 或 [\u4e00-\u9fa5] 时，不同 MySQL 版本对 Unicode 范围的支持有差异。稳妥做法是：
- 姓名脱敏避免用正则匹配中文，改用固定长度替换：
REGEXP_REPLACE(name, '^.(.{2,})$', '*\1')（保留姓氏后所有字，首字变 *） - 确保连接客户端、表、列的字符集统一为
utf8mb4，否则正则可能因编码不一致跳过中文 - 测试时用含 emoji 的样本数据（如
'张三?'），验证是否被完整保留或正确替换
脱敏不是加个函数就完事，正则边界、执行位置、字符集、版本兼容这四点漏掉任一，上线后都可能暴露数据或拖垮查询。
