4. 事务的执行过程@ACD

introduction

事务最出名的特点, 就是那个"要么执行/要么全都不执行(原子性)", "commit一定落盘(持久性)". 这两个重要特性全是靠undo/redo/binlog三者的合作完成的.

"事务改的数据" 是指什么数据?

事务具体怎么执行的方案是InnoDB负责的, InnoDB整出了一个叫做Buffer Pool的东西, 这种东西的原理是把磁盘上的页映射到内存里, 于是虽然磁盘读写比较慢, 但是内存读写却是相当的快 每次事务想要修改某个属性, 我们会先把这个对象从磁盘里加载到内存的Buffer Pool里, 然后我们开始执行事务内容

• 事务修改的时候直接修改到Buffer Pool, 加锁也是锁住Buffer Pool里的东西, 直到commit之前一直都只是在内存里

• 每执行一条语句, 这次修改都会直接改对应的内存页

  • 此操作会响应的生出一个相反的语句, 追加到undolog里面, 例如你执行了一条insert, 那么相应的就会有一条delete在undolog里

  • 此操作同样会被记录在redolog里, 我们记录下每一个操作的目的是为了在落盘之前如果宕机了, 就必须恢复之前执行的内容, 并把redolog设置成prepare状态

原子性是怎么做到的

[如果你想回滚] : 也就是事务不要了, 这个时候我们需要将内存恢复原状, 因为这个内存是直接一一对应着磁盘的, 我们想要查盘每次都会先走这个内存, 因此不能就把这个内存搞脏了就放在这儿, 因此我们把undolog执行一遍, 将内存恢复原状

[如果你想commit] : 这个时候我们的修改还停留在内存的buffer pool里, 我们首先写上binlog, 接着执行一条fsync将这些内存里的东西再一次性刷回硬盘里. 并把redolog的状态设置成commit, 代表这条数据已经在硬盘里了

如何保证提交一定落盘

[如果你还没到commit哪一步就crash了] : 我们能在redolog里找到一些状态为prepare的语句, 这些语句应该被撤回, 操作undolog撤回

[如果你已经commit, 但是还没来得及落盘就crash了] : 那么我们同样会在redolog里找到一些状态为prepare语句, 但于此同时binlog里也有这些语句:

• 如果binlog里有, 说明系统认为这些语句应该被执行

• 但于此同时redolog状态为prepare, 说明他们还没被执行, 因此执行