不能靠“重跑一遍update”修复，必须先定位是否由更新逻辑缺陷、并发冲突、事务中断或类型隐式转换引发；查不到结果需先确认事务是否提交，检查autocommit状态及影响行数。
直接说结论：不能靠“重跑一遍UPDATE”来修复，必须先定位不一致是否由更新逻辑缺陷、并发冲突、事务中断或类型隐式转换引发——否则修了A行，B行又出问题。
查不到更新结果？先确认事务到底提交没
应用层日志显示“UPDATE成功”，但数据没变，八成是事务没提交或被静默回滚。Python的psycopg2、Java的JDBC默认autocommit=False，而Node.js的pg默认autocommit=True，混用时极易踩坑。
- 显式检查连接状态：
conn.autocommit（Python）、connection.getAutoCommit()（Java） - 避免在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))，让下一次非法写入直接被拦截
