一次性 update 三百万行做脱敏，表被锁了四十分钟，订单写入全部超时，接口 504 涨到 30%。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，一个大事务包住全表更新，行锁加上 undo 膨胀，主从延迟拉到十几分钟。脱敏任务没有分批，也没放在低峰期。
「批量脱敏锁表」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
UPDATE users SET phone = mask(phone) WHERE id > 0 AND id <= 2000 AND masked = 0;
同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
改完隔一天再看一次，当场正常不代表能稳住。
具体做法是，按主键分批 每批 2000 行提交一次；只处理需要脱敏的行 加 where 条件；放到凌晨低峰执行；观察主从延迟 超阈值自动暂停。
最后用这个标准收尾，脱敏期间订单写入正常 主从延迟不超过 3 秒。