能直接用SQL定位并修复的脏数据必须满足异常模式可描述、修复逻辑可批量表达两个前提；否则应停服查代码。程序Bug导致的脏数据有固定“指纹”，可通过带时间范围和业务上下文的SELECT快速筛查，如查非法状态、时间倒挂、空值突增等；修复前须验证影响范围、抽样确认、检查下游依赖，并在从库或备份库预演；修复时用CASE WHEN安全批量修正，WHERE条件须同时限定时间范围和错误值；修复后必须添加数据库约束和定时校验监控，并确保修复语句在事务中执行。
能直接用SQL定位并修复的脏数据，必须满足两个前提：异常模式可描述、修复逻辑可批量表达。否则就得停服查代码，别硬写UPDATE。
怎么快速筛出程序Bug写入的脏数据
程序Bug导致的脏数据往往有固定“指纹”，比如某次上线后某个字段突然出现大量0、-1、'N/A'、NULL，或时间字段倒退、金额为负、状态值超出枚举范围。不要靠肉眼扫，用带条件的SELECT直接捞：
- 查非法状态：
SELECT * FROM orders WHERE status NOT IN (0, 1, 2, 3) AND created_at > '2026-06-10'（假设Bug是6月10日上线后引入） - 查时间倒挂：
SELECT * FROM orders WHERE ship_time - 查金额异常：
SELECT * FROM payments WHERE amount 1000000 - 查空值突增：
SELECT COUNT(*) FROM users WHERE phone IS NULL AND updated_at > '2026-06-10 14:00:00'
关键不是“全表查”，而是加时间范围+业务上下文过滤，避免误伤历史正常数据。
修复前必须验证影响范围
一条UPDATE跑错，可能把半年数据全刷成0。执行前务必确认三件事：
- 先用
SELECT COUNT(*)统计待修复行数，如果超过5%总记录量，暂停——大概率是逻辑Bug没修，光在擦屁股 - 抽样检查
SELECT * FROM ... LIMIT 5，确认这些行确实是Bug所致，不是人工补录或特殊场景 - 查该字段是否被下游视图、报表、定时任务依赖，比如
status = 999被前端硬编码为“处理中”，那你改成0就直接导致页面显示异常
生产环境严禁在主库直接跑UPDATE。先在从库或备份库执行一遍，看结果是否符合预期。
用CASE WHEN做安全批量修正
修复的核心是“映射明确”，不能靠猜。比如Bug导致所有新订单status被写成999，而它本应是0（待支付），那就只修正这部分：
UPDATE orders SET status = CASE WHEN status = 999 THEN 0 ELSE status END WHERE created_at > '2026-06-10' AND status = 999;
注意点：
- WHERE条件必须同时包含时间范围和原始错误值，防止误更新旧数据
- 不要写
UPDATE ... SET status = 0 WHERE status = 999——没有时间限定，等于把历史上所有曾为999的记录都改了 - 如果修复需关联其他表（如用
users表补orders.user_type），一定要加IS NULL限定，避免覆盖已有正确值：UPDATE orders o JOIN users u ON o.user_id = u.id SET o.user_type = u.type WHERE o.user_type IS NULL AND o.created_at > '2026-06-10'
修复后必须补约束和监控
修完不加防护，下次还来。两件事必须做：
- 加数据库级约束：
ALTER TABLE orders ADD CONSTRAINT chk_status CHECK (status IN (0, 1, 2, 3))，让下一次插入/更新直接报错，而不是写进去再清理 - 建校验脚本定时跑：
SELECT COUNT(*) FROM orders WHERE status NOT IN (0,1,2,3) AND created_at > DATE_SUB(NOW(), INTERVAL 1 DAY)，结果非零就告警
最常被忽略的是：修复语句本身没加事务包裹，或者没开AUTOCOMMIT=OFF。一旦中途失败，部分行已更新，数据就处于中间态——这点比SQL写错更难回滚。
