MySQL事务隔离级别按严格性递增分为READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE，分别容忍脏读、不可重复读、幻读的程度不同，核心在于MVCC与锁机制的协同实现。
MySQL 的事务隔离级别决定了一个事务能看到其他并发事务的哪些修改，直接影响数据一致性、并发性能和锁行为。核心区别在于对“脏读”“不可重复读”“幻读”这三类并发问题的容忍程度。
READ UNCOMMITTED（读未提交）
最低隔离级别，事务可以读取其他事务尚未提交的数据。
- 允许脏读：比如事务 A 修改了某行但未提交，事务 B 此时能读到这个“脏”值；若 A 回滚，B 就读到了不存在的数据
- 不加行级读锁，写操作仍需加行锁（如 UPDATE），但读不阻塞写，写也不阻塞读
- 实际生产极少使用，仅在对一致性要求极低、追求极致吞吐的场景（如日志统计临时分析）中偶见
READ COMMITTED（读已提交）
Oracle 默认级别，MySQL 在开启 innodb_read_committed 或使用一致性非锁定读（consistent non-locking read）时生效（需配合 MVCC）。
- 避免脏读：只能读到已提交事务的数据
- 仍可能发生不可重复读：同一事务内多次 SELECT 同一行，可能因其他事务中途提交更新而得到不同结果
- 每次 SELECT 都会生成新快照（基于语句执行时刻的已提交版本），不复用事务开始时的快照
- InnoDB 中，普通 SELECT 不加锁，UPDATE/DELETE 仍按需加行锁
REPEATABLE READ（可重复读）
MySQL InnoDB 默认隔离级别，通过 MVCC + Next-Key Lock 实现较强一致性保障。
- 避免脏读和不可重复读：事务启动时创建一致性视图（read view），整个事务期间都基于该快照读取数据
- 基本解决幻读：InnoDB 使用 Next-Key Lock（行锁 + 间隙锁）阻止其他事务在查询范围内插入新行，从而抑制多数幻读场景
- 注意：严格意义上的幻读仍可能出现在“先查后插”且未加锁的场景（如 SELECT ... FOR UPDATE 缺失时），需显式加锁或业务逻辑规避
- 快照读（普通 SELECT）不加锁；当前读（SELECT ... LOCK IN SHARE MODE / FOR UPDATE、UPDATE、DELETE）会加锁并触发最新版本读取
SERIALIZABLE（串行化）
最高隔离级别，强制事务串行执行，完全避免并发异常。
- 所有 SELECT 隐式转化为 SELECT ... LOCK IN SHARE MODE，即自动加共享锁
- 彻底避免脏读、不可重复读、幻读，但也极大降低并发度：读写互斥、写写互斥
- 适合极小并发、强一致性刚需场景（如金融核心账务校验），一般不作为默认选项
- 实际中常被更灵活的方案替代，例如应用层加分布式锁或使用乐观锁+重试
选择隔离级别本质是在一致性与性能之间权衡。大多数业务用 REPEATABLE READ 足够，关键操作再配合适当的锁或版本控制。理解每种级别背后的锁机制和 MVCC 行为，比死记定义更重要。
