作者把自己的股票分析仓库从 OLTP 引擎迁到 OLAP 栈：第一版跑在 InnoDB 上，第二版同一套分析改跑 lakehouse，起因只是想要一个优化点，但为了用上它，他被迫把 lakehouse 的每一层都弄明白。文章先梳理 InnoDB 的三条保证：行存储把所有列放在一起，取某个标的的一根 K 线只碰磁盘上一处，正是写入所需的形态，但一个指标只要用到两列，也会通过 buffer pool 把整行所有列都取出来；每个索引都是独立的 B 树，每次写入都要更新表上所有 B 树，索引本质上是用更慢的写换更快的读，所以他的 Raw 表只有主键，重索引与分区都放在接收 Raw 下游结果的表上；undo log 支撑并发读写，行被更新或删除时旧值写进 undo log，写入期间并发会话从里面读到旧版本，插入的 undo log 在提交后立即清理，更新与删除的 undo log 则进入全局的 history list，这就是 MVCC 的由来，而 InnoDB 会在所有早于或等于该提交开始的会话结束后才标记清理。
🔑 核心要点
背景是把同一套股票分析从 InnoDB 迁到 OLAP lakehouse 栈。
迁移动机只是想要一个优化点，却被迫理解整个 lakehouse 的分层。
InnoDB 保证一：行存让取一根 K 线只碰一处磁盘，但指标用两列也会把整行取回 buffer pool。
保证二：每个索引都是独立 B 树，写入要更新全部 B 树，等于用慢写换快读。
作者的取舍是Raw 表只有主键，重索引与分区放在下游表上。
保证三：undo log 支撑 MVCC，更新删除的旧版本进 history list 供并发会话读取。
💡 金句
B-trees are extremely quick to read. The goal of any index is to speed up reads at the cost of slower writes. Great for selective reads, awful for write heavy ingestion work.