SQL Server中UPDATE FROM不能直接引用被更新表，必须用CTE或派生表先生成脱敏结果再JOIN更新，且需TRIM()、CASE校验、TOP分批及长度检查。
SQL Server 中不能在 UPDATE 的 FROM 子句里直接引用被更新的同一张表——这是硬性限制，不是写法问题。想靠“子查询里套 UPDATE t SET t.phone = ... WHERE t.id IN (SELECT id FROM t)”这种写法，必然失败。
为什么子查询不能直接 UPDATE 目标表
MySQL 会报 ERROR 1093，SQL Server 虽不报这个错，但若在 UPDATE ... FROM 中把原表 alias 成子查询别名（比如 FROM Users u INNER JOIN (SELECT * FROM Users) tmp ON ...），仍可能触发不可预期行为：比如重复更新、NULL 覆盖、或执行计划跳过过滤条件。根本原因是 SQL Server 在解析时无法安全区分“读取源”和“更新目标”的语义边界。
- 真正能跑通的路径只有一条：用 CTE 或派生表先产出脱敏结果集，再跟原表
JOIN更新 - CTE 必须把业务过滤（如
WHERE phone IS NOT NULL AND TRIM(phone) != ''）写在内部，否则未过滤行会参与JOIN，导致匹配失败 →NULL写入 - SQL Server 不支持 PostgreSQL 那种
UPDATE ... FROM (SELECT ...) AS sub的宽松语法，必须显式绑定别名且确保无歧义
手机号/身份证脱敏必须用 SUBSTRING + CONCAT，别碰 REGEXP_REPLACE
SQL Server 2022 才原生支持 REGEXP_REPLACE，旧版本（尤其是还在用 2016/2019 的生产环境）需启用 CLR 或自定义函数，部署成本高、权限管控严、正则引擎性能也不稳定。而 SUBSTRING 和 CONCAT 兼容所有版本，逻辑直白，调试一眼可见。
- 手机号（11位，保留前3后4）：
CONCAT(LEFT(TRIM(phone), 3), '****', RIGHT(TRIM(phone), 4)) - 身份证（18位，保留前6后4）：
CONCAT(SUBSTRING(TRIM(id_card), 1, 6), '******', SUBSTRING(TRIM(id_card), LEN(TRIM(id_card)) - 3, 4)) -
TRIM()不可省：开头空格会让LEFT(phone, 3)返回空字符串，最终变成****1234→ 实际是****1234，但前段为空，视觉上只剩后4位 - 用
CASE WHEN包一层更稳：CASE WHEN LEN(TRIM(phone)) = 11 THEN ... ELSE phone END，避免非法长度字段报错或污染结果
大表脱敏必须分批，TOP (10000) 不是可选项
一次性更新百万级用户表，事务日志瞬间暴涨，可能占满磁盘；锁升级成表锁，业务查询全卡住；内存压力大，甚至触发 OOM。这不是“建议”，是线上事故高频原因。
- 写法必须带
TOP (10000)+WHERE条件双重控制：UPDATE TOP (10000) u SET ... FROM Users u INNER JOIN masked m ON u.id = m.id WHERE u.id > @last_id - 循环逻辑得自己补：用
@last_id = SCOPE_IDENTITY()或查出本次最大id，下一轮继续 - 别信“加索引就能快”：脱敏字段（如
phone）通常没索引，TRIM(phone)还会导致索引失效，所以过滤必须靠主键范围扫描 - 测试时先在副本表上跑
SELECT COUNT(*)确认匹配行数，再动手 —— 误写WHERE漏条件，一次就全表覆盖
用 CTE 还是派生表？优先选 CTE，但要注意兼容性
SQL Server 2005+ 都支持 CTE，语义清晰、嵌套可读性强。但某些老系统（尤其金融类定制中间件）会把 CTE 解析成临时表，导致统计信息不准、执行计划劣化。这时候派生表反而更可控。
- CTE 写法（推荐）：
WITH masked AS (SELECT id, CONCAT(...) AS masked_phone FROM Users WHERE ...)，后面直接UPDATE ... FROM Users u INNER JOIN masked m ... - 派生表写法（兼容兜底）：
UPDATE u SET u.phone = tmp.masked_phone FROM Users u INNER JOIN (SELECT id, CONCAT(...) AS masked_phone FROM Users WHERE ...) AS tmp ON u.id = tmp.id - 注意：派生表必须有别名（
AS tmp），且子查询里不能出现ORDER BY（除非配TOP），否则语法报错 - 如果脱敏字段要跨多表关联（比如从
UserProfile拿真实号码，往Users写掩码），CTE 更易组织逻辑，派生表容易嵌套过深难维护
最常被忽略的一点：脱敏后的字段长度是否还匹配原列定义？比如 phone VARCHAR(20) 脱敏成 ***1234（8位），看着没问题；但如果原值含空格或特殊字符，TRIM() 后再拼接，长度可能超限，导致截断或报错。上线前务必用 LEN() 校验样本数据的实际输出长度。
