MySQL事务隔离级别选择

MySQL 事务隔离级别不是“越高越好”，而是决定读操作看到哪个版本、写操作需要承担多少锁等待。以 InnoDB 为例，日常 OLTP 通常先从默认的 REPEATABLE READ 开始；报表更在意减少锁影响时可以评估 READ COMMITTED；只有能接受脏读或确实需要更强串行化时，才考虑另外两档。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/innodb-transaction-isolation-levels.html

选择时先问两个问题：同一事务里的多次普通查询是否必须看到同一快照？并发写入时，业务能否接受更长的锁等待？答案通常比“读已提交还是可重复读”这句抽象比较更有用。

先看懂隔离级别真正改变了什么

普通 SELECT 和锁定读取不是一回事。InnoDB 的一致性读取会通过多版本机制给查询一个读视图；SELECT ... FOR UPDATE 或 SELECT ... FOR SHARE 则是锁定读取，关注的是当前可用于并发协调的行状态。

在 REPEATABLE READ 下，同一事务的普通一致性读取通常使用第一次读取建立的快照；在 READ COMMITTED 下，每次一致性读取都建立自己的新快照。所以前者适合需要稳定读视图的事务，后者更容易看到已经提交的新数据，但同一事务两次查询可能得到不同结果。

需要注意，事务自己的写入对自己可见，不能简单理解成“所有语句都固定在同一时刻”。如果一个流程混合普通查询、更新和锁定读取，应该把它当成读视图与当前状态并存的问题来设计。

四种级别怎样按场景取舍

MySQL InnoDB 提供四个标准级别。下面这张图把选择重点放在一致性与并发成本，而不是把级别当成固定的性能排名。

• READ UNCOMMITTED：普通读取可能读到尚未提交的旧版本或中间状态，存在脏读风险。除非数据只是粗略观测且业务明确接受不一致，否则不应作为订单、库存等核心事务的默认选择。
• READ COMMITTED：每次一致性读取获得新快照，锁定读、更新和删除的间隙锁行为更宽松，通常有利于减少一部分锁等待；代价是同一事务的两次普通查询可能看到不同提交结果，也要留意幻读。
• REPEATABLE READ：InnoDB 默认级别，同一事务的普通读取保持一致快照，适合大多数需要稳定读视图的 OLTP 流程。范围更新和锁定读取可能涉及间隙锁或临键锁，长事务会放大并发压力。
• SERIALIZABLE：约束最强；在关闭自动提交时，普通 SELECT 会被隐式按共享锁语义处理。它适合少量、边界清楚的串行化需求，不适合作为“遇到并发问题就全局切换”的通用修复。

按会话范围配置，避免误改全局

先用会话级设置验证业务行为，再决定是否调整连接池初始化参数。一次事务可以这样写：

-- 只让当前会话的下一次事务使用 READ COMMITTED
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

START TRANSACTION;
-- 这个查询每次一致性读取都可能建立新的快照
SELECT id, status FROM orders WHERE user_id = 1001;
COMMIT;

如果要让当前会话后续事务都使用某个级别，可以使用 SET SESSION TRANSACTION ISOLATION LEVEL ...；全局设置则会影响后续建立的连接，必须结合连接池、读写分离和回滚策略一起评估。不要把一次临时排障命令直接写成全局配置。

用业务场景复核选择

订单创建、库存扣减这类流程通常需要稳定的读视图和明确的锁定边界，优先保留默认级别，再通过短事务、合适索引和固定访问顺序减少等待。报表或后台列表如果更关心看到较新的已提交数据，可以在独立只读会话中评估 READ COMMITTED，不要为了报表便利改变核心写事务。

遇到“查询结果不一致”时，先记录事务边界、自动提交状态、普通读取还是锁定读取，再判断是快照预期还是并发设计问题。遇到“锁等待很长”时，先缩短事务和检查访问路径；隔离级别只改变一部分读视图和锁语义，不能替代索引与事务设计。

快速决策：默认业务先用 REPEATABLE READ；需要每次读取新快照且能接受幻读时评估 READ COMMITTED；粗略观测才考虑 READ UNCOMMITTED；明确需要更强串行化且吞吐可接受时再使用 SERIALIZABLE。

相关问题

MySQL 默认隔离级别是什么？

对 InnoDB 来说，默认是 REPEATABLE READ。但应用连接池可能在建立连接后再次设置会话级别，排查时应以实际会话配置为准。

READ COMMITTED 一定比 REPEATABLE READ 快吗？

不能这样判断。它可能减少某些锁保持时间，却也改变快照语义；最终要看事务长度、索引、写冲突和业务是否允许结果变化。

隔离级别能彻底解决死锁吗？

不能。隔离级别只影响部分读写和锁行为，死锁仍可能来自访问顺序、范围条件和事务长度，应用仍需要处理回滚与重试。