高效回收MySQLInnoDB独立表空间

当碎片较多或者buffer pool较大的时候，我们需要面临风险----对Innodb存储引擎在执行DDL语句的时候，会短暂hang住整个系统，而且

对于innodb独立表空间来说，delete 是不能回收其在磁盘所占用的空间，采用truncate （原理是先删除，或重建）倒是可以；

这里不讨论直接drop表的情况，直接alter table ....engine=innodb 是可以整理碎片，回收部分表空间，在数据量小或者buffer pool 比较小的时候（小于30G）倒是很不错；

当碎片较多或者buffer pool较大的时候，我们需要面临风险----对Innodb存储引擎在执行DDL语句的时候，会短暂hang住整个系统，而且这个hang的时间的长短与Buffer Pool的大小相关。主要原因在于InnoDB在drop table时，会连续两次遍历buf pool LRU 链表，遍历的过程加锁，因此导致系统hang住。第一遍遍历LRU链表，会定期释放buf pool mutex，因此对于系统hang的影响较小；而第二遍会一直持有，对系统hang的影响较大。-

--相关文章可以参考：

MySQL删除大表性能

Innodb buffer解读

在这里我介绍一种安全高效的碎片整理方法；pt-online-schema-change

percona这款工具本身是用来进行非阻塞的online ddl的，但由于只有alter table ...语句才能回收表空间，那可以采用该工具的原理：创建一张临时表，以触发器来保证与原表的数据一致，最后renmame替换掉；用过这款工具的朋友可能会有疑问，“online ddl”最后的操作时 drop old table；drop trigger；这样的操作；但可以采用--no-drop-old-table,让其不会删除旧表，等有其他时间的时候，采用脚本形式批量删除记录，，最后在drop掉剩余的“小表”；这样就避免了hang 住系统；

本人亲测，版本2.2.1，60G表，2个小时左右回收至21G；

推荐阅读：

InnoDB存储引擎的启动、关闭与恢复

MySQL InnoDB独立表空间的配置

MySQL Server 层和 InnoDB 引擎层 体系结构图

InnoDB 死锁案例解析

MySQL Innodb独立表空间的配置