【WiredTiger 内核】Compaction 与 Backup：空间回收与一致性边界
内容提要
本文介绍WiredTiger存储引擎的compaction机制：通过将文件尾部块前移到可复用区间，再多次checkpoint后truncate缩小文件，但为best-effort不保证成功。同时说明backup cursor打开期间禁用日志删除与预分配改名，保证备份一致性，但会导致日志堆积，备份窗口应有界。
延伸解读
为什么删除数据后文件不缩小
WiredTiger 中删除数据通常不会自动缩小文件，因为空闲块若不在文件尾部，就无法通过 truncate 回收。Compaction 通过将尾部块前移到可复用区间，再多次 checkpoint 后截断文件，但这是 best-effort 操作，不保证一定缩小。理解这一点有助于解释数据库文件大小与逻辑数据量不一致的现象。
Compaction 的触发条件与门槛
Compaction 并非对所有文件都执行，它跳过小于 1MB 的文件，并要求满足硬编码门槛：至少 20% 可用空间落在文件前 80%，或至少 10% 总文件大小在前 90% 可用。这些条件确保 compaction 有足够的收益，避免无谓的 I/O 开销。
Backup 期间日志堆积的代价
Backup cursor 打开期间，WiredTiger 会禁用自动日志删除和预分配日志文件改名，以保证备份一致性。但这会导致 WiredTigerLog.* 文件持续堆积，因此备份窗口应有界。长时间挂起 backup cursor 可能耗尽磁盘空间，运维时需注意控制备份时长。
Q&A
WiredTiger的compaction机制是如何回收空间的？
WiredTiger的compaction通过将文件尾部的块移动到文件前部的可复用区间，然后执行多次checkpoint，最后截断文件来缩小文件大小。这是一个best-effort操作，不保证一定成功。
为什么删除数据后文件大小不会自动缩小？
因为删除数据后，空闲块可能不在文件尾部，而truncate只能从文件尾部进行，所以如果空闲块分散在文件中部，文件系统报告的文件大小不会改变。
WiredTiger compaction的触发条件有哪些？
compaction会跳过小于1MB的文件，或者理论可回收空间低于free_space_target的文件。此外，必须满足以下硬编码门槛之一：至少20%的可用空间落在文件前80%（则尝试重写最后20%），或至少10%的总文件大小在前90%可用（则尝试最后10%）。
compaction过程中为什么需要执行两次checkpoint？
第一次checkpoint释放的块会进入特殊的'checkpoint-available'列表，元数据更新后才进入真正的avail列表；第二次checkpoint是为了避免checkpoint自身写入文件尾部导致无法截断的问题。
backup cursor打开期间对日志管理有什么影响？
backup cursor打开期间，自动日志删除被禁用，预分配日志文件的改名也被禁用，以保证备份一致性。这会导致WiredTigerLog.*文件堆积，因此备份窗口应有界。
后台compaction是如何选择要处理的表的？
后台compaction服务遍历元数据中的合格文件，排除tiered和exclude列表中的文件，跳过开头那次checkpoint以降低打扰，使用历史成功率聚焦有效表，并且仅当dirty（不计updates）低于eviction_dirty_trigger且总cache低于eviction_trigger时处理下一张表。
