关于认为仅追加型TSDB无需WAL的推理，存在哪些问题？

你的推理忽略了仅追加时序数据库（TSDB）场景下，WAL与数据文件在功能定位、容错边界、性能权衡上的本质差异，具体问题如下：

1. 数据文件与WAL的刷写逻辑完全不同 #

虽然两者都是仅追加模式，但数据文件的写入通常是批量延迟刷写：为了优化性能，TSDB会把内存中的时序数据攒到一定阈值（比如按时间窗口、数据量）才写入数据文件，甚至会在后台做压缩、分片合并（compaction）操作。而WAL的核心是即时持久化：用户请求到达后，先把原始事务记录追加到WAL，立刻调用fsync强制刷盘，之后再向用户返回成功。

如果去掉WAL，你只能二选一：

• 每次写入数据文件都调用fsync，这会因大文件刷盘的高开销导致性能暴跌；
• 延迟刷写数据文件，但崩溃时内存中未落地的数据会完全丢失，违反ACID的持久性承诺。

WAL正是解决这一矛盾的关键：用低开销的小文件顺序fsync保证持久性，后台异步处理数据文件的批量写入，两者绝非简单的“副本”关系。

2. 数据文件可能处于不一致状态，WAL是可靠恢复的唯一来源 #

即便你的TSDB仅支持追加，也可能因后台操作（如compaction、分片文件切换）导致数据文件出现部分写入、结构损坏的情况。比如在合并多个时序分片文件时系统崩溃，此时数据文件可能存在重复数据、分片截断等问题，但WAL记录的是完整的原始事务序列，重放时可以完全重建出正确的数据文件。

如果只有数据文件，崩溃后你无法区分“正常的未完成写入”和“损坏的文件结构”，根本无法实现可靠的数据恢复。

3. WAL并非永久占用额外存储 #

WAL是临时日志：当数据文件确认已经落地了WAL中记录的所有事务后，对应的WAL段就可以被删除或归档。比如每次数据文件完成批量刷写后，就可以清理之前的WAL，不会持续占用额外存储。你认为WAL会一直消耗资源的假设不成立。

4. 数据文件的“仅追加”不代表写入原子性 #

即使数据文件是顺序追加，单次写入多个时序记录时，仍可能出现“部分写入”的情况（比如写了一半系统崩溃）。WAL记录的是完整的事务单元，重放时可以保证事务原子性：要么全量恢复，要么完全不恢复；而数据文件的部分写入会直接导致数据不一致。

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