mysql undo详谈
1 简介:undo是MVCC机制的基础部分之一
2 作用:为了实现可重复性读,存储历史数据
3 存储:5.6以前undo都存储在内存和ibdata1中,5.6以后undo可以独立成单独的文件,更可以进行truncate表空间,减少磁盘容量
5 回滚段三阶段
0 回滚段分类
update_undo: 只用于事务内的update语句 这里会加入到其对应rollback segment的history list数据页列表上，history list长度加1
insert_undo：只用于事务内的insert语句 新插入的记录产生的Undo不会被任何查询语句所引用，因此可以直接释放undo，这里的undo log不会累加到history list上
1 事务开始后,针对读写事务,会预先在内存中分配一个回滚段
2 事务进行中,将历史数据写入undo page中
1 事务commit
2 事务rollback
1：对于标记删除的记录清理标记删除标记；
2：对于in-place更新，将数据回滚到最老版本；
3：对于插入操作，直接删除聚集索引和二级索引记录（row_undo_ins）。
6 purge清理undo段
1 清理事务提交后不需要的undo信息 从回滚段的HISTORY 文件链表上开始遍历释放Undo log segment，由于history 链表是按照trx no有序的，因此遍历truncate直到完全清除，或者遇到一个还未purge的undo log（trx no比当前purge到的位置更大）时才停止。
2 清理已经被打上delete标记的数据实现物理删除
相关参数变量 innodb_purge_threads=1(默认值)
7 相关 innodb status信息
Purge done for trx's n:o < 219761368 undo n:o < 0 state: running but idle
History list length 3228
purge done 代表已经完成的事务量
n:0< 代表正在执行的purge
state:代表线程是否繁忙
history-list-length 代表存在的undo个数 16KX3228 代表使用的undo大小 一页是16K
这里要注意 一般情况下history-list不可能为零,因为 update_undo有一部分会进行cache重用,而这部分也算在没有清理的列表之中
8 关于ibdata1暴涨的原因
1 共享表空间=>改用独立表空间
2 大量undo暴涨了ibdata的空间
1 存在未完成的事务,可以通过hsitory list观察计算
2 执行过大事务(一般都是这种原因造成的)
9 补充
当我们delete数据行时，是对数据页中要删除的数据行做标记“deleted”，事务提交(速度快)；
10 undo的构成和布局
1 128个回滚段构成,32个回滚段用于系统的临时表空间,96个回滚段用于事务
2 每个回滚段维护了一个段头页，在该page中又划分了1024个slot，每个slot又对应到一个undo log对象，因此理论上InnoDB最多支持 96 * 1024个普通事务。
3 独立表空间的space id都是从1 开始,0被预留在ibdata中.space id必须是连续分配的,不能断档
4 8.0之前的版本默认只能创建128个回滚段