MySQL 事务隔离级别：社交恐惧症的四个阶段

在数据库的世界里，数据们也有社交问题！事务隔离级别就是控制它们互相看到对方的程度…

什么是事务隔离？

想象一下，数据库是一个繁忙的餐厅，每个事务都是一桌客人，而数据就是美食。事务隔离级别决定了：当甲桌客人正在吃饭时，乙桌客人能看到什么？

MySQL 的四种社交障碍等级

1️⃣ 读未提交 (Read Uncommitted) - 毫无隐私的偷窥狂

事务A: "我刚写了个数据，还没确定要不要提交..."
事务B: "我已经看到啦！嘿嘿嘿~"
事务A: "...我后悔了，撤回！"
事务B: "啊？那我刚才看到的是幻觉？"

特点: 一个事务可以看到其他事务未提交的数据变更。就像你在改简历，室友已经偷看到了草稿。

问题: 脏读 (Dirty Read) - 读到了别人还没确认的"脏数据"

2️⃣ 读已提交 (Read Committed) - 基本礼貌型

事务A: "我改完数据并确认提交了！"
事务B: "哦，现在我能看到你的新数据了"
事务A: "我又改了一次并提交了！"
事务B: "咦？数据怎么又变了？我刚才读的是假的吗？"

特点: 一个事务只能看到其他事务已经提交的数据。基本的社交礼仪。

问题: 不可重复读 (Non-repeatable Read) - 同一事务内多次读取，数据发生变化

3️⃣ 可重复读 (Repeatable Read) - 固执己见型 (MySQL 默认级别!)

事务A: "我要开始读取数据了，从现在起我只看到这个版本！"
事务B: "我已经修改并提交了新数据！"
事务A: "我看不见我看不见，在我这个事务里，数据还是老样子！"
事务B: "但我刚插入了新记录..."
事务A: "啊！怎么突然多了条数据？！"

特点: 同一事务内多次读取结果一致，但可能看不到新插入的行。

问题: 幻读 (Phantom Read) - 前后两次查询，数据行数发生变化

4️⃣ 串行化 (Serializable) - 完全社恐型

事务A: "我要操作这些数据了，其他人都别动！"
事务B: "好吧，我排队等你完事..."
DBA: "为什么系统这么慢？！"
所有事务: "我们在排队呢！‍♂️‍♀️‍♂️‍♀️"

特点: 事务们排队执行，完全避免并发问题。

问题: 性能低下 - 大家排队，效率当然差！

隔离级别对比表

隔离级别	脏读	不可重复读	幻读	社交能力评分
读未提交	✅ 可能	✅ 可能	✅ 可能	太开放 (0 分)
读已提交	❌ 不可能	✅ 可能	✅ 可能	基本礼貌 (5 分)
可重复读	❌ 不可能	❌ 不可能	✅ 可能*	有点固执 (8 分)
串行化	❌ 不可能	❌ 不可能	❌ 不可能	完全社恐 (10 分)

*注意：InnoDB 下的可重复读通过多版本并发控制(MVCC)解决了大部分幻读问题，但并非完全解决。

如何设置隔离级别？️

-- 全局设置
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 当前会话设置
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- 查看当前隔离级别
SELECT @@transaction_isolation;

选择建议

1. 怕出错但性能不是很重要：串行化（社恐型安全第一）
2. MySQL 默认且平衡好：可重复读（InnoDB 表现不错）
3. 追求性能且可以容忍一些问题：读已提交（礼貌型够用了）
4. 活在危险边缘：读未提交（偷窥型，不推荐）

---

“一个优秀的 DBA，就是既能保护数据的隐私权，又能让事务们高效社交的红娘！”

—— 匿名数据库管理员

---

下次面试官问你事务隔离级别，不要紧张，记住：那不过是数据库的社交障碍分级表！