| 优化点 | 解决的问题 | 业务收益 |
| 基于垃圾率的主动 GC | RocksDB 原生 GC 仅按"年龄"挑选文件，老文件中可能仍是有效数据 | 更精准回收，磁盘空间更省 |
| GC 优先级元数据 | 主动 GC 需要持久化"哪些 Blob 更紧急回收"的标记，原生 BlobDB 无此字段 | 重启后 GC 进度不丢失，DBA 可干预紧急 Blob |
| 小 Blob 文件合并 | 频繁 Compaction 会产生大量碎片化的小 Blob 文件 | 减少文件数，降低元数据开销 |
| Blob GC 直接拷贝 | 默认 GC 需要先解压 → 重新压缩 Blob 数据 | GC CPU 开销显著下降（实测5KB value 提速约1.5倍，10KB 约1.4倍） |
| Blob 写入 Sync 优化 | RocksDB 默认强制1MB 一次 RangeSync，现代 SSD 上反而成为瓶颈 | Blob 写入 IOPS 提升，长尾延迟下降 |
| Blob 值懒加载 | 范围扫描时即使最终不读 Value，迭代器也提前加载了 Blob | 范围扫描性能提升（如 SELECT COUNT(*)、唯一性校验） |
| DeleteRange 加速 | 大批量范围删除会逐条更新 Blob 引用计数 | 大批量删除更快 |
| 共享 Blob Cache | 默认无 Blob Cache，每次读 Blob 都是磁盘 I/O | Blob 热点读延迟下降（需重启） |
| Blob 起始 Level | 上层（L0/L1）数据短命，分离反而增加 GC 压力 | 默认从 L1 开始分离，更平衡 |
| 按 Level 设置压缩算法 | 不同层数据冷热不同，统一压缩不灵活 | 冷数据可用 ZSTD 强压缩省空间 |
优化点在数据流中的位置
注意：说明：
注意：黄色标注的节点（Blob 文件 / Blob Cache / 主动 GC）是上述10项优化的核心作用位置。