MySQL READ COMMITTED 与 REPEATABLE READ 怎样选择

我在排查“同一个事务里，前后两次查询为什么结果不一样”时，最后发现真正需要先决定的不是 SQL 写法，而是读一致性的目标：这次事务要不要保持同一份视图？如果要稳定地重读同一批数据，通常选择 REPEATABLE READ；如果更在意后续普通查询及时看到其他事务已经提交的变化，可以考虑 READ COMMITTED。

这里的比较限定在 InnoDB 的普通非锁定一致性读。它讨论的是快照什么时候建立、后续查询能看到什么，不把锁等待和锁优化混进同一个结论里。

快速判断：报表、校验和多步计算需要“同一事务看到同一视图”时优先考虑 REPEATABLE READ；工作流希望每次普通查询都尽量接近当前已提交数据时，READ COMMITTED 更贴合目标。

先看清两个隔离级别到底改变了什么

在 InnoDB 中，普通 SELECT 属于一致性读。它不会简单地把查询发出那一刻的磁盘内容原样返回，而是根据事务隔离级别，从多版本记录中构造当前事务可见的结果。

“更及时”不等于“更正确”，“更稳定”也不等于“所有业务都应该使用”。选择关键在于，业务代码是否把一次事务里的多次读取当成同一份事实。

READ COMMITTED：后续查询更快看到已提交变化

先用两个会话想象一个库存审核流程。会话 A 开启事务并读到库存 10；会话 B 把库存改成 8 并提交。此时会话 A 再做一次普通查询，在 READ COMMITTED 下通常会看到 B 已经提交的新版本。

-- 会话 A：设置本会话隔离级别，避免影响其他连接
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;

-- 第一次普通一致性读：示例中假定看到库存 10
SELECT stock FROM inventory WHERE sku = 'A-100';

-- 等待会话 B 提交后再次读取：普通查询可以看到新提交版本
SELECT stock FROM inventory WHERE sku = 'A-100';

-- 读完后结束事务，释放本次事务的视图
COMMIT;

它适合“分步骤处理，但每一步都希望基于较新的已提交状态”的流程，例如后台审核列表、状态轮询或不要求整段事务使用同一快照的工作流。代价是：如果事务中间夹着其他事务提交，前后两次查询可能不再代表同一时刻。

REPEATABLE READ：让一次事务保持稳定视图

REPEATABLE READ 的核心体验是“同一个事务里的普通一致性读保持可重复”。在会话 A 第一次普通查询建立事务视图后，即使会话 B 更新并提交，A 的第二次普通查询仍按自己的视图读取，不会因为 B 的提交而突然换成另一份结果。

-- 会话 A：使用 InnoDB 常见的稳定快照语义
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;

-- 第一次普通一致性读：这一步建立本事务后续普通读使用的视图
SELECT stock FROM inventory WHERE sku = 'A-100';

-- 会话 B 此时更新并提交，A 再查询仍按本事务视图读取
SELECT stock FROM inventory WHERE sku = 'A-100';

-- 多次读取结束后提交事务
COMMIT;

报表分页、跨表校验、需要比较前后结果的计算，往往更看重这种稳定性。它让同一事务内的多次读取更容易解释，但也意味着长事务可能持续依赖较旧的版本视图。事务边界应尽量贴合一次业务操作，不要为了“稳定”把连接长时间挂着。

实际项目中怎样做选择

我通常先把业务拆成三个问题，而不是直接照搬数据库默认值：

1. 多次读取要不要能互相对照？ 如果一次事务会先查明细、再查汇总，且两次结果必须属于同一观察视图，优先评估 REPEATABLE READ。
2. 后续查询要不要看到别人刚提交的结果？ 如果事务只是连续处理状态，旧视图会妨碍判断，可以评估 READ COMMITTED。
3. 事务会不会持续很久？ 长事务下，两种级别都不应该被当成替代事务设计的工具；先缩短事务范围，再决定读取语义。

可以把选择写成团队约定：稳定视图是硬要求时采用 REPEATABLE READ；及时看到已提交变化是硬要求时采用 READ COMMITTED；两者都重要时，把一次长流程拆成更小的事务，并在应用层明确每个阶段允许的数据新鲜度。

几个容易混淆的边界

• 隔离级别设置要在事务开始前完成；SET SESSION 只影响当前连接，不应误当成全局配置。
• 本文说的是普通非锁定 SELECT。带锁的读取属于另一套“当前读”讨论，不能用普通一致性读的快照结论替代。
• 不要把 READ COMMITTED 简化成“永远读到最新值”，也不要把 REPEATABLE READ 简化成“事务里所有语句都看见完全相同的世界”；语句类型和事务边界仍然重要。
• 如果业务需要跨请求保持一致，单个数据库事务通常不够，应把一致性要求落实到业务流程和数据版本设计。

相关问题

MySQL 默认应该直接改成 READ COMMITTED 吗？

不应该只因为“更新更及时”就切换。先找出业务是否依赖事务内可重复的普通读取，再用两会话实验确认行为，最后按连接池和事务边界逐步采用。

REPEATABLE READ 能解决所有并发一致性问题吗？

不能。它主要改变一致性读的可见性；锁定读取、写入冲突、跨事务业务规则仍需要单独设计。

怎样验证自己的应用到底用了哪个隔离级别？

检查连接会话的事务隔离配置，并在两个独立会话中复现“第一次读取、另一个会话提交、第二次普通读取”的时间线。验证时要记录事务是否真的在同一个连接中。

总结：READ COMMITTED 更偏向读取新提交状态，REPEATABLE READ 更偏向事务内稳定视图。先确定业务需要哪一种读法，再决定隔离级别，通常比背诵“哪个更高级”更可靠。