在数据库系统中，REPEATABLE READ和READ COMMITTED是两种常见的事务隔离级别，它们决定了事务在并发执行时能看到其他事务的哪些修改。选择不同的级别，会直接改变业务逻辑的行为和系统的并发能力。
基本语义差异
READ COMMITTED保证一个事务只能读到已经提交的数据，避免脏读，但在同一事务中多次执行相同查询，可能由于其他事务提交而得到不同结果，也就是不可重复读。
REPEATABLE READ在此基础上进一步保证，事务启动时看到的数据快照在事务内保持一致，后续查询不会看到其他事务提交的新插入或修改后的行，从而避免不可重复读。
业务场景中的影响
对账与报表类业务
这类业务通常在一个事务中多次读取同一批数据做汇总。如果使用READ COMMITTED，中途数据被其他事务修改并提交，会导致计算结果前后不一致。此时REPEATABLE READ更合适。
高并发交易类业务
在订单或支付场景中，业务更关心不要读到未提交的脏数据，而对同一事务内完全一致的要求不高。READ COMMITTED锁占用更少，并发度更好，常被选为默认级别。
并发与锁的表现
以MySQL InnoDB为例，在REPEATABLE READ下会通过间隙锁防止幻读，可能增加锁等待；READ COMMITTED则只在索引记录上加锁，冲突更少。
| 隔离级别 | 脏读 | 不可重复读 | 并发性能 |
|---|---|---|---|
| READ COMMITTED | 避免 | 可能出现 | 较高 |
| REPEATABLE READ | 避免 | 避免 | 中等 |
代码示例：观察不可重复读
下面用伪代码展示在READ COMMITTED下同一事务内两次查询得到不同结果：
-- 事务A，隔离级别为 READ COMMITTED START TRANSACTION; SELECT balance FROM account WHERE id = 1; -- 第一次查询，结果为100 -- 此时事务B提交：UPDATE account SET balance = 200 WHERE id = 1; COMMIT; SELECT balance FROM account WHERE id = 1; -- 第二次查询，结果为200，出现不可重复读 COMMIT;
若将隔离级别改为REPEATABLE READ，第二次查询仍会返回100，因为事务A看到的是启动时的快照。
如何选择
如果业务要求统计口径在事务内稳定，或者需要避免关键数据被并发修改干扰，优先使用REPEATABLE READ。如果系统并发压力很大，且业务能容忍非重复读，使用READ COMMITTED可以获得更好吞吐。
实际选型应结合数据库实现机制与具体业务容忍度，而非单纯追求更高隔离级别。
REPEATABLE_READREAD_COMMITTED事务隔离级别修改时间：2026-07-31 00:03:21