重做日志记录了事务的行为，可以很好地通过其进行“重做”。但是事务有时还需要撤销，这时就需要undo。undo和redo正好相反，对于数据库进行修改时，数据库不但会产生redo，而且还会产生一定量的undo，即使你执行的事务或语句由于某种原因失败了，或者如果你用一条rollback语句请求回滚，就可以利用这些信息将数据回滚到修改之前的样子。与redo不同的是，redo存放在重做日志文件中，undo存放在数据库内部的一个特殊段(segment)中，这成为undo段 (undo segment)，undo段位于共享表空间内，可以通过py_innodb_page_info.py工具，来查看当前共享表空间中undo的数量：
[roo@xen-server ~]# python py_innodb_page_info.py /usr/local/mysql/data/ibdata1
Total number of page: 46208:
Insert Buffer Free list: 13093
Insert Buffer Bitmap: 3
System Page: 5
Transaction system Page: 1
Freshly Allocated Page:4579
undo Log Page:2222 ——可以看到,当前的共享表空间ibdata内有2222个undo页。
File Segment inode: 6
B-tree Node: 26296
File Space Header: 1
扩展描述页:2
我们通常对于undo有这样的误解：undo用于将数据库物理地恢复到执行语句或事物之前的样子——但事实并非如此。数据库只是逻辑地恢复到原来的样子，所有修改都被逻辑地取消，但是数据结构本身在回滚之后可能大不相同，因为在多用户并发系统中，可能会有数十数百甚至数千个并发事务。数据库的主要任务就是协调对于数据记录的并发访问。如一个事务修改当前一个页中某几条记录，但同时还有别的事务在对同一页中另几条记录进行修改。因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行的工作。
例如：我们的事务执行了一个insert 10万条记录的SQL语句，这条语句可能会导致分配一个新的段，即表空间会增大。如果我们执行rollback时，会将插入的事务进行回滚，但是表空间的大小并不会因此而收缩。因此，当InnoDB存储引擎回滚时，它实际上做的是与先前相反的工作。对于每一个insert，innodb存储引擎都会完成一个delete；对于每一个delete，innodb存储引擎都会完成一个insert；对于每一个update，innodb存储引擎都会执行一个相反的update。将修改前的行放回去。
oracle和Microsoft server数据库都有内部的数据字典来观察当前undo的信息；InnoDB存储引擎在这方面做得还是不够的，所以DBA只能通过原理和经验来进行判断。我写了一个补丁(patch)来扩展show engine innodb status命令的显示结果，可以用来查看当前内存缓冲池中undo页的数量，如下代码所示。
Per second averages calculated from the last 14 seconds
······
-------------
UNDO PAGE INFO
--------------
Undo Page count: 1 ——可以看到,当前内存缓冲中有1个undo页。
······
-----------------
END OP INNODB MONITOR OUTPUT
=================
1 row in set (0.01 sec)
接着我们开启一个事务,执行插入10万条记录的操作,注意,这并不进行提交操作:
mysql> create table t like order line
Query OK, 0 rows affected (0. 23 sec)
mysql> insert into t select * from order_line limit 100000:
Query OK, 100000 rows affected (45.01 sec)
Records: 100000 Duplicates: 0 Warnings: o
之后在另一个会话中执行命令SHOW ENGINE INNODB STATUS,可以看到之前的会话产生的undo量:
mysql> show engine innodb statusG
********************* 1.row **************************
-----------------
UNDO PAGE INFO
-----------------
Undo Page count:129.
·······
---------------
END OF INNODB MONITOR OUTPUT
========================
1 row in set (12.38 sec)
可以看到，此时undo页的数量变成了129.也就是说，刚才的一个事务大致产生了129个undo页。另外，即使对insert的事务进行了提交，我们在一段时间内还是可以看到内存中有129个undo页。这是因为，对于undo页的回收实在master thread中进行的，master thread也不是每次回收所有的undo页。