RocksDB 在 C# 中无法直接使用官方库，因其仅提供 C++ 接口，C# 需通过 P/Invoke 调用第三方封装（如 RocksDbSharp）加载 native 二进制文件，需手动管理版本、平台匹配与路径；常见错误为 DllNotFoundException；初始化须确保目录存在且有权限、使用绝对路径、避免复用 Options 实例；性能调优关键在 WriteOptions（如 sync=false）、批量写入用 WriteBatch、ReadOptions 复用及 key 前缀设计；注意 native ABI 兼容性、key 编码一致性与 Dispose 正确调用。
为什么 RocksDB 在 C# 里不能直接用官方库
因为 RocksDB 官方只提供 C++ 接口，C# 没有原生绑定。你看到的 RocksDbSharp 或 MyRocksDb 都是第三方封装，本质是通过 P/Invoke 调用编译好的 rocksdb.dll（Windows）或 librocksdb.so（Linux）。这意味着：你必须自己管好 native 二进制文件的版本、平台匹配和加载路径。
- 常见错误现象：
System.DllNotFoundException: Unable to load DLL 'rocksdb'——不是没装包，是没放对.dll - 使用场景：适合需要单机高吞吐写入（比如日志聚合、本地缓存索引）、不依赖网络服务、且能接受手动维护 native 依赖的项目
- 参数差异：
RocksDbSharp的Options类多数字段只是 C++rocksdb::Options的浅层映射，像table_factory或自定义 comparator 这类高级配置，C# 封装往往不支持或需额外 unsafe 代码 - 性能影响：P/Invoke 本身开销极小，瓶颈几乎全在 RocksDB 本身；但若误配
WriteOptions.sync = true（每次写都刷盘），吞吐会暴跌 10 倍以上
RocksDbSharp 初始化时最常漏掉的三件事
它不像 SQLite 那样“建个连接就能跑”，RocksDB 是基于目录的，初始化失败往往卡在路径、权限或选项冲突上。
- 必须确保目标目录存在且进程有读写权限——
RocksDB不会自动创建父目录，Directory.CreateDirectory得你自己调 -
DB.Open的第二个参数是绝对路径，相对路径容易因工作目录变化而错位；建议用Path.GetFullPath("data")显式转义 - 别复用同一个
Options实例多次调用Open：内部指针会被释放，第二次调用大概率触发AccessViolationException - 示例：
RocksDb db = null; try { var options = new Options { CreateIfMissing = true }; db = RocksDb.Open(options, Path.GetFullPath("mydb")); } catch (Exception ex) { // 注意：ex.InnerException 可能才是真实错误（比如权限不足） }
写入性能卡在 WriteOptions 的默认值上
默认配置为数据安全妥协了速度，生产环境必须调。
-
sync = false（默认）+disableWAL = false（默认）：写入快，断电可能丢最后几条 WAL 未刷盘数据 -
sync = true：强制落盘，写入延迟从 ~0.1ms 升到 ~5ms+，QPS 掉 80% 以上 -
disableWAL = true：跳过 WAL，崩溃必丢数据，仅适用于纯缓存或可重建场景 - 批量写用
WriteBatch，比单条Put快 3–10 倍：var batch = new WriteBatch(); batch.Put("key1", "val1"); batch.Put("key2", "val2"); db.Write(writeOptions, batch); // writeOptions 可单独设 sync=false
查询慢？先看 ReadOptions 和 key 设计
RocksDB 本身查得很快，但 C# 层容易无意中引入阻塞或重复序列化。
-
ReadOptions.fillCache = true（默认）：热 key 会进 block cache，但如果 value 很大（>64KB），cache 效率骤降，考虑关掉 - 避免反复 new
ReadOptions：实例可复用，new 它本身不贵，但频繁 GC 会影响长稳运行 - key 设计比想象中重要：前缀相同的一批 key（如
"user_123:profile","user_123:settings"）能利用PrefixExtractor加速迭代，否则Iterator扫全表 - 注意
Get返回byte[]，不是 string——直接Encoding.UTF8.GetString前先确认写入时也是同编码，否则乱码不报错
native 二进制的 ABI 兼容性、key 编码一致性、以及 Dispose 是否被正确调用（不 Dispose 会导致句柄泄漏），这三个点一旦出问题，现象都是“跑着跑着就卡住或崩”，而不是报明确异常。
