不可靠。REPLACE会全文匹配替换，导致手机号或身份证号中重复数字被多次误替；应使用LEFT+CONCAT或分长度CASE处理，确保仅替换固定位置字符，并注意NULL、日志泄露等生产陷阱。
脱敏手机号：用 REPLACE 替换中间4位是否可靠？
不可靠。直接对整字段用 REPLACE 会误伤——比如把 '13812345678' 里的所有 '1234' 都替换成 '****'，结果可能是 '138****5678'，但更糟的是若号码含重复数字（如 '13812121212'），可能多处被替换，完全失真。
真正安全的做法是「定位替换」：只动第4～7位。这时 LEFT 和 CONCAT 更可控：
SELECT CONCAT(LEFT(mobile, 3), '****', RIGHT(mobile, 4)) AS masked_mobile FROM users;
-
LEFT(mobile, 3)稳定取前3位，不依赖内容 -
RIGHT(mobile, 4)比SUBSTRING(mobile, -4)兼容性更好（MySQL 5.0+ 全支持） - 避免用
REPLACE(mobile, SUBSTRING(mobile,4,4), '****')—— 子串重复时行为不可控
脱敏身份证号：LEFT + SUBSTRING 组合要注意长度校验
身份证号可能是15位或18位，直接 LEFT(id_card, 6) + SUBSTRING(id_card, -4) 会漏掉15位证的校验位逻辑，且末4位在15位证里其实是出生年月日的一部分，脱敏粒度不对。
稳妥做法是先判断长度，再分路径处理：
SELECT CASE WHEN LENGTH(id_card) = 18 THEN CONCAT(LEFT(id_card, 6), '********', RIGHT(id_card, 4)) WHEN LENGTH(id_card) = 15 THEN CONCAT(LEFT(id_card, 6), '******', RIGHT(id_card, 3)) ELSE 'INVALID' END AS masked_id FROM users;
- 必须显式检查
LENGTH()，不能假设全是18位 - 15位证末3位是顺序码+校验（无X），所以掩码位数要少1位
- 别用
REPLACE去“删掉”中间段——它不认位置，只认值，身份证里数字重复极高
为什么不用 REPLACE 做通用脱敏？
因为 REPLACE(str, from_str, to_str) 是全文模糊替换，不是按索引操作。它解决不了「固定位置遮盖」这个核心需求，反而引入三类风险：
- 源字符串含多个匹配子串 → 多次替换，结果错乱（如邮箱
'admin@1234.com'中'1234'被替） - from_str 本身是变量（如用
SUBSTRING动态生成）→ 若值为空或含特殊字符（%,_），可能触发意外模式匹配 - 性能差：全扫描比定位截取慢，尤其大字段或大数据量时
真正需要 REPLACE 的场景极少，比如统一清理字段中所有空格或特定符号，而不是脱敏。
生产环境脱敏必须绕开的坑
脱敏不是前端加个 *** 就完事，数据库层处理有硬约束：
- 字段类型要匹配：如果原字段是
VARCHAR(11)（手机号），脱敏后仍是11位，但CONCAT(LEFT(), '****', RIGHT())结果长度固定，需确认目标列能容纳（比如11位变11位，没问题；但身份证18→18，也OK） - NULL 值必须显式处理，否则
LEFT(NULL, 3)返回NULL，整个表达式崩掉：IFNULL(LEFT(mobile, 3), '') - WHERE 条件里不能对脱敏结果做查询——你永远不该用
WHERE masked_mobile = '138****5678'，这既没意义又慢；脱敏只用于 SELECT 展示
最常被忽略的一点：日志和审计。如果应用层没关掉 SQL 日志，SELECT CONCAT(...) 这种语句本身会把原始字段明文打到日志里——脱敏白做。得配合数据库日志过滤策略一起落地。
