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: <trx1, insert …>
  記錄2: <trx2, update …>
  記錄3: <trx1, delete …>
  記錄4: <trx3, update …>
  記錄5: <trx2, insert …>
  D. 由於C的緣由, 當一個事務將Redo Log寫入磁盤時, 也會將其餘未提交的事務的日誌寫入磁盤。
  E. Redo Log上只進行順序追加的操做, 當一個事務須要回滾時, 它的Redo Log記錄也不會從
  Redo Log中刪除掉。

摘自
http://blog.163.com/zihuan_xuan/blog/static/1287942432012366293667/