PostgreSQL中不可重复读与幻读为何会引发问题？

为什么这两类读问题会有负面影响？ #

• 事务逻辑彻底失控：比如你在一个事务里先查用户余额是100块，接着要转走50块，结果操作前再查余额变成了80——这是因为另一个并发事务刚转走了30。这时候你的转账逻辑基于错误的初始值执行，最终用户余额会变成30（100-50），但实际应该是50（80-50），直接搞出数据不一致。
• 业务规则直接被击穿：电商场景里，你先查库存有10件，接着生成10个订单，结果提交前库存变成了8——另一个事务卖了2件。这就导致超卖，完全违反了库存不能为负的规则，后续还要花精力处理退款、用户投诉。
• 排查难度拉满：这类问题是并发下的偶发情况，单测根本复现不了，出问题后你得翻一堆事务日志才能找到哪两个事务冲突了，维护成本极高。

为什么不能“再次请求就看到已发生的变更”？ #

核心在于事务需要一个稳定的执行环境：

• 事务的本质是把一系列操作打包成一个“原子单元”，让开发者可以放心地认为这段时间里只有自己的事务在操作数据库。如果事务执行过程中每次查询都能看到其他事务的变更，那事务内的逻辑就完全不可预测了——你写的代码今天跑正常，明天可能就因为某个并发操作出bug，根本没法保证正确性。
• 举个实际的例子：你做一个优惠发放逻辑，先查用户是否满足满减条件，然后发优惠券。第一次查满足，但发券前另一个事务改了用户的消费记录，导致第二次查不满足，这时候优惠券已经发出去了，相当于白送了优惠，损失成本。
• 当然，PostgreSQL不是不让你看实时变更——它提供了不同的隔离级别，比如「读已提交」级别下就能看到其他已提交事务的变更，但这会牺牲隔离性，风险得你自己扛。

内容的提问来源于stack exchange，提问作者Panagiotis Foliadis