MySQL：事务隔离级别、事务传播行为（简单明了版本）

MySQL事务隔离级别

1. 读未提交（Read Uncommitted）

   • 问题存在：脏读、不可重复读、幻读。
   • 描述：事务可以读取其他事务未提交的修改。可能导致数据不一致。

2. 读已提交（Read Committed）

   • 解决：脏读。
   • 问题存在：不可重复读、幻读。
   • 描述：事务只能读取已提交的数据，但同一事务多次读取同一数据可能结果不同。

3. 可重复读（Repeatable Read）

   • 解决：脏读、不可重复读。
   • MySQL对幻读的处理：通过MVCC（多版本并发控制）和间隙锁（Gap Locks）避免幻读。
   • 描述：确保同一事务中多次读取同一数据的结果一致（MySQL默认隔离级别）。

4. 串行化（Serializable）

   • 解决：所有并发问题（脏读、不可重复读、幻读）。
   • 代价：通过完全锁定相关数据实现，性能最低。

---

事务并发问题总结

隔离级别	脏读	不可重复读	幻读
读未提交	❌	❌	❌
读已提交	✅	❌	❌
可重复读（MySQL）	✅	✅	✅*
串行化	✅	✅	✅

*MySQL通过MVCC和间隙锁在可重复读级别避免幻读，但其他数据库可能不同。

---

事务传播行为（Spring框架）

事务传播行为定义了事务在嵌套方法调用中的边界规则：

1. REQUIRED

   • 如果当前存在事务，则加入该事务；否则新建一个事务。
   • 场景：默认选择，适用于大多数业务逻辑。

2. REQUIRES_NEW

   • 无论当前是否存在事务，都新建事务，并挂起当前事务（若存在）。
   • 场景：需要独立事务的操作（如日志记录，避免主事务回滚影响日志）。

3. SUPPORTS

   • 如果当前存在事务，则加入；否则以非事务方式执行。
   • 场景：查询操作，支持事务但不需要强制。

4. NOT_SUPPORTED

   • 以非事务方式执行，挂起当前事务（若存在）。
   • 场景：不涉及数据修改的操作，或需要绕过事务管理。

5. MANDATORY

   • 必须存在事务，否则抛出异常。
   • 场景：强制要求方法在事务中调用（如核心业务方法）。

6. NEVER

   • 必须在非事务环境下执行，否则抛出异常。
   • 场景：确保方法不被事务包裹（如性能敏感的非数据库操作）。

7. NESTED

   • 如果当前存在事务，则嵌套一个子事务（通过保存点实现）；否则同REQUIRED。
   • 场景：部分操作需要独立回滚（如订单创建成功后记录日志，日志失败不影响订单）。

---

总结

• 隔离级别：权衡数据一致性与性能，从低到高逐步解决脏读、不可重复读、幻读。
• 传播行为：控制事务边界，解决多方法调用时事务如何协同（提交/回滚）。
• 实际应用：MySQL默认的可重复读已满足多数场景，结合传播行为（如REQUIRED和REQUIRES_NEW）可灵活管理复杂业务逻辑。