AWS RDS MariaDB大表OPTIMIZE效果差异排查求助

1. 两次快照的数据内容差异 #

• 统计JSON列的平均大小：执行SELECT AVG(LENGTH(your_json_column)) FROM abc;，对比两次快照中该值的差异。如果第二次快照的JSON列平均大小远小于首次，说明生产环境在4周内已减少了冗余，导致清理步骤无太多空间可释放。
• 验证清理脚本的实际效果：检查第二次通过RabbitMQ清理时，实际更新的行数（比如用ROW_COUNT()或日志统计），确认是否因JSON结构变化、冗余规则不匹配导致清理未生效。

2. 表空间与碎片率差异 #

• 查看表状态详情：执行SHOW TABLE STATUS LIKE 'abc'\G，重点对比两次快照的Data_length、Index_length、Data_free值。如果第二次快照的Data_free本身很小，说明表碎片率极低，OPTIMIZE TABLE无法释放更多空间。
• 确认innodb_file_per_table配置：执行SHOW VARIABLES LIKE 'innodb_file_per_table';，若该值为OFF，OPTIMIZE TABLE释放的空间会回到共享表空间，不会体现在表的磁盘占用上（RDS控制台显示的表大小可能无变化）。

3. OPTIMIZE TABLE的执行瓶颈 #

• 排查IO资源瓶颈：通过RDS Performance Insights查看操作期间的IOPS、磁盘吞吐量指标，确认是否因存储IO被其他任务抢占（如其他备份、查询任务）导致重建表耗时变长、空间释放不彻底。
• 检查锁与事务干扰：查看操作期间的锁等待情况（SHOW ENGINE INNODB STATUS;），若存在长时间的表锁或事务阻塞，会延缓OPTIMIZE TABLE的执行，甚至导致部分空间未被回收。
• 确认OPTIMIZE TABLE的完整性：检查操作日志，确认命令是否完整执行，未因超时、连接中断等原因中途终止。

4. 表结构与索引的隐含变化 #

• 对比两次快照的表结构：执行DESCRIBE abc;，确认第二次快照的表是否仍包含那30个无用列（可能生产环境在4周内已调整过表结构），或新增了其他占用空间的列。
• 检查索引占用空间：执行SELECT SUM(index_length) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='abc';，对比两次快照的索引总大小。若第二次索引占用空间远高于首次，即使删除了复合索引，新增的其他索引也会占据大量空间。

5. AWS RDS存储层特性影响 #

• 检查存储类型与IO性能：若使用GP2存储，128GB的默认IOPS为384，首次操作时可能利用了存储缓存，第二次从快照恢复后缓存未命中，导致IO耗时剧增，OPTIMIZE TABLE无法高效完成空间回收。
• 快照的事务一致性：确认第二次快照是否包含未提交的大事务，导致表中存在大量脏页，OPTIMIZE TABLE重建时需处理更多无效数据，空间释放效率降低。

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