相同表Redshift磁盘占用75GB而MySQL仅40GB，差异原因是什么？

对应查询语句：select size from svv_table_info where "table"='table_name'
已确认前置条件：

1. MySQL侧的表不存在缺失的行或列，两边数据量完全一致
2. Redshift表已定期执行VACUUM操作，排除未回收死元组的影响

• 数据编码配置未优化：Redshift若未手动指定列编码，部分场景默认使用RAW无压缩编码，而MySQL InnoDB默认对页数据、可变长字段做压缩，压缩率差距可达数倍。可执行ANALYZE COMPRESSION table_name获取官方推荐的列压缩配置，调整后可显著降低空间占用。
• 分布键选择不当导致数据倾斜：如果分布键基数极低，会导致数据集中在少数分片，同时Redshift每个数据块有最小预留空间，倾斜严重时会产生多倍空间放大。可执行SELECT slice, COUNT(*) FROM table_name GROUP BY slice ORDER BY 2 DESC检查分片数据分布是否均匀。
• 排序键的元数据开销：Redshift排序键需要在每个数据块中存储排序元数据，复合排序键的维度越多，元数据开销越高，这部分是无索引的MySQL表不需要承担的额外存储成本。
• 数据类型定义差异：Redshift部分数据类型默认占用空间高于MySQL，比如Redshift不支持TINYINT、SMALLINT等极小整数类型，同时超长VARCHAR定义即使存储短文本，也会产生额外的块预留开销，而MySQL的可变长类型完全按实际存储长度占用空间。
• 多副本存储开销：Redshift默认会为每个数据块存储1-2个副本用于节点故障容错，如果你的MySQL实例未配置多副本同步，这部分会直接带来1-2倍的空间差距。
• 旧版本数据未回收：若仅执行了VACUUM SORT而未执行VACUUM DELETE ONLY，或者存在长事务持有旧版本数据的引用，已删除/更新的旧数据块不会被立即释放，也会导致空间占用偏高。可执行SELECT * FROM svv_vacuum_progress WHERE table_name = 'table_name'检查VACUUM执行效果。

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