先用select模拟脱敏逻辑再执行update；需检查字段长度、格式、null值、数据库substring行为差异及边界情况，避免错位或空值。
update 里用 substring 做脱敏时，怎么确认改对了？
别直接跑 update，先用 select 模拟替换逻辑。很多人跳过这步，结果把手机号中间四位全替成星号后发现——原字段是 varchar(11)，但有些数据带空格或短号，substring(phone, 1, 3) + '****' + substring(phone, 8, 4) 一执行就截出空值或错位。
- 真实场景中，先查出所有待脱敏字段的长度和格式：
SELECT phone, LENGTH(TRIM(phone)), REGEXP_LIKE(phone, '^1[3-9]\d{9}$') FROM users WHERE ... -
SUBSTRING在 MySQL 和 PostgreSQL 行为不同：MySQL 从 1 开始计数，PostgreSQL 默认从 1，但如果你开了substring(... FROM 0)兼容模式，行为会变 - 空值、NULL、空字符串必须单独处理，否则
SUBSTRING(NULL, 1, 3)直接返回 NULL，整条记录脱敏后变空 - 测试时加
LIMIT 5和FOR UPDATE SKIP LOCKED（如支持）避免锁表干扰验证
用 REPLACE 批量脱敏邮箱时，为什么 @ 符号前后都变了？
REPLACE 是全文傻替换，不识别上下文。想把 user@domain.com 脱敏成 u***r@domain.com，如果写成 REPLACE(email, SUBSTRING(email, 2, LENGTH(email)-3), '***') 就错了——这不是 REPLACE 的用法，它只接受固定字符串做查找目标。
- 正确思路是用字符串拼接：
CONCAT(LEFT(email, 1), '***', SUBSTRING(email, LENGTH(email) - LOCATE('@', REVERSE(email)) + 1)) - 注意
LOCATE('@', email)返回首次出现位置，但邮箱可能含多个 @（比如admin@mail@company.com），得用STRRPOS（PostgreSQL）或LENGTH(email) - LENGTH(REPLACE(email, '@', ''))倒推最后一个 @ - MySQL 8.0+ 可用
REGEXP_REPLACE，但正则引擎不统一：MySQL 用 ICU，MariaDB 用 PCRE，匹配(.)(.*?)(@)时捕获组数量和贪婪性表现不同
脱敏 SQL 验证阶段，哪些字段最容易漏掉边界情况？
身份证、手机号、银行卡号看着结构固定，实际入库时早被业务代码“加工”过了：补零、加横线、混入字母（如 L 开头的老身份证）、前端传参带换行符。这些不会报错，但脱敏后变成无效格式。
- 身份证：长度可能是 15 或 18，末位可能是 X，但大小写不敏感；用
UPPER()统一后再截取，否则SUBSTRING(id_card, 1, 6) + '********' + SUBSTRING(id_card, -1)在小写 x 上失效 - 银行卡号：常被空格或下划线分段，
REPLACE(card_no, ' ', '')必须放在最外层，否则SUBSTRING按带空格长度截取，前 4 位可能截到空格 - 地址字段：用
REPLACE(address, '中国', '***')看似安全，但如果字段值是中国北京市，结果变***北京市，地理层级信息意外丢失
验证 SQL 执行后，怎么快速比对脱敏前后差异？
不能只看“看起来像脱敏了”，要量化验证。重点不是是否用了星号，而是原始敏感信息是否真正不可逆、不可推断。
- 对手机号，执行：
SELECT COUNT(*) FROM users WHERE phone REGEXP '^[1][3-9]\d{10}$' AND (SUBSTRING(phone, 4, 4) != '****')—— 这能揪出漏脱敏或部分脱敏的记录 - 用
MD5或SHA2对原始字段哈希后存临时表，脱敏后再对脱敏结果哈希，对比哈希值变化率应为 100%（排除 NULL 和空值） - 导出脱敏前后各 100 条，用
diff -y行对行比对，比肉眼扫快得多；注意数据库导出时字段间分隔符是否一致（如 CSV 里的逗号是否被转义）
脱敏验证最耗时的环节从来不是写 SQL，而是搞清业务数据到底长什么样——字段注释写着“手机号”，实际存的是“+86 138 1234 5678”。多花十分钟查样本，能省两小时回滚时间。
