undo

重做日志记录了事务的行为，可以很好地通过其进行“重做”。但是事务有时还需要撤销，这时就需要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 status\G

********************* 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页。

 

转载于:https://www.cnblogs.com/5945yang/p/11061671.html