以steam游戏为例理解脏读，不可重复读，幻读

转载自暴躁的外皮博文
MySQL事务隔离级别有以下四种：

• Read Uncommited 未提交读
• Read Commited 提交读
• Repeatable Commited 可重复读
• Serializable 串行化/序列化

脏读

在Read Uncommitted级别下存在，使用Read Committed级别以解决

大白话解释：事务A未提交时，事务B就读了事务A未提交的数据
举例：A君准备买了一款新游戏，填写了购买申请，但是犹豫再三，到底要不要提交，这时候A君的老婆通过select订单详情居然发现了A君的申请，顿时大怒。但实际上A君后来删除了申请，虽然没买游戏，但是A君老婆还是认为已经有了订单，为此吵了一大架。

不可重复读

在Read Committed级别下存在，使用Repeatable Read级别以解决

大白话解释：事务B一直在关注一条数据，事务A去修改这条数据，修改后立刻提交，但是在修改期间，事务B一直未提交，多次查询该条数据，但是发现结果不一样，不知道该相信哪一个结果。
举例：
这一天A君老婆心情不错，允许A君可以购买50元以下的游戏，A君老婆一直通过后台来监控是否超标。于是A君下单，并提交了订单，但是价格选高了，是总价100元的游戏，此时A君老婆发现了这条100元的订单，觉得很生气，但是此时并没有关闭查询界面（事务未提交）。此时A君也意识到选错了，修改了订单并提交。此时A君老婆继续查询订单，发现价格变成了50元，这下不知道该相信谁了，觉得其中有诈，虽然A君没有超标并买了游戏，但还是被老婆怀疑了。

幻读

在Repeatable Read级别下存在，使用Serializable级别以解决 （如果是Mysql，则得益于MVCC机制，在Repeatable Read下就可解决）

大白话解释：事务B先按条件查询了条件S下的数据数量（B不提交），此时事务A向表中多次插入和删除符合条件S的数据，每次修改后马上提交，事务B多次以条件S检索数据数量，但是发现数量不一样了，不知道该相信哪一个结果。
举例：
A君老婆允许A君再购买2款游戏，通过订单系统一直查询A君的游戏数量，A君提交了2款游戏的订单，但是网络延迟导致多提交了2款游戏的订单，A君马上又删除了多余的订单。在此期间A君老婆通过订单系统先看到了2条订单，之后查询又出现了2条订单，再查又发现多出的2条订单不见了，不知道A君到底买了几款游戏，觉得A君老是这么不靠谱，和A君大吵了一架。

总结

• 以上3种情况的发生，均是通过某个一直未提交的事务发现的。
• 脏读、不可重复读，是在单行数据产生，幻读在多行数据中产生。
• 幻读中出现的异常数据称为“幻影行”
• 不可重复读和幻读发生的场景很像：均是一个事务在不停提交，另一个事务一直不提交。
• 不可重复读和幻读容易搞混，可以这么理解：不可重复读是一条数据出现了“幻影结果”，幻读是一个表中出现了幻影行。
• 由于不可重复读和幻读产生情况很像，所以Mysql的MVCC机制就能一次都把他们解决了。

————————————————
版权声明：本文为CSDN博主「暴躁的外皮」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/k99sam/article/details/84858689