为何RocksDB需设计多层级结构 已排序Level1仍要合并到Level2？

即便Level 1层的SSTable整体键范围不重叠、全局有序，也依然需要执行Level 1到Level 2的compaction操作，核心原因不止是单目录文件数过多的问题：

• 容量限制约束：RocksDB默认Level 1的最大容量仅为256MB，如果不将数据compact到容量更大的Level 2（默认容量为Level 1的10倍），Level 1很快会被占满，后续Level 0到Level 1的compaction会直接阻塞，写入请求无法正常处理。
• 空间放大优化：同一个键的多次更新、删除操作产生的历史版本、墓碑标记会分散在不同层级的SSTable中，只有跨层级compaction时才会清理这些冗余数据，释放磁盘空间。如果停止Level 1向下的compaction，冗余数据会持续堆积，空间放大率会高到不可接受。
• 读放大优化：查询请求需要按照MemTable→Immutable MemTable→Level 0→Level 1→Level N的顺序逐层查找目标键，层级越多、每层的文件数越多，查询需要的IO次数就越高。将Level 1的多个小文件compact合并为Level 2的少量大文件，可以减少后续查询需要扫描的文件总数，降低读放大。

这个观点不成立，原因如下：

• 分片仅能解决单目录文件数过多这一个单一问题，完全无法解决上述的容量限制、空间放大、读放大优化等LSM树的核心需求，就算对Level 1做了目录分片，存储引擎的性能和可用性依然会快速恶化。
• 分片的实际实现复杂度远没有预想的低：如果采用键范围分片，需要额外维护分片元数据、处理分片的动态分裂与合并、保证查询路由的正确性，还要解决分片一致性、热点分片负载均衡等问题，整套逻辑的开发和调优难度远高于成熟的compaction策略。如果采用哈希分片，还会破坏Level 1的键有序性，导致范围查询性能暴跌，得不偿失。
• Compaction是LSM树架构的核心设计，它的作用不止是处理文件数问题，更是用来平衡读放大、写放大、空间放大三者权衡的核心机制，可通过调整compaction策略适配读密集、写密集、空间优先等不同业务场景，这是分片方案完全不具备的能力。

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