B-Tree vs LSM-Tree：写多读少场景的索引选择

B-Tree

• 写：原位更新，要写 WAL + 改 page
• 读：一次 B+ 树查找，O(log n)
• 空间：稳定，无放大

适合：OLTP、点查为主、读多写少

LSM-Tree

• 写：append 到 memtable，后台 compaction 合并
• 读：要查 memtable + 多层 SSTable，需要 Bloom filter 加速
• 空间：有写放大和空间放大

适合：写多读少、时间序列、日志

不是简单二选一

• LSM 的读放大在小数据集不明显，大数据集要靠 Bloom filter + cache
• B-Tree 写放大其实也不小（WAL + double write）
• 真实场景里大多混合，要看模式分布

工程选择参考

场景	推荐
OLTP（交易型）	B-Tree (PostgreSQL, MySQL)
时间序列	LSM (Cassandra, InfluxDB)
搜索引擎	倒排索引
嵌入式	LSM (RocksDB, LevelDB)

PostgreSQL 永远不会换成 LSM —— 它的优势就在 B-Tree 的查询稳定性上。