事务隔离级别与并发风险

数据库的事务隔离级别，本质上是在“数据一致性”与“系统并发性能”之间做的一场交易。你几乎找不到一个能同时满足严格串行化执行又能支撑每秒百万级并发的完美方案。理解了这场交易的底层逻辑，你才能在设计库存扣减、账户转账这类核心业务时，避开那些足以造成资损的深坑。

我们先直面最血腥的战场：如果完全没有事务隔离，也就是所谓的“读未提交”（Read Uncommitted），会发生什么？一个事务可以读到另一个事务尚未提交的修改。这不仅仅是读到假数据的问题，而是你基于这个假数据做出的决策，很可能会在对方回滚后导致逻辑雪崩。比如你看到库存被扣减了，于是通知仓库停止补货，结果那个扣减事务因为余额不足回滚了，你的补货链路就断了。这就是脏读，它动摇的是数据可信度的根基。

绝大多数数据库的默认隔离级别是“读已提交”（Read Committed）。它解决了一个核心痛点：你只能看到别人提交后的数据。这避免了脏读，但带来了更隐蔽的问题。在一个事务内部，如果你两次执行相同的查询，结果可能完全不同。因为在你查询的间隙，另一个事务提交了修改。这种“不可重复读”现象，在报表生成场景是致命的。想象一下，财务在对账，同一个统计周期内，A端读出的流水总额是100万，B端读出的却是102万，对不上账的原因就在于读取期间有新的交易被提交了。

更值得警惕的是，在“读已提交”级别下，更新操作通常基于“当前读”机制。这意味着，如果你的更新语句包含条件筛选，它不会基于你事务开始时的快照，而是基于数据的最新已提交版本。在高并发下，这可能导致更新丢失或条件失效。例如，你执行 "UPDATE account SET balance = balance - 100 WHERE id = 1 AND balance >= 100"，虽然单条SQL具有原子性，但如果业务逻辑是先查询余额再决定是否扣款，那么在查询和扣款之间，余额可能已被其他事务修改，导致你的判断依据失效。

“可重复读”（Repeatable Read）是MySQL InnoDB引擎的默认级别，它通过多版本并发控制（MVCC）生成一个一致性视图。在这个视图下，事务内的查询看到的数据就像被冻结在事务开始的瞬间。这解决了“不可重复读”的问题，对账逻辑变得可靠了。然而，它引入了一个新的幽灵：“幻读”。

幻读不是指数据内容变了，而是指数据集合变了。你在事务中第一次查询返回了10条记录，第二次查询时，虽然那10条记录的值没变，但凭空多出了第11条记录。这通常发生在有新的INSERT操作提交时。幻读对库存管理、排期系统影响极大。比如你试图锁住今天所有的预约记录，但在你锁定过程中，又有人插入了新的预约，导致你漏掉了这条“幻影”。

针对幻读，InnoDB引入了“间隙锁”（Gap Lock）机制。当你执行 "SELECT ... FOR UPDATE" 时，不仅锁住了存在的行记录，还锁住了索引记录之间的间隙。这能有效阻止其他事务插入新数据，但代价是并发性能的急剧下降。因为间隙锁之间很容易冲突，导致大量事务进入锁等待状态，甚至引发死锁。很多系统从MySQL迁移到PostgreSQL时，会发现后者的“可重复读”并不像前者那样能完全杜绝幻读，这正是实现机制的差异，需要架构师格外注意。

“串行化”（Serializable）是隔离级别的最高形态，它强制事务按顺序执行，仿佛并发不存在。它彻底解决了脏读、不可重复读和幻读。但在现代互联网架构中，这基本等同于系统自杀。它放弃了数据库最宝贵的并发能力，将所有读写操作变成了排队。除非是极其核心且并发量极低的金融清算场景，否则极少在生产环境全局使用。通常我们更倾向于通过应用层的分布式锁或特定的事务边界设计来局部替代串行化。

要真正驾驭并发，不能只背定义，要理解背后的两种实现哲学：悲观锁与乐观锁。悲观锁假设冲突必然发生，先取锁再操作，如 "SELECT FOR UPDATE"。它在冲突激烈的场景下避免了回滚开销，但容易造成死锁和连接池耗尽。乐观锁假设冲突很少发生，只在提交时检查版本号或时间戳。它性能极高，但在高冲突场景下会导致大量事务反复重试，吞吐量反而骤降。

这里有一个容易被忽视的陷阱：在MVCC机制下，事务看到的快照是旧数据，而写操作必须基于最新版本。如果你的业务逻辑是“读取旧版本数据，经过复杂计算，再写回数据库”，那么在没有显式加锁或使用乐观锁的情况下，你的写操作极大概率会覆盖掉别人的更新。这就是经典的“丢失更新”问题。解决它的标准范式是使用CAS（Compare And Swap）操作：

-- 乐观锁更新范式
UPDATE product 
SET stock = stock - 1, version = version + 1 
WHERE id = 1 AND version = 5;
-- 检查受影响行数，若为0则说明版本号已变，需要重试

这段代码看似简单，但它揭示了并发控制的精髓：将“读取-判断-写入”的复合操作原子化，把冲突检测的时机推迟到提交瞬间，却通过版本号保证了绝对的数据完整性。

在真正的高并发场景下，比如秒杀系统，我们几乎不会依赖数据库的“可重复读”甚至“读已提交”来解决所有问题。因为数据库的锁机制太重了。常见的策略是“读已提交”加“Redis预扣库存”。将热点数据的并发争抢前置到Redis这个单线程的高速缓存中，利用Redis的原子操作完成核心扣减，数据库仅作为最终一致性的持久化兜底。此时数据库的隔离级别甚至可以降级为“读已提交”，因为核心的并发冲突已经被Redis层吸收掉了。

另一个容易被忽视的风险是长事务。在“可重复读”级别下，一个长事务持有的Read View（快照）迟迟不释放，会导致undo log（回滚日志）不断膨胀，甚至拖垮主库。因为数据库必须保留那个时间点的旧版本数据，即使那些数据在物理上已经被删除了。这就是为什么DBA总是强调事务要尽快提交，避免在事务中调用RPC或进行复杂文件处理。

理解事务隔离级别，最终要落实到你的业务容忍度上。如果你的业务是用户评论列表，偶尔出现几条“幻读”完全无伤大雅，用“读已提交”换取高性能是明智的。但如果你的业务是银行转账或机票预订，哪怕一次“丢失更新”都是不可接受的，那么就必须通过“可重复读”加“显式行锁”甚至“串行化”来兜底。没有银弹，只有基于场景的权衡。真正资深的开发者，会在SQL语句的细微之处，通过精准的索引设计和锁范围控制，在毫厘之间拿捏并发与安全的平衡。