MySql--undo日志（上）

具体细节 请去掘金购买《MySQL 是怎样运行的：从根儿上理解 MySQL》

事务回滚的需求

• 1.这些为了回滚而记录的这些东西称之为撤销日志--undo log
• 2.查询操作（SELECT）并不会修改任何用户记录，所以在查询操作执行时，并不需要记录相应的undo日志

事务id

给事务分配id的时机

• 1.如果某个事务执行过程中对某个表执行了增、删、改操作，那么InnoDB存储引擎就会给它分配一个独一无二的事务id
• 2.对于只读事务来说，只有在它第一次对某个用户创建的临时表执行增、删、改操作时才会为这个事务分配一个事务id(比如explain 语句会创建临时表)
• 3.对于读写事务来说，只有在它第一次对某个表（包括用户创建的临时表）执行增、删、改操作时才会为这个事务分配一个事务id

事务id是怎么生成的

• 1.它的分配策略和我们前边提到的对隐藏列row_id的分配策略大抵相同。
• 2.服务器会在内存中维护一个全局变量，每当需要为某个事务分配一个事务id时，就会把该变量的值当作事务id分配给该事务，并且把该变量自增1
• 3.每当这个变量的值为256的倍数时，就会将该变量的值刷新到系统表空间的页号为5的页面中一个称之为Max Trx ID的属性处，这个属性占用8个字节的存储空间。
• 4.当系统下一次重新启动时，会将上边提到的Max Trx ID属性加载到内存中，将该值加上256之后赋值给我们前边提到的全局变量
• 5.先被分配id的事务得到的是较小的事务id，后被分配id的事务得到的是较大的事务id。

trx_id隐藏列就是事务id

undo日志的格式

• 1.nnoDB存储引擎在实际进行增、删、改一条记录时，都需要先把对应的undo日志记下来
• 2.一般每对一条记录做一次改动，就对应着一条undo日志，但在某些更新记录的操作中，也可能会对应着2条undo日志
• 3.undo日志会被从0开始编号
• 4.undo 日志是放在页面类型为FIL_PAGE_UNDO_LOG的页面中。

INSERT操作对应的undo日志

• 1.因为需要回滚时候主要是删除该记录，因此日志主要是记录该记录的主键。
• 2.end of record:本条undo日志结束，吓一跳开始时在页面中的地址
• 3.undo type:undo的类型
• 3.undo no：undo的编号：在一个事务中是从0开始递增的，也就是说只要事务没提交，每生成一条undo日志，那么该条日志的undo no就增1
• 4.table id：本条undo日志对应的表
• 5.主键各列的信息：包含列占用的存储空间大小和真实值
• 6.start of record 上一条undo日志结束，本条开始时在页面中的地址。

DELETE操作对应的undo日志

• 1.被删除的记录其实也会根据记录头信息中的next_record属性组成一个链表,只不过这个链表中的记录占用的存储空间可以被重新利用，所以也称这个链表为垃圾链表
• 2.Page Header部分有一个称之为PAGE_FREE的属性，它指向由被删除记录组成的垃圾链表中的头节点
• 3.当我们删除一条正常记录的时候需要先将该记录的delete_mask标识位设置为1，在删除语句的事务提交前先不加入垃圾链表
• 4.当该删除语句所在的事务提交之后，会有专门的线程后来真正的把记录移动到垃圾链表，并调整页面信息和目录信息--这个阶段叫purge
• 5.删除记录是加入到垃圾链表的头结点，会跟着修改PAGE_FREE属性的值
• 6.PAGE_GARBAGE：属性记录着当前页面中可重用存储空间占用的总字节数。每当有已删除记录被加入到垃圾链表后，都会把这个PAGE_GARBAGE属性的值加上该已删除记录占用的存储空间大小
• 7.PAGE_FREE指向垃圾链表的头节点，之后每当新插入记录时，首先判断PAGE_FREE指向的头节点代表的已删除记录占用的存储空间是否足够容纳这条新插入的记录，如果不可以容纳，就直接向页面中申请新的空间来存储这条记录
• 8.如果可以容纳，那么直接重用这条已删除记录的存储空间，并且把PAGE_FREE指向垃圾链表中的下一条已删除记录
• 9.如果新插入的那条记录占用的存储空间大小小于垃圾链表的头节点占用的存储空间大小，那就意味头节点对应的记录占用的存储空间里有一部分空间用不到，这部分空间就被称之为碎片空间
• 10.碎片空间占用的存储空间大小会被统计到PAGE_GARBAGE属性中，这些碎片空间在整个页面快使用完前并不会被重新利用，不过当页面快满时
  如果再插入一条记录，此时页面中并不能分配一条完整记录的空间，这时候会首先看一看PAGE_GARBAGE的空间和剩余可利用的空间加起来是不是可以容纳下这条记录，如果可以的话，InnoDB会尝试重新组织页内的记录，重新组织的过程就是先开辟一个临时页面，把页面内的记录依次插入一遍，
  因为依次插入时并不会产生碎片，之后再把临时页面的内容复制到本页面，这样就可以把那些碎片空间都解放出来
• 11.综上所述，设计的undo日志只是针对阶段一事务未提交的时候设计回滚段。
• 12.delete类型比insert类型多了该记录的旧的trx_id，roll_pointer，索引列各列信息
• 13.索引列各列信息这部分信息主要是用在事务提交后，对该中间状态记录做真正删除的阶段二，也就是purge阶段中使用的

roll_pointer隐藏列的含义

• 1.undo日志是对应一个记录的，虽然undo no是以一个事务开始的
• 2.roll_pointer每次都指向记录的最新undo日志，而undo日志指向之前老的undo日志

UPDATE操作对应的undo日志--不更新主键的情况--就地更新（in-place update）

• 1.对于被更新的每个列来说，如果更新后的列和更新前的列占用的存储空间都一样大，那么就可以进行就地更新
• 2.有任何一个被更新的列更新前比更新后占用的存储空间大，或者更新前比更新后占用的存储空间小都不能进行就地更新

UPDATE操作对应的undo日志--不更新主键的情况--先删除掉旧记录，再插入新记录

• 1.在不更新主键的情况下，如果有任何一个被更新的列更新前和更新后占用的存储空间大小不一致，那么就需要先把这条旧的记录从聚簇索引页面中删除掉，然后再根据更新后列的值创建一条新的记录插入到页面中
• 2.请注意一下，我们这里所说的删除并不是delete mark操作，而是真正的删除掉，也就是把这条记录从正常记录链表中移除并加入到垃圾链表中
• 3.且是由用户线程同步执行真正的删除操作，真正删除之后紧接着就要根据各个列更新后的值创建的新记录插入。
• 4.这里如果新创建的记录占用的存储空间大小不超过旧记录占用的空间，那么可以直接重用被加入到垃圾链表中的旧记录所占用的存储空间

针对UPDATE不更新主键的日志

• 1.日志形式和删除的undo 日志相似，只是多了以下几点。
• 2.n_updated：表示本条UPDATE语句执行后将有几个列被更新，后边跟着的<pos, old_len, old_value>分别表示被更新列在记录中的位置、更新前该列占用的存储空间大小、更新前该列的真实值。
  如果在UPDATE语句中更新的列包含索引列，那么也会添加索引列各列信息这个部分，否则的话是不会添加这个部分的。

更新主键的情况的日志

• 1.将旧记录进行delete mark操作，而是真正的删除掉，也就是把这条记录从正常记录链表中移除并加入到垃圾链表中-
• 2.根据更新后各列的值创建一条新记录，并将其插入到聚簇索引中（需重新定位插入的位置）。
• 3.由于更新后的记录主键值发生了改变，所以需要重新从聚簇索引中定位这条记录所在的位置，然后把它插进去
• 4.针对UPDATE语句更新记录主键值的这种情况，在对该记录进行delete mark操作前，会记录一条类型为TRX_UNDO_DEL_MARK_REC的undo日志；
  之后插入新记录时，会记录一条类型为TRX_UNDO_INSERT_REC的undo日志，也就是说每对一条记录的主键值做改动时，会记录2条undo日志