badgerdb 是基于 lsm 树的 kv 数据库，但采用 value 分离存储（value 写入独立 log，key+pointer 入 lsm），降低读放大；缺点是 gc 复杂、value log 不支持随机删改，易现索引与 value 不一致。
BadgerDB 是 LSM 树吗？它和 LevelDB/RocksDB 有什么实质区别
是，BadgerDB 是纯 Go 实现的、基于 LSM 树结构的嵌入式 KV 数据库。但它不是 LevelDB 或 RocksDB 的 Go 移植版，而是从头设计的——关键差异在 value 分离存储：Badger 把 value 单独写入 value log 文件，key 和 value pointer 才进 LSM memtable/sstables。这带来两个直接后果：读放大更低（尤其大 value 场景），但 GC 更复杂，且 value log 不支持随机删改。
常见错误现象：Get 返回 ErrKeyNotFound，但用 Iterator 能扫到 key —— 很可能 value log 被 GC 掉了而索引没及时更新（尤其低频写+手动调 RunValueLogGC 不足时）。
- 适用场景：高吞吐写入、value 大小不均（如存 JSON blob、protobuf）、需要强 ACID 单机事务
- 不适用场景：要求原地更新 value、依赖 RocksDB 的 compaction 策略调优、或需要 ColumnFamily
- 性能影响：value 超过 ~1KB 时，Badger 比 RocksDB 内存占用更稳；但小 value（
初始化 BadgerDB 时必须注意的 3 个配置项
Options 里最关键的不是 Dir 或 ValueDir，而是 SyncWrites、NumVersionsToKeep 和 MaxTableSize。它们直接决定数据可见性、磁盘膨胀速度和查询延迟。
-
SyncWrites = false是默认值，但生产环境写入量大时容易丢数据——WAL 不落盘，进程崩溃就丢最近一批未 flush 的 memtable。设为true会降写入吞吐约 15–30%，但保证 crash-safe -
NumVersionsToKeep = 1（默认）够用，但如果业务依赖多版本读（比如做简易 MVCC 快照），要提前设高；设太高会导致旧 SST 文件长期不被清理，磁盘涨得快 -
MaxTableSize默认 64MB，对 SSD 友好；但机械盘上建议提到 128–256MB，减少 compaction 频次和小文件数量
示例：
opt := badger.DefaultOptions("/tmp/badger").WithSyncWrites(true).WithNumVersionsToKeep(1)
立即学习“go语言免费学习笔记（深入）”；
事务中 Get/Set 后忘记 Commit 或 Discard 就会卡住后续操作
Badger 的事务不是“自动提交”的，txn.Commit() 或 txn.Discard() 必须显式调用。漏掉会导致：内存泄漏（memtable 不释放） + 后续 Update 事务阻塞在 pendingWrites 队列，表现为你发了新写请求但一直没返回。
- 最安全写法：用
defer txn.Discard()开头，再if err == nil { txn.Commit() }结尾 - 不要在事务里调用外部 HTTP 请求或长耗时逻辑——Badger 事务持有锁，会拖慢整个 DB 的写入吞吐
- 读事务（
db.NewTransaction(false)）不用Commit，但也要Discard，否则 iterator 句柄不释放，SST 文件引用计数不下，GC 无法清理
Value log GC 不触发？别只盯着 RunValueLogGC
RunValueLogGC 不是定时器，它是一次性尝试回收 value log 中被覆盖/删除的 value 空间。失败很常见，原因通常是：当前 value log 文件太“热”（还有活跃 key 指向它），或者 DropRatio 设太高（默认 0.5，意思是至少 50% space 可回收才动手）。
- 先检查
ValueLogSize和ValueLogSizeAtLastGC（通过db.Stats()），确认确实在涨 - 降低
DropRatio到 0.3～0.4，再调RunValueLogGC，成功率明显上升 - GC 过程中会阻塞写入，所以最好选低峰期做；频繁 GC（比如每分钟一次）说明 value 更新太猛，考虑把大 value 改成外存路径存，只在 Badger 存 URL
真正容易被忽略的是：Badger 的 GC 不清理 SST 文件里的 stale key，那是靠后台 compaction 自动做的——如果你关了 CompactL0OnClose 或 KeepL0InMemory，L0 层堆积太多小文件，查询会变慢，且 GC 效果打折。
