聊聊MySQL事务隔离级别那些事儿，实例帮你理解到底差在哪儿

今天咱们就拉家常一样,聊聊MySQL里事务隔离级别这个听起来有点技术，但实际上跟咱们日常生活中“排队”、“加锁”很像的概念，想象一下，你和朋友们同时操作一个共享的Excel表格（这就是数据库），如果没点规矩，岂不是乱套了？事务隔离级别就是MySQL定的规矩，用来决定一个事务（可以理解为一系列操作，比如转账）在多大程度上能看到其他同时进行的事务所做的更改，以及如何避免由此产生的各种“奇葩”问题。

MySQL主要提供了四种隔离级别,从最宽松到最严格分别是：读未提交、读已提交、可重复读、串行化，咱们一个一个看，用同一个银行账户转账的例子来理解它们到底差在哪儿。

场景设定： 假设你（事务A）和你的朋友（事务B）同时操作同一个银行账户，账户里有1000块钱，事务A的任务是查询余额，事务B的任务是取走100块钱。

读未提交

这是最没规矩的级别,就像你俩挤在同一个电脑屏幕前看同一个Excel文件，一个人刚改了数字但还没保存（也没喊“我改好了”），另一个人一刷新就能看到这个没最终确定的修改。

• 会发生什么：

  • 时刻1：事务A查询余额，看到1000元。
  • 时刻2：事务B开始取钱，把余额从1000元改成了900元（但还没最终确认提交）。
  • 时刻3：事务A再次查询余额，这时它竟然看到了事务B还没提交的修改，余额显示900元！
  • 时刻4：万一事务B因为某种原因（比如ATM机故障）撤销了操作，余额又变回1000元，但对于事务A来说，它刚才明明看到了900元，这就产生了“脏读”，读到了不存在的数据。

• 差在哪儿： 这个级别允许读别人“未提交”的更改，风险最大，容易看到临时数据，一般不用。

读已提交

这个级别规矩了一点：你只能看到别人已经“最终保存”（提交）的数据，就像你朋友B修改完Excel并点击了“保存”之后，你刷新一下才能看到新数据。

• 会发生什么：

  • 时刻1：事务A查询余额，看到1000元。
  • 时刻2：事务B取钱，把余额改成900元（但未提交）。
  • 时刻3：事务A再次查询，它看不到B未提交的修改，余额还是1000元，这就避免了脏读。
  • 时刻4：事务B提交（确认取钱成功）。
  • 时刻5：事务A第三次查询，这时它才看到余额变成了900元。

• 新问题： 在同一个事务A里，前后两次查询（时刻1和时刻5）得到了不同的结果，这叫做“不可重复读”，对于事务A来说，它可能会困惑：“咦？我啥也没干，钱怎么少了？” 这在某些需要保证数据一致性的业务场景下是不允许的。

可重复读

这是MySQL默认的隔离级别,它定了个更严格的规矩：在你的事务开始那一刻，就像给数据库拍了个快照，无论这个事务执行多久，期间别人怎么修改提交，你每次在这个事务里读到的数据，都和快照里的内容一样。

• 会发生什么：

  • 时刻1：事务A查询余额，看到1000元（此时MySQL为A创建了一个数据快照）。
  • 时刻2：事务B取钱100元并提交成功，数据库里实际余额已是900元。
  • 时刻3：事务A再次查询余额，它看到的仍然是快照里的1000元，而不是实际的900元，这就保证了在事务A内部，多次读取同一数据的结果是可重复的、一致的。

• 新问题（MySQL下可能发生）： “幻读”，比如事务A要统计所有余额大于500的账户数，第一次查是10个，这时事务B新开了一个余额1000的账户并提交，事务A再统计一次，发现变成了11个，就像出现了“幻觉”，虽然InnoDB引擎通过MVCC（多版本并发控制）机制在很大程度上解决了幻读，但并非在所有情况下都能完全避免。

串行化

这是最严格的级别,相当于“加锁排队”，它要求事务一个个串行执行，就像银行只有一个柜台，你必须等前面的人办完所有业务才能轮到你，这样绝对不会出现脏读、不可重复读和幻读，但代价是性能最差，并发性最低。

总结一下差在哪儿：

你可以把这四个级别想象成管得越来越严的保安：

• 读未提交： 保安不管，谁都能进来看，甚至能看到别人正在写的草稿，问题多。
• 读已提交： 保安只允许你看已经正式贴出来的公告，解决了脏读，但公告可能会更新，导致你两次看到的内容不一样（不可重复读）。
• 可重复读（MySQL默认）： 保安在你第一次看公告时，给你发了一份复印件（快照），在你离开前，你只看这份复印件，内容始终不变，解决了脏读和不可重复读，但可能不知道外面又贴了新的公告（幻读）。
• 串行化： 保安一次只放一个人进去看公告，看完出来再放下一个，绝对安全，但效率最低。

选择哪种隔离级别,就是在数据的“一致性”要求和系统的“并发性能”之间做权衡，了解了它们的区别，你就能根据自己应用的实际情况，做出最合适的选择了。