事务实现,redo,undo,锁

事务（Transaction）是数据库区别于文件系统的重要特性之一。在文件系统中，如果你正在写文件，但是操作系统突然崩溃了，这个文件就很有可能被破坏。当然，有一些机制可以把文件恢复到某个时间点。不过，如果需要保证两个文件同步，这些文件系统可能就显得无能为力了。如当你需要更新两个文件时，更新完一个文件后，在更新完第二个文件之前系统重启了，你就会有两个不同步的文件。这正是数据库系统引入事务的主要目的：事务会把数据库从一种一致状态转换为另一种一致状态。在数据库提交工作时，可以确保其要么所有修改都已经保存了，要么所有修改都不保存。

事务概述

事务是数据库区别于文件系统的重要特性之一。事务用来保证数据库的完整性——要么都做修改，要么都不做。

事务有严格的定义，它必须同时满足四个特性。

原子性（atomicity）：原子性是指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作执行都成功，才算整个事务成功。如果事务中任何一个SQL语句执行失败，那么已经执行成功的SQL语句也必须撤销，数据库状态应该退回到执行事务前的状态。
一致性（consistency）：一致性指事务将数据库从一种状态转变为下一种一致的状态。在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
隔离性（isolation）：一个事务的影响在该事务提交前对其他事务都不可见——这通过锁来实现。
持久性（durability）：事务一旦提交，其结果就是永久性的。即使发生宕机等故障，数据库也能将数据恢复。

事务的实现

隔离性由锁得以实现。原子性、一致性、持久性通过数据库的redo和undo来完成。

redo

在InnoDB存储引擎中，事务日志通过重做（redo）日志文件和InnoDB存储引擎的日志缓冲（InnoDB Log Buffer）来实现。

当开始一个事务时，会记录该事务的一个LSN（Log Sequence Number，日志序列号）；

当事务执行时，会往InnoDB存储引擎的日志缓冲里插入事务日志；

当事务提交时，必须将InnoDB存储引擎的日志缓冲写入磁盘（默认的实现，即innodb_flush_log_at_trx_commit=1）。也就是在写数据前，需要先写日志。这种方式称为预写日志方式（Write-Ahead Logging，WAL）。

InnoDB存储引擎通过预写日志的方式来保证事务的完整性。这意味着磁盘上存储的数据页和内存缓冲池中的页是不同步的，对于内存缓冲池中页的修改，先是写入重做日志文件，然后再写入磁盘，因此是一种异步的方式。可以通过命令SHOW ENGINE INNODB STATUS来观察当前磁盘和日志的“差距”：

create table z(a int,primary key(a)) engine=innodb;

create procedure load_test(count int)

begin

　　declare i int unsigned default 0;

　　start transaction;

　　while i＜count do

　　　　insert into z select i;

　　　　set i=i+1;

　　end while;

commit;

end;

首先建立一张表z，然后建立一个往表z中导入数据的存储过程load_test。通过命令SHOW ENGINE INNODB STATUS观察当前的重做日志情况：

show engine innodb status\G

Log sequence number表示当前的LSN

Log flushed up to表示刷新到重做日志文件的LSN

Last checkpoint at表示刷新到磁盘的LSN。

因为当前没有任何操作，所以这三者的值是一样的。

接着开始导入10 000条记录：

call load_test(10000);

show engine innodb status\G

这次SHOW ENGINE INNODB STATUS的结果就不同了，Log sequence number的LSN为113047672789，Log flushed up to的LSN为113047672789，Last checkpoint at的LSN为113047174608，可以把Log flushed up to和Last checkpoint at的差值498 181（～486.5K）理解为重做日志产生的增量（以字节为单位）。

虽然在上面的例子中，Log sequence number和Log flushed up to的值是相等的，但是在实际的生产环境中，该值有可能是不同的。因为在一个事务中从日志缓冲刷新到重做日志文件，并不只是在事务提交时发生，每秒都会有从日志缓冲刷新到重做日志文件的动作。下面是一个生产环境下重做日志的信息：

show engine innodb status\G

---

LOG

---

Log sequence number 203318213447

Log flushed up to 203318213326

Last checkpoint at 203252831194

1 pending log writes，0 pending chkp writes

103447 log i/o's done，7.00 log i/o's/second

可以看到，在生产环境下Log sequence number、Log flushed up to、Last checkpoint at三个值可能是不同的。

undo

重做日志记录了事务的行为，可以很好地通过其进行“重做”。但是事务有时还需要撤销，这时就需要undo。undo与redo正好相反，对于数据库进行修改时，数据库不但会产生redo，而且还会产生一定量的undo，即使你执行的事务或语句由于某种原因失败了，或者如果你用一条ROLLBACK语句请求回滚，就可以利用这些undo信息将数据回滚到修改之前的样子。与redo不同的是，redo存放在重做日志文件中，undo存放在数据库内部的一个特殊段（segment）中，这称为undo段（undo segment），undo段位于共享表空间内。可以通过py_innodb_page_info.py工具，来查看当前共享表空间中undo的数量：

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

File Segment inode：6

B-tree Node：26296

File Space Header：1

扩展描述页：2

可以看到，当前的共享表空间ibdata1内有2222个undo页。

我们通常对于undo有这样的误解：undo用于将数据库物理地恢复到执行语句或事务之前样子——但事实并非如此。数据库只是逻辑地恢复到原来的样子，所有修改都被逻辑地取消，但是数据结构本身在回滚之后可能大不相同，因为在多用户并发系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要任务就是协调对于数据记录的并发访问。如一个事务在修改当前一个页中某几条记录，但同时还有别的事务在对同一个页中另几条记录进行修改。因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行的工作。

例如：我们的事务执行了一个INSERT 10万条记录的SQL语句，这条语句可能会导致分配一个新的段，即表空间会增大。如果我们执行ROLLBACK时，会将插入的事务进行回滚，但是表空间的大小并不会因此而收缩。因此，当InnoDB存储引擎回滚时，它实际上做的是与先前相反的工作。对于每个INSERT，InnoDB存储引擎会完成一个DELETE；对于每个DELETE，InnoDB存储引擎会执行一个INSERT；对于每个UPDATE，InnoDB存储引擎则会执行一个相反的UPDATE，将修改前的行放回去。

Oracle和Microsoft SQL Server数据库都有内部的数据字典来观察当前undo的信息；InnoDB存储引擎在这方面做得还是不够的，所以DBA只能通过原理和经验来进行判断。我写过一个补丁（patch）来扩展SHOW ENGINE INNODB STATUS命令的显示结果，可以用来查看当前内存缓冲池中undo页的数量，如下代码所示。

show engine innodb status\G

可以看到，当前内存缓冲中有1个undo页。

接着我们开启一个事务，执行插入10万条记录的操作，需要注意的是，这并不进行提交操作：

create table t like order_line;

insert into t select * from order_line limit 100000;

之后在另一个会话中执行命令SHOW ENGINE INNODB STATUS，可以看到之前的会话产生的undo量：

show engine innodb status\G

可以看到，此时undo页的数量变成了129，也就是说，刚才的一个事务大致产生了129个undo页。另外，即使对INSERT的事务进行了提交，我们在一段时间内还是可以看到内存中有129个undo页。这是因为，对于undo页的回收是在master thread中进行的，master thread也不是每次回收所有的undo页。