RocksDB 本身是用 C++ 编写的最优嵌入式 LSM 实现，无需“用 C++ 和 RocksDB 实现”；关键在于正确配置 Options（如 create_if_missing、max_open_files、bytes_per_sync）和 BlockBasedTableOptions（启用 LRUCache），而非重写底层逻辑。
为什么 RocksDB 本身已经是最优嵌入式 LSM 实现，不必“用 C++ 和 RocksDB 实现”
RocksDB 就是用 C++ 写的、专为高性能嵌入式键值存储设计的 LSM-tree 引擎。所谓“用 C++ 和 RocksDB 实现”，实际就是正确配置和调用 RocksDB 的 C++ API。很多项目踩坑，是因为误以为要自己手写 memtable、SST 文件格式或 compaction 调度——这些恰恰是 RocksDB 已经高度优化、不建议覆盖的部分。
真正需要关注的是：如何根据你的数据访问模式（读多写少？点查为主？批量导入？）选对 Options 和 ColumnFamilyOptions，以及如何避免常见反模式。
初始化时必须显式设置的三个关键 Options
默认构造的 rocksdb::Options 适合测试，但生产环境几乎总是需要调整。漏掉以下任一配置，都可能导致吞吐骤降或内存失控：
-
options.create_if_missing = true：否则打开不存在的 DB 会失败 -
options.max_open_files = -1：禁用文件句柄限制（RocksDB 自行管理缓存），否则在高并发下频繁 open/close SST 文件，I/O 毛刺明显 -
options.bytes_per_sync = 512 * 1024：控制 WAL 同步粒度；太小（如 0）→ 每次写都 fsync，延迟飙升；太大（如 1MB+）→ 崩溃可能丢失更多数据；512KB 是多数 SSD 的平衡点
另外，options.use_fsync = false（默认）配合 bytes_per_sync 更安全，比盲目设 use_fsync = true 更可控。
立即学习“C++免费学习笔记（深入）”；
点查性能差？先检查 BlockBasedTableOptions 和 cache 配置
90% 的“RocksDB 查询慢”问题，根源不在 LSM 结构本身，而在表格式和缓存没配对。默认的 BlockBasedTableOptions 不启用 block cache，相当于每次读都要解压 + 查找 SST 块。
正确做法：
- 创建
rocksdb::LRUCache，大小建议 ≥ 1GB（例如rocksdb::NewLRUCache(1ULL ） - 将 cache 绑定到
table_options.block_cache，而非table_options.block_cache_compressed（除非你明确压缩 hot data） - 开启
table_options.cache_index_and_filter_blocks = true：把 index/filter 加载进 block cache，避免每次查找都读磁盘 - 确认
options.optimize_filters_for_hits = true：当 95%+ 查询命中 key 时，跳过 bloom filter 检查，省一次 cache miss
未配 cache 时，单次 Get() 可能触发多次随机 I/O；配好后，热 key 基本落在内存，P99 延迟从 10ms+ 降到 100μs 内。
写放大过高或 compaction 卡住？优先调 level0_file_num_compaction_trigger 和 max_bytes_for_level_base
LSM 的写放大主要来自 level-0 compaction（无序 SST 合并）和跨 level 合并。默认参数针对通用场景，但如果你的 workload 是“每秒写 5K key，key 很小（
实操建议：
- 增大
options.level0_file_num_compaction_trigger（默认 4 → 试试 8~12）：让 level-0 积累更多文件再触发 compaction，降低频率 - 同步调大
options.max_bytes_for_level_base（默认 256MB → 512MB 或 1GB）：避免 level-1 过早满，减少 level-0→level-1 的倾倒压力 - 禁用
options.compaction_pri = rocksdb::kMinOverlappingRatio（默认）→ 改用kByCompensatedSize：对小 value 场景更公平，防止大 value 文件长期滞留
注意：max_bytes_for_level_base 必须是 target_file_size_base 的整数倍，否则 RocksDB 启动时静默忽略该配置。
LSM 的复杂性不在代码实现，而在参数与 workload 的耦合。一个 WriteOptions.sync = true 的误用，可能让吞吐跌 10 倍；而一个没开的 cache_index_and_filter_blocks，会让读延迟毛刺藏得极深——它们不会报错，只会默默拖垮性能。
