登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  MySQL

MySQL 事务隔离级别怎样影响一致性读

来源:17golang原创

时间:2026-10-14 08:55:40 317浏览 收藏

MySQL 事务隔离级别真正影响的,不只是“能不能读到别人刚提交的数据”,还包括 InnoDB 什么时候建立一致性读快照,以及普通读取是否需要用锁把并发修改挡住。最常见的选择是保留默认的 REPEATABLE READ;如果业务更看重同一事务内的实时提交,则考虑 READ COMMITTED。需要强约束时才评估 SERIALIZABLE,不要把它当成通用加速开关。

官方文档:https://dev.mysql.com/doc/refman/8.4/en/innodb-consistent-read.html

先分清一致性读和锁定读

InnoDB 的普通 SELECT 默认是一致性读:它通过多版本机制给语句一个快照,不为读取的行主动加锁。因此,其他事务仍可以同时更新数据。SELECT ... FOR UPDATE、SELECT ... FOR SHARE 则属于锁定读,讨论的是当前版本和锁,而不是普通快照。

这一区分很重要:隔离级别主要改变一致性读的可见性与并发约束,不能用一句“级别越高,查询越新”概括。高隔离通常意味着更稳定的观察结果,也可能带来更多等待或冲突。

四种隔离级别分别承担什么压力

级别普通一致性读特点适合的压力
READ UNCOMMITTED可能读到未提交修改,隔离最弱只在能容忍脏读的特殊分析场景评估
READ COMMITTED同一事务的每次一致性读建立新快照更关注读取新提交数据的在线业务
REPEATABLE READ同一事务通常复用第一次一致性读建立的快照报表、订单处理和需要稳定重复读取的默认场景
SERIALIZABLE以更严格的并发约束换取更强一致性少量强约束事务,需谨慎评估锁等待

MySQL 8.4 InnoDB 的默认级别是 REPEATABLE READ。它不是让整个数据库永远停在一个时间点,而是让事务中的普通一致性读对同一个快照保持稳定;事务内自己已经修改的行仍会按当前事务语义反映出来。

MySQL InnoDB 事务会话、普通 SELECT、一致性读快照、已提交版本与并发提交之间的静态关系说明图
图1:InnoDB 一致性读与事务快照的静态关系说明图,不是运行截图。

用两个会话观察 RR 和 RC 的快照边界

下面是可改写的最小观察模板。先在测试表准备一行数据,然后打开会话 A 和会话 B。示例只用于说明语义,不代表已经在某个环境执行。

-- 会话 A:设置隔离级别并开始事务
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;

-- 普通 SELECT 建立本事务的一致性读快照
SELECT id, stock FROM inventory WHERE id = 1;

-- 会话 B:提交对同一行的更新后
-- 会话 A 再执行下面的查询,RR 通常仍看到原快照
SELECT id, stock FROM inventory WHERE id = 1;

-- 如需观察 RC,请在新事务中改成 READ COMMITTED
-- 每次一致性读都可能看到新的已提交快照
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

在 REPEATABLE READ 下,事务第一次普通读取决定了后续一致性读的观察基线;想获得更新快照,通常要先提交当前事务,再开始新事务。在 READ COMMITTED 下,每次一致性读都建立自己的新快照,所以同一事务中的两次查询可能看到不同的已提交结果。

按业务目标选择,而不是只追求更高等级

如果是分页报表、账单核对或需要多次读取同一批数据的处理,稳定快照更重要,默认的 REPEATABLE READ 往往更容易解释。实时看板、短事务接口若更关心刚提交的数据,可以评估 READ COMMITTED,但要接受同一事务前后两次查询结果变化。

只有当业务确实需要把并发读写约束得更紧时,才考虑 SERIALIZABLE。隔离级别解决不了错误的事务边界、长事务或缺少索引;长时间持有事务本身就会增加版本保留、锁等待和排查难度。

MySQL READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE 与快照策略和业务压力的静态对照图
图2:四种隔离级别与读取压力的静态对照图,不是数据库界面截图。

几个容易误判的边界

  • 普通 SELECT 不等于加锁:需要阻止并发修改时,明确使用锁定读并评估索引和等待。
  • 快照不覆盖所有语句:一致性读的快照语义主要针对事务中的普通 SELECT,不能机械套到所有 DML。
  • 自己修改的行是特殊情况:事务内先更新再查询,可能同时看到自己修改的最新版本和其他行的历史版本。
  • DDL 不是普通并发读取:例如表被删除后,InnoDB 不能继续用旧表完成一致性读。

快速判断清单

需要稳定重复读取时,先看 REPEATABLE READ;需要每次普通查询都追踪新提交时,评估 READ COMMITTED;能容忍脏读才考虑 READ UNCOMMITTED;只有明确的强并发约束才评估 SERIALIZABLE。最后再检查事务是否过长、查询是否有合适索引,以及业务是否把普通读和锁定读混用了。

常见问题

为什么 RR 下第二次 SELECT 没看到别的事务刚提交的数据?

如果两次都是一致性读,第二次通常继续使用事务第一次一致性读建立的快照;提交当前事务后重新开始,才会建立新的观察边界。

把隔离级别调高就一定更安全吗?

它只改变并发读写的可见性与约束,不能替代正确的事务边界、权限控制、唯一约束和错误处理。级别越严格,也可能带来越多等待。

小结

MySQL 一致性读的关键是快照,而隔离级别决定快照何时建立、能看到哪些已提交版本以及并发约束有多强。默认的 REPEATABLE READ 偏向稳定观察,READ COMMITTED 偏向更新可见性;先明确业务要稳定还是要新鲜,再决定是否改变默认设置。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>