Leveled Compaction 在 LSM-Tree 中通过层级规则触发合并：Level 0 文件数≥4、Level L 文件超限或 Level L+1 对应键范围总大小超阈值时触发；L≥1 层合并只选一个 SSTable 及其重叠文件，输出严格分片为固定大小且有序无重复。
Leveled Compaction 的层级合并逻辑怎么落地
LSM-Tree 中最常用也最可控的是 Leveled Compaction，它要求 Level L（L ≥ 1）中每个 SSTable 大小相近、键范围不重叠，而 Level 0 允许重叠（因为直接来自 Flush）。实现时关键不是“把文件塞进某一层”，而是按规则选文件、做归并、写新文件、删旧文件。
核心判断逻辑是：pick_compaction 函数需满足三个条件才触发合并：Level L 文件数超限（如 Level 1 默认 10 个）、Level L+1 对应键范围内的文件总大小超过阈值（如 10MB × Level L 文件数）、或 Level 0 文件数 ≥ level0_file_num_compaction_trigger（RocksDB 默认 4）。
- Level 0 → Level 1 合并必须全量扫描所有 Level 0 文件 + 所有与之 key range 重叠的 Level 1 文件，这是唯一允许跨 key range 重叠的合并路径
- Level L → Level L+1（L ≥ 1）只挑一个“热点”SSTable，再找 Level L+1 中所有与其 key range 重叠的文件，避免一次合并拉入过多数据
- 合并输出的新 SSTable 必须严格拆分成固定大小（如 2MB），且内部 key 有序、无重复；若合并后 key 范围超出目标层单文件上限，需主动切分
Size-Tiered Compaction 在 C++ 中如何简化实现
如果你在写教学版或嵌入式 LSM（比如 Tiny-LSM），Size-Tiered 更易上手：它不维护层级概念，只按文件大小分组，同组内文件数达阈值（如 4 个）就合并成一个更大的 SSTable。
难点不在合并本身，而在“分组策略”——不能简单按文件体积四舍五入分桶。实际要按 log₂(size) 取整做桶号，例如 1MB~2MB → bucket 20，2MB~4MB → bucket 21。这样能自然形成指数级增长的文件尺寸分布。
立即学习“C++免费学习笔记（深入）”；
- 每次 Flush 生成的新 SSTable 都要立即归入对应 size bucket，并检查该 bucket 是否达到
level_multiple（默认 10）倍于上一级 bucket 的数量 - 合并时只取当前 bucket 中最老的 N 个文件（N = bucket 触发阈值），避免拖入刚写的热数据
- 合并结果不写回原 bucket，而是放入下一个 bucket（size 翻倍），否则会反复触发同一层合并
Compaction 过程中如何避免读写冲突
Compaction 是后台线程干的活，但 MemTable 可能在它跑一半时被新写请求刷成 Immutable，同时前台读请求还在查各层 SSTable。C++ 实现里没锁不行，但锁粒度太大会卡住整个引擎。
标准解法是用引用计数 + 文件句柄快照：SSTable 对象构造时增加 refcount，VersionSet::PickCompaction() 拿到待合并文件列表后，对每个 SSTable* 调用 Ref()；合并完成、新文件写入成功、旧文件标记为“待删除”前，不调用 Unref()。
- 前台读请求通过
Version快照看到的是合并开始前的文件视图，不会因后台删文件而 crash - Immutable MemTable 刷盘时，只影响新生成的 Level 0 文件，不影响正在 compaction 的 Level 1+ 文件
- 绝不能在 compaction 线程里直接
unlink()旧文件——要交由VersionEdit提交后，在下次LogAndApply时由主版本管理器统一清理
压缩时要不要做数据过滤和编码优化
Compaction 不只是物理搬运，更是数据净化的关键时机。C++ 实现里最容易被跳过、但收益最大的一步，就是在归并过程中丢弃过期数据。
具体操作是：遍历所有输入 SSTable 的 key-value 时，对每个 key 维护一个“最新有效 value”的状态机。遇到 DEL 类型记录就标记为已删除；遇到相同 key 的新 PUT 就覆盖旧值；最后只把未被删除的最新 value 写入新 SSTable。
- 必须保留 tombstone（删除标记）直到它被更高层的 PUT 覆盖，否则会导致读取时误判存在性
- 如果开启 block compression（如 Snappy），要在写入新 SSTable 的
DataBlock前压缩，而不是对原始 value 字节数组做无差别压缩 - Key 编码推荐用 delta encoding（如
Varint32编码 key 长度 + shared prefix 长度 + unique suffix），可显著降低索引块体积，但要注意 prefix 共享只在同一个 SSTable 内有效
VersionEdit 的序列化顺序和 Manifest 文件的原子更新必须严格一致。 
