子查询中不能直接UPDATE目标表，须用JOIN或CTE替代；手机号/身份证脱敏优先用SUBSTRING+CONCAT而非正则；UPDATE的WHERE条件需严格匹配关联键并双重过滤；大表脱敏必须分批加LIMIT防锁表和OOM。
子查询里不能直接 UPDATE，得用 JOIN 或 CTE 替代
SQL 标准里，UPDATE 语句的 SET 子句不支持嵌套子查询直接修改目标表的敏感字段（比如把 phone 变成 ****1234），尤其当子查询还引用了被更新的同一张表时，MySQL 会报错 ERROR 1093: You can't specify target table 't' for update in FROM clause，PostgreSQL 则直接拒绝语法。
真正能落地的做法是：把脱敏逻辑封装进子查询或 CTE，再跟原表 JOIN 更新。不是“在 UPDATE 里写子查询”，而是“用子查询结果驱动 UPDATE”。
- MySQL 8.0+ 推荐用
WITH+JOIN，避免临时表歧义 - MySQL 5.7 只能靠派生表（即子查询套一层
SELECT * FROM (…)）绕过错误 - PostgreSQL 允许在
UPDATE … FROM中直接引用子查询，但要注意别名绑定
手机号/身份证脱敏：用 SUBSTRING + CONCAT 拼接比正则更稳
别一上来就用 REGEXP_REPLACE —— 它在 MySQL 8.0 才原生支持，5.7 需要自定义函数；PostgreSQL 虽有，但性能差、可读性低，且不同版本正则语法微调容易翻车。
更可靠的是用字符串截取组合：SUBSTRING 提取前后段，CONCAT 拼掩码。既兼容老版本，又明确控制脱敏粒度。
- 手机号脱敏（保留后4位）：
CONCAT('****', SUBSTRING(phone, -4)) - 身份证脱敏（保留前6后4）：
CONCAT(SUBSTRING(id_card, 1, 6), '******', SUBSTRING(id_card, -4)) - 注意：MySQL 的
SUBSTRING(str, -n)从末尾取 n 位，PostgreSQL 要写成SUBSTRING(str FROM LENGTH(str) - 3)
UPDATE 带子查询时，WHERE 条件必须严格匹配关联键
脱敏常需按用户 ID、租户 ID 等条件筛选，但一旦用了子查询 + JOIN，WHERE 写错位置就会全表误更新或漏更新。最典型错误是把过滤条件只放在子查询里，主表没约束。
正确做法是：过滤逻辑要么放在子查询内部（确保只产出待脱敏行），要么在主 UPDATE 的 WHERE 子句中显式声明关联条件 + 业务条件。
- 错误示例（子查询过滤了，但 UPDATE 没限制）：
UPDATE t JOIN (SELECT id FROM t WHERE status = 'active') tmp ON t.id = tmp.id SET t.phone = CONCAT('****', SUBSTRING(t.phone, -4))→ 如果外层没加WHERE，可能连 status != 'active' 的也一起改了 - 正确写法（双保险）：
UPDATE t JOIN (SELECT id FROM t WHERE status = 'active') tmp ON t.id = tmp.id SET t.phone = CONCAT('****', SUBSTRING(t.phone, -4)) WHERE t.status = 'active' - CTE 方式更清晰：
WITH sensitive AS (SELECT id FROM users WHERE role = 'customer') UPDATE users u JOIN sensitive s ON u.id = s.id SET u.email = CONCAT('***@', SUBSTRING_INDEX(u.email, '@', -1))
大表脱敏要加 LIMIT 和分批，否则锁表+OOM
线上表几百万行，一次 UPDATE 跑到底，轻则锁住整个表导致业务阻塞，重则事务日志暴涨、内存溢出（OOM）。子查询本身不解决这个问题，反而可能因中间结果集放大风险。
必须人工拆分：用主键范围或自增 ID 分页，每次只处理几千行，并确认上一批已提交。
- 分批模板（MySQL）：
UPDATE users SET phone = CONCAT('****', SUBSTRING(phone, -4)) WHERE id BETWEEN 10000 AND 19999 AND phone IS NOT NULL - 加
AND phone NOT LIKE '****%'避免重复脱敏（前提是你能接受这个判断逻辑） - 执行前先
SELECT COUNT(*)验证子查询结果量级，别等 UPDATE 卡住才发现子查询返回了全部数据
脱敏不是写完 SQL 就完事，关键是子查询是否真只捞出了你要动的那几行——少查一行是漏脱敏，多查一行是事故。
