Read Uncommitted隔离级别是否违反数据库事务的Atomicity？

先把原子性的约束范围说清楚 #

原子性从头到尾管的是事务自己的写操作最后怎么落库，它的要求非常明确：

• 一个事务里的所有修改，要么在事务提交的时候全部生效落库，要么在事务回滚的时候全部撤干净，半点儿修改都不能留在数据库里
• 绝对不允许出现事务还没做完、没到最终提交/回滚的决定时，某一半修改就被永久存到数据库、撤不回去的情况

拿你举的例子对照下：会话A的事务最后走完流程，不管是commit让a=1、b=2两个修改都生效，还是rollback把两个值都改回初始的0，整个过程没有哪笔修改是脱离事务自己的最终决定单独存在的——这完全符合原子性的要求。

为什么你会觉得这违反了原子性 #

你期待的“读出来的结果要么是全0的初始状态，要么是a=1、b=2的最终完成状态”，这根本不是原子性要管的事，是对隔离性的预期：

• 要求读操作只能看到完整一致的快照状态、看不到其他事务执行到一半的中间修改，这是隔离级别的设计目标。能完全满足你这个预期的，至少要到可串行化的隔离级别，Repeatable Read级别都不一定能完全做到。
• 你现在用的Read Uncommitted隔离级别，从设计上就主动放弃了“读操作不能碰未提交事务的中间修改”的保护：它就是要让其他会话能直接读到事务还没提交的临时值，好把读锁的开销降到最低，把并发性能拉满。这种能读到a=1、b=0的中间结果，甚至读到事务回滚就作废的脏数据的情况，本来就是这个隔离级别自带的代价，全是隔离性层面的问题，和原子性没有关系。

什么情况才算真的破了原子性 #

要是遇到下面这两种情况，才是真的违反了原子性：

• 会话A执行完set a=1之后主动回滚，结果a=1的修改没被撤掉，永久留在数据库里了
• 会话A执行到set b=2的时候数据库突然宕机，恢复之后a=1的修改被永久存下来了，b的修改因为没执行完直接丢了

这种“事务的一部分修改没跟着事务的最终结果走、单独残留下来”的情况，才是原子性要解决的问题。

内容的提问来源于stack exchange，提问作者ideawu