使用者的ibdata1檔案持續增加：

Innodb的表有兩種存放方式：

第一種共享表空間方式：所有表的索引，資料統一存放在一個共享表空間中，這樣會導致共享表空間的空間迅速增長，同時空間回收困難；

第二種獨佔表空間方式：就是RDS目前採用 的，也就是一張表一個表空間，表中的索引和資料存放在自己獨立的表空間中，空間能夠比較容易的回收；

無論是獨佔還是共享表空間，innodb都會有系統共享表空間（ibdata1），該系統表空間主要用於儲存資料字典，undo entry，insert buffer，doublewrite buffer，

該系統表空間的增加通常的原因有如下：

a.長時間沒有提交事務，同時資料庫中有大量的更新，插入，刪除 ，導致innodb建立大量的undo來維護一致性讀：可以通過show engine innodb status\G檢視active的事務：

SHOW ENGINE INNODB STATUS\G

—TRANSACTION 36E, ACTIVE 1256288 sec

MySQL thread id 42, OS thread handle 0x7f8baaccc700, query id 7900290 localhost root

show engine innodb status

Trx read view will not see trx with id >= 36F, sees < 36F

b.mysql 5.1中undo的purge是和master thread 共用一個執行緒，所以發現show engine inndob status\G中的histtory length過長，則可能的purge的速度到達了瓶頸，

所以在mysql 5.5將undo的purge獨立出來，可以設定undo purge的執行緒個數：

| innodb_purge_threads    | 0     |

| innodb_max_purge_lag    | 0     |

| innodb_max_purge_size   | 0     |

| innodb_purge_batch_size | 20    |

如何檢視ibdata1中的檔案組建?

開源社群提供了一個工具：innodb_space可以清晰地分析出ibdata1的組成（該工具需要bindata環境）

innodb_space -f /tmp/ibdata1 space-page-type-summary

type                count       percent     description

UNDO_LOG            4430725     80.61       Undo log            

ALLOCATED           1035701     18.84       Freshly allocated

INODE               28348       0.52        File segment inode

INDEX               722         0.01        B+Tree index

IBUF_BITMAP         334         0.01        Insert buffer bitmap

XDES                333         0.01        Extent descriptor

IBUF_FREE_LIST      152         0.00        Insert buffer free list

SYS                 3           0.00        System internal

TRX_SYS             1           0.00        Transaction system header

FSP_HDR             1           0.00        File space header

可以看到ibdata1檔案中大量的都是undo_log，在定位到其中的檔案組成後，我們可以採取以下方案：

建議使用者將版本從5.1升級到5.5，5.5中有獨立的purge執行緒可以很快的回收掉undo log,遷移的過程中由於是採用邏輯遷移，會重建ibdata1檔案降低空間使用；

在5.6中可以單獨設定undo tablespace檔案，避免與ibdata1混用在一起。