几种常见的MySQL/PolarDB-MySQL回收表空间方法对比

MySQL/PolarDB-MySQL回收表空间常见方法包括基于表重建的临时表替换、基于数据清理的整理操作、分区表删除及分表删除，工具方面有pt-online-schema-change、OnlineSchemaChange、gh-ost及DMS无锁变更，其中DMS无锁变更+ALTER TABLE性能最稳定。 以下是具体对比分析：

• 方法1：临时表重建替换（CREATE TABLE + INSERT + DROP + RENAME）

  操作流程：创建与原表结构相同的临时表A'，筛选保留数据插入临时表，删除原表A，将临时表A'重命名为A。

  适用场景：需快速清理大量数据且保留数据量较少，允许短暂暂停写入（毫秒级）。

  优势：操作逻辑简单，数据清理彻底。

  劣势：大表操作时可能引发性能抖动，需评估业务对短暂写入的容忍度。

• 方法2：数据清理后整理（DELETE + ALTER TABLE/OPTIMIZE TABLE）

  操作流程：通过DELETE语句删除不需要的数据，再执行ALTER TABLE或OPTIMIZE TABLE整理表空间。

  适用场景：保留数据量较大，需逐步清理少量数据的场景。

  优势：可结合无锁数据变更工具（如DMS）减少锁表影响。

  劣势：DELETE操作可能引发性能抖动，OPTIMIZE TABLE会重建表，耗时较长。

• 方法3：分区表删除（ALTER TABLE DROP PARTITION）

  操作流程：直接删除分区表的指定分区。

  适用场景：数据已按分区存储（如按时间、范围分区），需快速清理特定分区数据。

  优势：删除分区效率高，无需重建表。

  劣势：仅适用于分区表，非分区表无法使用。

• 方法4：分表删除（DROP TABLE）

  操作流程：直接删除已分表的子表（如按日期或取模分表的A_0000、A_20100101）。

  适用场景：数据已按分表策略存储，需清理特定分表数据。

  优势：操作简单，删除效率高。

  劣势：需提前规划分表策略，否则无法使用。

通用问题：上述方法均可能引发性能抖动，需在业务低峰期操作。阿里云RDS MySQL通过Purge Large File Asynchronously功能优化DROP TABLE性能，减少对业务的影响。

• pt-online-schema-change

  原理：创建临时表A_gst，通过触发器同步原表A的增量变更，最后通过RENAME交换表名。

  优势：开源工具，社区支持广泛。

  劣势：触发器可能增加数据库负载，对高并发场景不友好。

• OnlineSchemaChange

  原理：与pt-online-schema-change类似，但采用异步模式，通过日志表记录增量变更，后台进程回放。

  优势：异步处理减少对原表影响，可控制回放速度。

  劣势：实现复杂，需额外维护日志表。

• gh-ost

  原理：不使用触发器，通过解析Binlog获取增量变更，直接应用到临时表。

  优势：无触发器设计，减少数据库开销，Binlog解析效率高。

  劣势：需确保Binlog配置正确，否则可能丢失数据。

• DMS无锁变更

  原理：采用无触发器设计，结合DTS同步临时表数据，确保下游链路不中断。

  优势：

  性能稳定：测试显示，DMS无锁变更+ALTER TABLE的曲线（绿色）比其他方法更平稳，虽持续时间较长，但对业务影响最小。

  操作便捷：通过DMS控制台即可完成操作，无需复杂配置。

  兼容性强：支持与DTS联动，保障数据同步链路的稳定性。

  劣势：不支持字符串类型的主键（因需通过min/max计算拷贝范围，字符串类型计算效率低）。

  操作路径：打开DMS控制台，选择全部功能 > 数据方案 > 无锁变更。

• 性能对比：以基准测试（oltp_insert）为基线，DMS无锁变更+ALTER TABLE（绿色曲线）的性能波动最小，虽操作耗时较长，但对业务影响可控。其他方法（如关闭DMS无锁变更的ALTER TABLE或OPTIMIZE TABLE）性能波动较大。
• 推荐方案：结合业务需求，优先选择DMS无锁变更+ALTER TABLE，以保障生产环境的稳定性。

• 主键类型限制：DMS无锁变更不支持字符串类型的主键，因需通过min/max计算拷贝范围，字符串类型的计算效率较低。
• 业务低峰期操作：尽管DMS无锁变更性能稳定，但仍建议在业务低峰期执行表空间回收操作，进一步降低风险。
• 备份与验证：操作前需备份数据，并在测试环境验证操作流程，确保数据安全。