MySQL学习笔记事务篇：undo日志和MVCC_undo日志 mvcc
赞
踩
目录
undo log
undo用来回滚行记录到某个版本。undo log一般是逻辑日志，根据每行记录进行记录。
undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。
当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。
undo log有两个作用：提供回滚和多个行版本控制(MVCC)。
undo log是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment。
另外，undo log也会产生redo log，因为undo log也要实现持久性保护。
undo log的存储方式
innodb存储引擎对undo的管理同样采用段的方式。
每个rollback segment 包含1024个undo log segment，事务在每个undo log segment中进行undo页的申请。
innodb1.2开始，可以通过下面参数对rollback segment做进一步的设置:
innodb_undo_directory #undo表空间存放目录
innodb_undo_logs #设置rollback segment的个数
innodb_undo_tablespaces #设置构成rollback segment文件的数量，这样可以较为平均的分布在多个文件中
innodb_undo_log_truncate #参数设置为1，即开启在线回收（收缩）undo log日志文件，支持动态设置
innodb_max_undo_log_size #当undo表空间超过该参数设定时，会标记为truncation，选择一个undo表空间进行截断
innodb_purge_rseg_truncate_frequency #undo 表空间一般不能直接truncate，需要在所有回滚段释放完后，才能truncate， purge system每128次释放一次回滚段，可以通过参数
事务在undo log segment分配页写入undo log的过程同样需要写入重做日志，当事务提交时，innodb会做以下两件事:
- 将undo log放入列表，以供以后的purge操作
- 判断undo log 所在页是否可以重用，若可以则分配给下个事务使用
delete/update操作的内部机制：purge 机制
insert undo log
指在insert操作中产生的undo log，因为insert操作的记录只对事务本身可见。因此该undo log在事务提交后直接删除，不需要进行purge操作。
update undo log
记录的是对delete和update操作产生的undo log，该log需要提供mvcc机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行清除。
当事务提交的时候，innodb不会立即删除undo log，因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即undo log不能删除。
但是在事务提交的时候，会将该事务对应的undo log放入到删除列表中，未来通过purge来删除。并且提交事务时，还会判断undo log分配的页是否可以重用，如果可以重用，则会分配给后面来的事务，避免为每个独立的事务分配独立的undo log页而浪费存储空间和性能。
通过undo log记录delete和update操作的结果发现：
- delete操作实际上不会直接删除，而是将delete对象打上delete flag，标记为删除，最终的删除操作是purge线程完成的。
- update分为两种情况：update的列是否是主键列。
- 如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
- 如果是主键列，update分两部执行：先删除该行，再插入一行目标行。
MVCC
数据库默认隔离级别：RR（Repeatable Read，可重复读），MVCC主要适用于Mysql的RC,RR隔离级别
MVCC的实现，通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间，在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同，同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。
- 每行数据都存在一个版本，每次数据更新时都更新该版本。
- 修改时Copy出当前版本随意修改，各个事务之间无干扰。
- 保存时比较版本号，如果成功（commit），则覆盖原记录；失败则放弃copy（rollback）
MVCC的实现原理
undo log
为了便于理解MVCC的实现原理，这里简单介绍一下undo log的工作过程
在不考虑redo log 的情况下利用undo log工作的简化过程为：
| 序号 | 动作 |
|---|---|
| 1 | 开始事务 |
| 2 | 记录数据行数据快照到undo log |
| 3 | 更新数据 |
| 4 | 将undo log写到磁盘 |
| 5 | 将数据写到磁盘 |
| 6 | 提交事务 |
1）为了保证数据的持久性数据要在事务提交之前持久化
2）undo log的持久化必须在在数据持久化之前，这样才能保证系统崩溃时，可以用undo log来回滚事务
结构
Innodb通过undo log保存了已更改行的旧版本的信息的快照。
InnoDB的内部实现中为每一行数据增加了三个隐藏列用于实现MVCC。
| 列名 | 长度(字节) | 作用 |
|---|---|---|
| DB_TRX_ID | 6 | 插入或更新行的最后一个事务的事务标识符。（删除视为更新，将其标记为已删除） |
| DB_ROLL_PTR | 7 | 写入回滚段的撤消日志记录（若行已更新，则撤消日志记录包含在更新行之前重建行内容所需的信息） |
| DB_ROW_ID | 6 | 行标识（隐藏单调自增id） |
MVCC工作过程
MVCC只在READ COMMITED 和 REPEATABLE READ 两个隔离级别下工作。READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE 则会对所有读取的行都加锁
SELECT
InnoDB 会根据两个条件来检查每行记录：
- InnoDB只查找版本(DB_TRX_ID)早于当前事务版本的数据行（行的系统版本号<=事务的系统版本号,这样可以确保数据行要么是在开始之前已经存在了，要么是事务自身插入或修改过的）
- 行的删除版本号(DB_ROLL_PTR)要么未定义（未更新过），要么大于当前事务版本号（在当前事务开始之后更新的）。这样可以确保事务读取到的行，在事务开始之前未被删除。
INSERT：InnoDB为新插入的每一行保存当前系统版本号作为行版本号
DELETE：InnoDB为删除的每一行保存当前的系统版本号作为行删除标识
UPDATE：InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识
