Google Cloud Spanner相同数据库副本大小差异及增量缩减原因咨询

• 旧版本数据垃圾回收延迟：Spanner基于MVCC（多版本并发控制）机制，会保留历史版本数据以支持时间旅行查询和事务一致性。原库decision长期运行过程中积累了大量未被回收的旧版本数据，导致实际存储体积远大于当前有效数据量。而导出的快照仅包含当前最新版本的数据，导入后的decision_backup没有这些冗余历史数据，初始体积自然更小。后续原库的后台垃圾回收进程逐步清理了旧版本数据，所以体积持续缩减至接近有效数据量。

• 存储碎片与数据重组织：原库长期经历写入、更新、删除操作，会产生大量存储碎片（比如已删除数据占用的未释放空间、数据块碎片化）。导入新库时，数据是按照Spanner最优的存储结构重新组织的，没有碎片，存储效率更高。原库后续的后台存储优化进程（如数据块合并、碎片整理）会逐步消除碎片，导致体积逐步下降。

• 索引的优化重建：原库的索引在长期操作中可能积累了冗余的索引条目或碎片化的索引数据。导入新库时，索引是基于快照数据重新构建的，结构更紧凑、高效。原库的后台索引维护进程会逐步合并索引片段、清理冗余条目，使得索引占用空间减少，整体库体积随之缩减。

• 存储格式的后台转换：Spanner导出的备份采用了经过压缩和优化的存储格式，导入新库时直接使用这种高效格式存储。而原库之前的存储格式可能因历史操作保留了一些非优化的格式，后续后台进程会将原库的存储格式逐步转换为更高效的版本，从而降低整体体积。

内容的提问来源于stack exchange，提问作者Aziz R.