mysql++ibdata_mysql ibdata1

When you have innodb_file_per_table enabled, the tables are stored in their own tablespace but the shared tablespace is still used to store other InnoDB’s internal data:

data dictionary aka metadata of InnoDB tables

change buffer

doublewrite buffer

undo logs

Some of them can be configured on Percona Server to avoid becoming too large. For example you can set a maximum size for change buffer with innodb_ibuf_max_size or store the doublewrite buffer on a separate file with innodb_doublewrite_file.

Undo Log

Undo Log 是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来实现多版本并发控制(简称：MVCC)。

事务的原子性(Atomicity)

事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发生

了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。

原理

Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方

(这个存储数据备份的地方称为Undo Log)。然后进行数据的修改。如果出现了错误或者用户执行了

ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。

除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化。

事务的持久性(Durability)

事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。为了保证持久性，数据库

系统会将修改后的数据完全的记录到持久的存储上。

用Undo Log实现原子性和持久化的事务的简化过程

假设有A、B两个数据，值分别为1,2。

A.事务开始.

B.记录A=1到undo log.

C.修改A=3.

D.记录B=2到undo log.

E.修改B=4.

F.将undo log写到磁盘。

G.将数据写到磁盘。

H.事务提交

这里有一个隐含的前提条件：‘数据都是先读到内存中，然后修改内存中的数据，最后将数据写回磁盘’。

之所以能同时保证原子性和持久化，是因为以下特点：

A. 更新数据前记录Undo log。

B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。

C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的，

可以用来回滚事务。

D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。

缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。

如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化，即Redo Log.

Redo log

原理

和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可，

不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据

Redo Log的内容，将所有数据恢复到最新的状态。

Undo + Redo事务的简化过程

假设有A、B两个数据，值分别为1,2.

A.事务开始.

B.记录A=1到undo log.

C.修改A=3.

D.记录A=3到redo log.

E.记录B=2到undo log.

F.修改B=4.

G.记录B=4到redo log.

H.将redo log写入磁盘。

I.事务提交

Undo + Redo事务的特点

A. 为了保证持久性，必须在事务提交前将Redo Log持久化。

B. 数据不需要在事务提交前写入磁盘，而是缓存在内存中。

C. Redo Log 保证事务的持久性。

D. Undo Log 保证事务的原子性。

E. 有一个隐含的特点，数据必须要晚于redo log写入持久存储。

IO性能

Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据, 减少了写数据的IO.

但是却引入了新的IO，即写Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。

为了保证Redo Log能够有比较好的IO性能，InnoDB 的 Redo Log的设计有以下几个特点：

A. 尽量保持Redo Log存储在一段连续的空间上。因此在系统第一次启动时就会将日志文件的空间完全分配。

以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。

B. 批量写入日志。日志并不是直接写入文件，而是先写入redo log buffer.当需要将日志刷新到磁盘时

(如事务提交),将许多日志一起写入磁盘.

C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起，

以减少日志占用的空间。例如,Redo Log中的记录内容可能是这样的：

记录1:

记录2:

记录3:

记录4:

记录5:

D. 因为C的原因, 当一个事务将Redo Log写入磁盘时, 也会将其他未提交的事务的日志写入磁盘。

E. Redo Log上只进行顺序追加的操作, 当一个事务需要回滚时, 它的Redo Log记录也不会从

Redo Log中删除掉。