事务隔离级别解决脏读、不可重复读和幻读问题：读未提交允许脏读；读已提交避免脏读但存在不可重复读；可重复读避免前两者，InnoDB通过Next-Key Lock抑制幻读；串行化杜绝所有问题但性能最差。
事务隔离级别决定了多个并发事务之间如何相互影响，核心是解决脏读、不可重复读和幻读问题。不同数据库默认隔离级别不同（如MySQL默认可重复读，PostgreSQL默认读已提交），而底层实现机制（尤其是锁策略）直接影响性能与一致性。
四大隔离级别与典型现象
每种隔离级别通过限制事务能看到的数据范围来避免特定并发问题：
- 读未提交（Read Uncommitted）：最低级别，允许读取其他事务尚未提交的修改——可能产生脏读。实际生产极少使用。
- 读已提交（Read Committed）：只能读到已提交的数据，避免脏读；但同一事务内多次查询可能返回不同结果（因其他事务已提交），即不可重复读。
- 可重复读（Repeatable Read）：保证同一事务中多次读取相同数据结果一致，避免脏读和不可重复读；但无法阻止幻读（新插入行导致结果集变化）。MySQL InnoDB 通过间隙锁（Gap Lock）+ 行锁组合，在多数场景下也解决了幻读。
- 串行化（Serializable）：最高级别，强制事务串行执行，通过加范围锁或表级锁避免所有并发问题，但并发性能最差。
InnoDB 的锁机制与隔离级别关联
MySQL 默认使用 InnoDB 引擎，其锁行为与隔离级别深度绑定：
- 在 读已提交 下，普通 SELECT 不加锁（快照读），UPDATE/DELETE 等语句只对涉及的行加记录锁（Record Lock），不锁间隙，因此可能出现幻读。
- 在 可重复读 下，InnoDB 默认启用 Next-Key Lock（记录锁 + 间隙锁），锁定索引记录及其前隙，有效防止其他事务在范围内插入新行，从而抑制幻读。
- 显式加锁语句（如
SELECT ... FOR UPDATE或LOCK IN SHARE MODE）在任一隔离级别都会触发当前读，并按规则加锁，不受 MVCC 快照影响。
常见面试陷阱与辨析要点
面试官常通过具体 SQL 场景考察对“现象—级别—锁型”链条的理解：
- 问：“为什么可重复读下还出现幻读？” → 要区分 MVCC 快照读（无幻读）与 当前读（如带 WHERE 条件的 UPDATE，可能触发间隙锁失效或锁范围不足）。
- 问：“RR 级别下，UPDATE 非索引字段会锁全表吗？” → 不会。InnoDB 锁定的是索引，若 WHERE 条件无索引，会走主键聚簇索引全扫描，等效于锁所有行（但仍是行锁，非表锁）。
- 问：“两个事务同时 INSERT 相同唯一键，谁失败？” → 唯一键冲突检测发生在引擎层，先获得插入意向锁（Insert Intention Lock）并尝试加唯一索引记录 S 锁，冲突方被阻塞或报错，与隔离级别无关。
实战建议：如何选择与调优
隔离级别不是越高越好，需权衡一致性需求与并发吞吐：
- 绝大多数 Web 应用使用 读已提交 即可，兼顾正确性与性能；金融类强一致性场景再考虑可重复读。
- 避免长事务：事务越长，持有锁时间越久，越易引发阻塞与死锁；尽量将非DB操作（如HTTP调用）移出事务体。
- 善用索引：WHERE/JOIN 条件务必走索引，否则锁范围扩大，甚至退化为临键锁覆盖整个索引区间。
- 监控锁等待：通过
SHOW ENGINE INNODB STATUS或 performance_schema.data_locks 分析锁类型与持有者。
