并发事务问题 + 事务四大隔离级别

一、并发事务会产生的三大问题假设现在有两个事务 T1、T2 同时操作同一份数据1. 脏读Dirty Read定义一个事务读到了另一个事务未提交的修改数据。 场景T2 更新数据但没 commitT1 读取到这条修改后的数据随后 T2 回滚T1 读到的数据就是无效脏数据。 危害基于脏数据做计算、业务逻辑全部出错。2. 不可重复读Non-Repeatable Read定义同一个事务内两次读取同一行数据中间被其他事务提交修改两次结果不一致。 场景T1 开启事务第一次查询 id1 余额 100T2 更新余额为 200 并提交T1 再次查询余额变成 200。 核心区别脏读是读未提交数据不可重复读是读已提交但同一事务前后数据变了针对单行更新。3. 幻读Phantom Read定义同一个事务内两次按条件范围查询中间其他事务插入 / 删除数据并提交两次结果行数不一样。 场景T1 查询余额 200 的用户有 3 条T2 插入一条余额 100 的新用户并提交T1 再次同条件查询查出 4 条像凭空多出来一行 “幻影数据”。 核心区分不可重复读聚焦已有行被 update幻读聚焦新增 / 删除行范围查询行数变化。二、SQL 标准四大事务隔离级别从低到高读问题越少并发性能越差隔离级别越高并发冲突越少但锁竞争加剧、吞吐下降是一致性与性能的取舍。1. 读未提交 Read Uncommitted允许读取未提交数据存在问题脏读、不可重复读、幻读全部出现MySQL InnoDB 不实际使用无业务场景。2. 读已提交 Read CommittedRCOracle 默认只能读到其他事务已经提交的数据解决脏读仍存在不可重复读、幻读InnoDB 机制每次读取都会生成新的 Read View同一事务两次查询看到不同快照。3. 可重复读 Repeatable ReadRRMySQL InnoDB 默认解决脏读、不可重复读仍存在当前读下会出现幻读快照读不会核心机制事务第一次快照读时生成 Read View整个事务复用同一个快照保证同一事务多次读取结果不变MySQL 通过间隙锁 临键锁在当前读update/delete/select for update场景下解决幻读这是 MySQL 区别于标准 SQL 的地方。4. 串行化 Serializable最高隔离级别所有并发问题全部解决脏读、不可重复读、幻读都消失实现方式读操作加共享锁写操作加排他锁读写互斥事务串行执行完全不并发缺点并发极低大量锁等待、死锁仅金融核心少量场景使用普通业务禁用。三、关键补充面试加分点1. InnoDB 两种读取方式区分幻读快照读普通 select不加锁依赖 MVCC 多版本并发控制RR 隔离级别下不会出现幻读当前读select ... for update /update/delete走行锁 间隙锁锁住整个查询范围阻止其他事务插入杜绝幻读。2. 隔离级别取舍线上开发经验绝大多数业务使用默认RR 可重复读平衡一致性和并发性能不需要手动修改部分大数据报表、统计场景使用 RC 读已提交减少锁等待读取最新已提交数据不推荐串行化并发吞吐量会大幅下降读未提交无使用场景。3. MVCC 与隔离级别关系RC、RR 底层依靠 MVCC 实现不加锁的读通过 undo 日志版本链、Read View 控制可见数据 串行化抛弃 MVCC全部走锁机制性能最差。简短总结并发事务三大问题脏读读未提交、不可重复读同一行被更新、幻读范围新增删除 SQL 四种隔离级别由低到高读未提交、读已提交、可重复读、串行化 MySQL InnoDB 默认 RR 可重复读依靠 MVCC 解决脏读与不可重复读配合临键锁解决当前读幻读隔离级别越高一致性越强但并发性能越低普通业务优先使用 RR。