背景

为什么需要回收表空间？任何一个存储或您购买的实例规格都有容量限制，并且根据存储介质不同，保存方式不同，相应地成本也会不同。在线数据库的存储成本是比较高的，所以架构师和DBA在系统设计之初就要考虑满足未来几年内的业务需求，同时又能最大化地节省成本，这是比较合理的架构布局和容量规划的方法。而大多数系统是没有经过以上步骤直接上线的，这种随着业务的发展在线数据会保留的越来越多，当存储容量不够时可以通过升级实例规格或硬件解决，但如果没有更大的规格时，只能删除数据回收表空间了。

回收表空间的常见方法

在删除回收表空间时，通常有以下几种方法：

针对DROP TABLE A可能会带来的性能抖动可以通过阿里云内核经过特殊优化Purge Large File Asynchronously(https://help.aliyun.com/document_detail/134095.html)默认已经打开。而对于ALTER TABLE的操作，目前业界开源的有gh-ost、pt-online-schema-change和OnlineSchemaChange

，阿里云RDS MySQL也专门研发了无锁结构变更。本文针对几种常见的表空间回收的方式做了测试，希望给开发或运维人员提供更稳定的变更参考方式，保障生产环境的稳定性。

各类工具对比

1. 比pt-online-schema-change的trigger对原表影响较小

pt-online-schema-change的工作原理是创建和源表A一样的表A_gst执行DDL操作，同时在A上创建一个DML触发器，然后将A中的数据拷贝到A_gst，在拷贝过程中产生的增量变更就用触发器完成同步更新。拷贝结束后执行两张表的rename操作完成变更。

2. OnlineSchemaChange

工作原理和pt-online-schema-change基本一致，不同的地方是它采用的是异步模式，在A_gst的基础上创建了一张日志表，触发器的条目更新将直接落在日志表中，后台进程将日志表中的条目应用到A_gst表。这样整个流程上是异步的，也能够控制回放速度。

3. gh-ost

与上面两种变更流程基本一致，但是没有使用触发器的设计，所以增量变更的数据来源不是触发器，而是Binlog文件。订阅读取该文件中A表的变更记录，将记录解析并应用到A_gst表。这样的数据对于gst表回放非常有利，binlog中存储的都是A表的记录，易于直接读取和应用。

4. DMS的无锁结构变更

采用了无触发器的设计，能有效解决触发器设计带来的锁、数据库开销等问题。同时和DTS的联动，执行表空间回收时会把临时表也传送到DTS，这样DTS的同步下游链路不会中断。

为了验证DMS的无锁变更的稳定性，做了4次测试分别是：

• 编号34221蓝色曲线，基准oltp_insert测试作为对比基线;
• 编号34222绿色曲线，基准oltp_insert测试+DMS的无锁变更+ALTER TABLE [tbname] ENGINE=INNODB;
• 编号34237黄色曲线，基准oltp_insert测试+关闭DMS的无锁变更+RDS kernel ALTER TABLE [tbname] ENGINE=INNODB;
• 编号34239灰色曲线，基准oltp_insert测试+关闭DMS的无锁变更+RDS kernel OPTIMIZE TABLE [tbname];

以蓝色基线为基准，从图中可以看出绿色曲线相较于同样是执行回收表空间的黄色和灰色平稳，但持续时间较长；绿色、黄色、灰色曲线到最后都会临时表重命名成正式表的过程，最多2s。

测试结论

结合实际业务来说推荐性能比较稳定的DMS无锁变更+ALTER TABLE。使用DMS的无锁变更可以打开DMS控制台，在页面顶部，选择全部功能 > 数据方案 > 无锁变更。

注意事项

1. 不支持字符串类型的主键(dms是一块一块的拷贝，最大值和最小值确定拷贝范围，然后分成若干块拷贝，会用到很多min max计算范围的SQL)

参考

如何用DMS进行无锁结构变更(https://help.aliyun.com/document_detail/98373.html)

关于optimize和alter的原理(https://developer.aliyun.com/article/579242)