最隐蔽危险的并发一致性破口是UPDATE未加WHERE导致全表覆盖，高并发下引发“最后写入获胜”、ABA问题、死锁及不可重复读等风险，须用WHERE精确匹配、乐观锁、显式行锁和原子化校验防范。
UPDATE 语句没加 WHERE 条件导致全表覆盖
这是最隐蔽也最危险的并发一致性破口：单条 UPDATE 没带 WHERE，在高并发下可能被多个请求同时执行，结果不是“谁先谁后”，而是“谁最后谁赢”，且中间状态完全不可见。
常见错误现象：UPDATE users SET status = 'active'（漏掉 WHERE id = ?）；上线后发现大量用户状态被意外批量改写。
- 务必在所有
UPDATE前确认WHERE条件是否精确匹配业务主键或唯一约束字段 - 开发环境可开启 mysql 的
sql_safe_updates=ON（或 postgresql 的safe_update_mode类似机制），强制要求UPDATE/delete必须含WHERE或LIMIT - 用
EXPLaiN或EXPLAIN ANALYZE验证执行计划，确保WHERE字段命中索引——否则即使写了WHERE，也可能因锁全表而引发连锁阻塞
WHERE 条件基于非最新值引发 ABA 问题
典型场景：前端读出某订单 status = 'pending'，用户点击“支付”触发 UPDATE orders SET status = 'paid' WHERE status = 'pending' AND id = 123。但若该订单在读取后已被另一服务设为 'cancelled'，又回滚成 'pending'（ABA），这条 UPDATE 仍会成功，破坏业务语义。
本质是把“读取时的状态”当成了更新前提，但数据库不保证该状态自读取后未被篡改。
- 改用版本号（
version）或时间戳（updated_at）做乐观锁：UPDATE ... SET status = 'paid', version = version + 1 WHERE id = 123 AND version = 5 - 检查
ROW_COUNT()（MySQL）或GET DIAGNOSTICS（PostgreSQL）返回影响行数，为 0 则说明条件不满足，需重试或报错 - 避免在应用层拼接
WHERE status = ?，尤其当 status 是枚举且存在中间态流转时
多个 UPDATE 涉及同一行但顺序不定引发死锁
两个事务分别执行：UPDATE accounts SET balance = balance - 100 WHERE id = 1001;UPDATE accounts SET balance = balance + 100 WHERE id = 1002;
与UPDATE accounts SET balance = balance + 100 WHERE id = 1002;UPDATE accounts SET balance = balance - 100 WHERE id = 1001;
——只要加锁顺序不一致，InnoDB 就可能检测到循环等待并回滚其中一个。
- 约定全局更新顺序：对涉及多行的事务，始终按主键升序（或固定哈希分片序）排列
UPDATE语句 - 尽量合并为单条语句：
UPDATE accounts SET balance = CASE id WHEN 1001 THEN balance - 100 WHEN 1002 THEN balance + 100 END WHERE id IN (1001, 1002) - 监控
Innodb_row_lock_waits和innodb_deadlocks，死锁日志里会明确写出哪两行锁冲突、哪个事务被选为 victim
READ COMMITTED 下的“不可重复读”干扰业务判断
比如库存扣减逻辑：先 select stock FROM items WHERE id = 123 得到 5，再 UPDATE items SET stock = 3 WHERE id = 123 AND stock >= 5。但在 READ COMMITTED 隔离级别下，两次查询之间 stock 可能已被其他事务减到 4，导致 UPDATE 影响行为 0，但应用误以为“还有库存可扣”。
这不是 bug，是隔离级别本身的语义——但业务常把它当成 bug。
- 关键判断逻辑必须用
SELECT ... for UPDATE显式加行锁（InnoDB）或SELECT ... FOR NO KEY UPDATE（PostgreSQL），确保读取即锁定 - 注意
FOR UPDATE在范围查询时可能升级为间隙锁（gap lock），造成意外阻塞，测试时用SELECT * FROM performance_schema.data_locks查看实际锁类型 - 不要依赖“先查后更”的两阶段模式做核心校验；把校验逻辑下沉到
WHERE子句中，让数据库原子执行
实际中最容易被忽略的，是把应用层的“读-判-更”当成原子操作。数据库只保证单条语句的原子性，跨语句的一致性必须靠显式锁、版本控制或事务隔离级别协同实现。