事务隔离级别不应该只背成四行表格。真正要判断的是：一个业务到底要防哪类并发异常，愿意为一致性付出多少锁、版本和等待成本。
InnoDB 的隔离能力不是单靠一个开关实现的，而是 MVCC、当前读、记录锁、间隙锁和 next-key lock 共同作用的结果。隔离越强不一定越好，关键是知道风险和代价分别落在哪里。
先把机制边界说清楚
隔离级别定义的是并发事务之间互相能看到什么。InnoDB 通过 MVCC、当前读、记录锁、间隙锁和 next-key lock 实现隔离。隔离越强，不代表越适合所有业务；它只是把一致性风险和并发代价放在不同位置。
整体路径
上面这张图先看入口和边界：宏观上，普通快照读主要依赖 MVCC，当前读和写入则依赖锁。RC 下每条语句看到新的已提交视图，RR 下事务内快照更稳定，并通过 next-key lock 在当前读场景减少幻读。Serializable 则进一步把读也纳入更强约束。
第二张图再看结构关系。
底层流程
底层拆解先看数据结构。「事务隔离级别」至少涉及下面几类结构：
- ReadView：RC 和 RR 快照差异的核心。
- 记录锁：锁住已经存在的索引记录。
- 间隙锁：锁住索引记录之间的插入空间。
- next-key lock：记录锁和间隙锁组合。
- 当前读：需要读取最新并可能加锁的读写路径。
再看完整执行流程：
- 业务开启事务并选择隔离级别。
- 普通 select 根据隔离级别创建或复用 ReadView。
- update、delete、select for update 走当前读并加锁。
- InnoDB 根据索引范围决定记录锁、间隙锁或 next-key lock。
- 事务提交后释放行锁并结束可见性边界。
取舍与边界
版本差异上，InnoDB 默认隔离级别长期是 REPEATABLE READ。MySQL 8.0 的实现细节和可观测性更好，但 RC 与 RR 在 ReadView 时机、间隙锁使用上的核心差异依然存在。RC 下一般减少范围查询的间隙锁，但外键检查和唯一性检查等场景仍可能使用间隙锁。
隔离级别的短板是名字容易造成误解。RR 不等于所有业务逻辑都不会并发错；RC 也不等于一定不安全。库存扣减、余额变更、唯一约束、幂等写入，往往还需要显式锁、唯一索引或业务状态机配合。
典型问题：用机制化例子排查
并发校验类逻辑最容易踩隔离级别的边界：先 select 判断不存在，再 insert 写入，并不天然等于安全。真正可靠的约束通常要落到唯一索引、当前读或幂等状态机上。
可以落到这些动作：
- 先定义业务要防脏读、不可重复读、幻读，还是写偏斜和重复提交。
- 读多写少且追求新鲜度的业务可以评估 RC，但要检查锁语义变化。
- 关键一致性不要只依赖隔离级别，优先使用唯一索引、状态机和幂等约束。
- 调整隔离级别前必须回归当前读、范围更新和死锁场景。
收束：隔离级别是成本选择
事务隔离级别不是越高越好，而是把一致性要求翻译成 MVCC 和锁成本。会选隔离级别，才算真正开始做数据库架构设计。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MySQL」，欢迎关注公众号 「十三Tech」。后续会继续按机制、图解和实战排查这条线更新。
