LevelDB引入Sequence Number（序列号）的必要性解析

你提到的「compaction时L层同user key记录总是覆盖L+1层对应记录」的规则，本身就不是独立于Sequence Number（以下简称seq）存在的前置逻辑，只是seq机制在compaction场景下的一个简化表现——这个规则只能覆盖跨层compaction合并的极小部分场景，根本没法支撑LevelDB的核心能力，完全没法替代seq的作用，核心原因有几个：

• 首先，大量需要判断数据新旧的场景根本不涉及跨层。
  L0层的SST是直接从内存Immutable MemTable刷盘生成的，多个L0 SST之间的key范围完全重叠，甚至单个SST内部都可能存在同个user key的多条记录（比如对同一个key短时间内多次写入、删除，还没触发compaction就一起刷到了同一个SST里）。这种同层、同文件内的多版本记录，靠层级规则完全没法判断新旧，必须靠全局递增的seq：seq更大的记录版本更新。
  另外读请求的查询路径是先查内存MemTable、再查Immutable MemTable，之后才从L0到L6逐层查SST，内存里的记录还没分配到任何SST层级，和磁盘上的同key记录比版本，也必须靠seq判断，总不能硬编码「内存里的记录一定比磁盘新」——万一刷盘过程中崩溃，内存数据丢失，磁盘上半写完的SST和其他已有SST里的同key记录，没有seq根本分不清版本先后。
• 其次，LevelDB的快照功能完全依赖seq实现，靠层级规则根本做不到。
  LevelDB的快照本质就是记录一个某时刻的seq值，带快照的读请求只能读取seq小于等于该值的最新记录，哪怕seq更大的新写入已经落到更高层级的SST里，也不能对这个快照可见。如果没有seq，仅靠层级优先级，要么为了保留快照完全禁止同key的新记录覆盖旧记录，导致空间无限膨胀、读性能暴跌；要么新记录覆盖旧记录之后，快照读直接读到新数据，完全破坏快照的隔离性。
  而且compaction过程中判断旧版本记录、删除墓碑能不能被清理，核心依据也是seq：只要还有快照引用比某个旧版本seq更小，这个旧版本就不能被删，等所有引用它的快照都释放了，compaction时才会把冗余旧版本清掉，这个逻辑没有seq根本跑不通。
• 最后，你提到的跨层覆盖规则本身就需要seq做正确性兜底。
  compaction不是原子操作，过程中如果发生进程崩溃、机器掉电，可能出现部分记录已经写到L+1层、对应的L层旧记录还没删掉的情况，重启之后如果只靠「L层覆盖L+1层」的硬规则，万一遇到同层compaction中途失败、或者L0多个重叠SST部分合并的场景，根本判断不了记录的新旧顺序。甚至删除操作的墓碑标记，如果没有seq标识版本，很容易出现旧墓碑误删更新版本记录的严重数据错误。

说白了，SST层级的新旧优先级只是seq全局有序带来的一个附加特性：越靠上层的SST，里面存储的记录seq整体越大，所以正常compaction流程里可以直接用上层记录覆盖下层记录减少比较开销，但seq才是整个LevelDB判断数据版本的唯一可信依据，根本不可能被层级规则替代。

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