用户的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混用在一起。
