mysql 8.0无内置mask()函数，生产中稳定脱敏需用left()+right()+concat()组合并显式处理空值与格式清洗，而非依赖不存在的函数或不可控的replace()。
MySQL 8.0 中没有内置的 MASK() 函数，存储过程里也不能直接调用不存在的脱敏函数；真正在生产中稳定掩码，得靠 LEFT()、RIGHT()、CONCAT() 组合 + 显式空值兜底，而不是依赖幻想中的“一键掩码”。
存储过程中不能用 MASK() 或 REPLACE() 做通用脱敏
写 MASK(phone, 3, 4) 会直接报错 FUNCTION MASK does not exist —— MySQL 官方函数列表里压根没这玩意儿。有人误以为它来自 SQL Server 的 DDM 或 Oracle 的 DBMS_REDACT，但那是别的数据库。至于 REPLACE()，它只做子串全局替换，比如 REPLACE(phone, '1', '*') 会把所有数字 1 都干掉，连区号和尾号里的 1 都不放过，完全不可控。
-
REPLACE()对 NULL 返回 NULL，而脱敏结果应是确定格式（如***-****-****） - 对身份证这类含字母 X、长度不一（15/18 位）的字段，
REPLACE()根本无法识别校验位或长度规则 - 试图封装成存储过程后迁移至 5.7 或其他环境，会因函数缺失直接崩
真正可用的掩码逻辑：LEFT+RIGHT+CONCAT 组合
这是兼容性最好、语义最清晰的写法，适用于 MySQL 5.7+ 所有版本。核心是“显式切段 + 确定拼接”，不依赖正则、不假设数据干净。在存储过程中使用时，必须包裹 IFNULL() 或 COALESCE() 处理空值，否则整列可能为空。
- 手机号标准掩码：
CONCAT(IFNULL(LEFT(TRIM(phone), 3), ''), '****', IFNULL(RIGHT(TRIM(phone), 4), '')) - 身份证推荐写法：
CONCAT(IFNULL(LEFT(id_card, 6), ''), REPEAT('*', 8), IFNULL(RIGHT(id_card, 4), ''))（避开末位 X 导致的长度错位） - 邮箱掩码示例：
CONCAT(IFNULL(LEFT(email, 1), ''), '***', IFNULL(SUBSTRING(email, LOCATE('@', email)), ''))
如果要用 REGEXP_REPLACE()，注意版本与权限陷阱
该函数仅在 MySQL 8.0.4+ 可用，5.7 用户写完直接报 FUNCTION REGEXP_REPLACE does not exist。即使版本达标，在存储过程中调用也需显式声明 SQL SECURITY DEFINER，否则常因权限不足报 Access denied for function REGEXP_REPLACE。
- 正则表达式中反斜杠必须双写，
'\d'才表示数字类，单写'd'会被当普通字符 - 不能在
WHERE子句中用它做条件过滤，否则索引彻底失效，查询变全表扫描 - 真实数据带括号、空格、短横线（如
(010)1234-5678），得先清洗：REPLACE(REPLACE(phone, '-', ''), ' ', '')
存储过程不是万能胶：哪些场景不该硬上
触发器或存储过程改写原始字段，本质是“落库即掩码”，一旦执行就不可逆。如果你需要保留原始值供风控比对、或按角色返回不同掩码强度（如客服看后 4 位、审计员全屏蔽），存储过程做不到——它不感知用户身份，也无法动态切换逻辑。
- 需要保留原始字段用于实时比对（如反欺诈）→ 改用视图 + 权限回收
- 要支持不同角色看到不同掩码粒度 → 必须上 MySQL 8.0.22+ 的行级安全策略（RLS）或代理层
- 字段本身已加密（如
AES_ENCRYPT()）→ 掩码应在应用层解密后处理，而非在存储过程中对密文再操作
最易被忽略的一点：无论用哪种方式，只要涉及字符串截取，就必须统一清洗输入（TRIM()）、显式处理空值（IFNULL()）、校验长度边界（比如手机号强制 11 位），否则上线后第一波脏数据就会让整个脱敏逻辑崩出奇怪格式。
