结论很明确：别指望重新跑一遍UPDATE就能解决问题。必须先搞清楚数据不一致的根因——是更新逻辑本身有缺陷？并发冲突导致的？事务中途断了？还是类型隐式转换在偷偷作怪？否则你修了A行，B行转眼又崩给你看。

查不到更新结果？先确认事务到底提交没

应用层日志里明明写着“UPDATE成功”，可数据库里数据纹丝不动。十有八九是事务没提交，或者被静默回滚了。这里有个常见陷阱：Python的psycopg2、Ja va的JDBC默认autocommit=False，而Node.js的pg默认autocommit=True，混用的时候特别容易踩坑。

• 显式检查连接状态：conn.autocommit（Python）、connection.getAutoCommit()（Ja va）
• 避免在PostgreSQL存储过程里混用COMMIT和DDL语句（比如CREATE TABLE），这玩意儿会触发隐式提交，导致后续的ROLLBACK全废了
• 在关键节点打点：SELECT txid_current()（PostgreSQL）或SELECT @@TRANCOUNT（SQL Server），确认事务有没有意外退出

WHERE条件没匹配上？别信肉眼看到的SQL

一条像是没毛病的UPDATE users SET status = 'active' WHERE id = '123'，可能因为字段类型和传入值不匹配，连一行都碰不着。MySQL对字符串转数字比较宽松，PostgreSQL则直接不匹配或报错，结果都是“0 rows affected”——你查了半天还以为语句没执行。

• 验证实际类型：SELECT pg_typeof(id) FROM users LIMIT 1（PostgreSQL），或SHOW COLUMNS LIKE 'id'（MySQL）
• 检查比较逻辑：SELECT id::text = '123 ' FROM users LIMIT 1（注意末尾那个空格）
• MySQL开启STRICT_TRANS_TABLES模式，让隐式转换直接报错，别给静默失败留任何余地
• 应用层打印真实绑定参数（比如ORM设echo=True），别相信日志里拼出来的SQL字符串——那些跟实际执行的往往差了十万八千里

并发更新覆盖？必须用RETURNING或版本号校验影响行数

两个请求同时抢着改同一行数据，后提交的直接覆盖前一个的更新。应用层看到的是“UPDATE返回成功”，就以为数据妥了——这是最隐蔽、也最容易忽略的一致性漏洞。

• 在UPDATE里加乐观锁条件：UPDATE orders SET status = 'shipped', version = version + 1 WHERE id = 123 AND version = 5
• 执行后立刻检查影响行数（rowcount），结果为0说明更新失败，需要重试或者提醒用户
• PostgreSQL可以用RETURNING *直接拿到更新后的整行，省掉一次二次查询；MySQL就只能额外来个SELECT确认
• 禁止依赖UPDATE ... WHERE id = X的返回值来判断业务是否成功——它压根不保证数据真的变了

修复后不校验，等于没修

修复脚本跑完就拍屁股走人，转头去搞下一个任务——这种操作是线上事故高发的典型节奏。真正危险的往往不是修复动作本身，而是没去验证修复结果是否符合业务语义。比如你误把status=999全改成0，可0在业务里代表“创建中”，实际应该改成“已取消”才对。

• 用原始校验SQL重跑一遍：SELECT COUNT(*) FROM t WHERE status = 999，确认数量归零
• 抽样核对修复结果：SELECT id, status, updated_at FROM t WHERE id IN (123, 456, 789)，人工比对是否符合预期
• 补上数据库层约束：ALTER TABLE t ADD CONSTRAINT chk_status CHECK (status IN (0,1,2))，让下一次非法写入直接被拦截，省得再折腾