Aurora MySQL迁移后数据库容量缩减问题排查咨询

针对你遇到的「RDS MySQL备份恢复到Aurora后，行数一致但部分表空间占用显著更小」的问题，可以从以下几个方向逐一排查：

1. 检查源RDS表的InnoDB碎片情况 #

从你提供的watchdog表统计数据来看：

• RDS的Data_free高达29360128字节，远大于Aurora的4194304字节，说明源表存在大量表空间碎片。InnoDB在频繁执行删除、更新操作后，会留下未释放的空闲页，这些空间不会立即归还操作系统，导致表空间虚高。
• RDS的Avg_row_length（37016）是Aurora（4696）的近8倍，也印证了源表因碎片化导致行存储的空间浪费。

验证方法：在RDS上执行OPTIMIZE TABLE watchdog;（或ALTER TABLE watchdog ENGINE=InnoDB;），重新整理表空间后，对比Data_length和Avg_row_length的变化。如果空间明显下降，说明碎片是核心原因。

2. 对比索引的碎片化与重建差异 #

两张表的Index_length差距明显（RDS: 425984，Aurora: 81920），可能是源库索引存在严重碎片，而Aurora在恢复过程中自动重建了索引，消除了碎片：

• 先通过SHOW CREATE TABLE watchdog;确认两边的索引结构完全一致，排除索引定义差异的可能。
• 在RDS上执行ALTER TABLE watchdog FORCE;重建索引，之后查看Index_length是否降低，验证索引碎片的影响。

3. 核实Aurora的存储优化特性 #

Aurora的集群存储引擎自带一些默认优化机制，可能导致空间占用更低：

• 检查两边的InnoDB关键参数：比如innodb_page_size（页大小）、innodb_compression_level（压缩级别）是否一致。Aurora可能默认启用了页压缩或使用了更优的存储格式。
• Aurora会自动对存储层进行碎片整理和空间优化，而RDS需要手动执行OPTIMIZE TABLE才能释放空闲空间。

4. 确认统计信息的准确性 #

SHOW TABLE STATUS返回的Data_length、Rows等数据是估算值，存在误差：

• 用SELECT COUNT(*) FROM watchdog;精确验证两边的行数一致。
• 查询INFORMATION_SCHEMA.TABLES获取更准确的表空间数据：

  SELECT table_name, data_length, index_length, data_free 
  FROM INFORMATION_SCHEMA.TABLES 
  WHERE table_schema = '你的数据库名' AND table_name = 'watchdog';
  

• 若有条件，使用innodb_space工具分析实际的表空间页分布，彻底排除统计误差的影响。

5. 检查数据恢复的方式 #

不同的恢复方式会直接影响表空间的碎片化程度：

• 如果是用mysqldump等逻辑备份恢复，恢复过程是重新插入所有数据，相当于自动完成了表空间整理，自然没有源库长期运行产生的碎片。
• 如果是快照恢复，Aurora的快照存储机制会自动优化空间占用，而RDS的快照可能保留了源库的碎片状态。

内容的提问来源于stack exchange，提问作者Griffin