InnoDB
MySQL默认存储引擎，采用B+树索引结构，支持完整ACID事务和行级锁，兼顾读写性能与数据一致性，是MySQL生产环境中最广泛使用的存储引擎
核心事实
时间轴 (近 90 天)
把在线业务从 InnoDB 迁移到 Iceberg 不只是更换连接串，而是需要重新定义一致性、延迟和成本之间的权衡。
InnoDB 擅长高频小事务和低延迟点查，Iceberg 擅长海量数据批量写入、分析型扫描和 schema 演进。
InnoDB 的复杂度来自‘就地更新’前提，Iceberg 的简洁来自‘文件不可变’前提；选存储方案时应先确定写入模式和存储介质再决定元数据形态。
InnoDB 是 MySQL 的行式存储引擎，面向在线事务处理，数据按 16KB 的页组织，表本身是一棵以主键为序的 B+ 树（聚簇索引）。
InnoDB 的写入路径为日志先行：任何修改先写 redo log，再异步刷脏页；崩溃后通过 redo 重放恢复，通过 undo 实现回滚和多版本读。
InnoDB 的 MVCC 通过就地修改行、用 undo 链跟踪旧版本实现：每行隐藏事务 ID 和回滚指针，回滚指针串起 undo log 中的旧版本形成版本链；已提交读（RC）每次语句执行生成新快照，可重复读（RR）在事务开始时生成快照。
InnoDB 的旧版本不会自动消失，需要 purge 线程在确认没有更早活跃事务引用后异步清理；长事务会拖住 purge，导致 undo 空间膨胀。
InnoDB使用B+树而非B树的关键原因是B+树非叶子节点只存键不存数据，单页能容纳更多索引项，树高更低、磁盘IO更少。
在相同硬件上MyRocks相比InnoDB实现了约50%的存储空间压缩，同时将写入IO减少约60%
全部知识事实 (11)
MySQL的InnoDB存储引擎默认使用B+树作为索引数据结构
65%待验证MySQL的LIMIT offset, N分页方式存在深分页性能问题，即使只需返回N条记录也必须先扫描并丢弃前offset条记录
60%待验证把在线业务从 InnoDB 迁移到 Iceberg 不只是更换连接串，而是需要重新定义一致性、延迟和成本之间的权衡。
50%待验证InnoDB 擅长高频小事务和低延迟点查，Iceberg 擅长海量数据批量写入、分析型扫描和 schema 演进。
50%待验证InnoDB 的复杂度来自‘就地更新’前提，Iceberg 的简洁来自‘文件不可变’前提；选存储方案时应先确定写入模式和存储介质再决定元数据形态。
50%待验证InnoDB 是 MySQL 的行式存储引擎，面向在线事务处理，数据按 16KB 的页组织，表本身是一棵以主键为序的 B+ 树（聚簇索引）。
50%待验证InnoDB 的写入路径为日志先行：任何修改先写 redo log，再异步刷脏页；崩溃后通过 redo 重放恢复，通过 undo 实现回滚和多版本读。
50%待验证InnoDB 的 MVCC 通过就地修改行、用 undo 链跟踪旧版本实现：每行隐藏事务 ID 和回滚指针，回滚指针串起 undo log 中的旧版本形成版本链；已提交读（RC）每次语句执行生成新快照，可重复读（RR）在事务开始时生成快照。
50%待验证InnoDB 的旧版本不会自动消失，需要 purge 线程在确认没有更早活跃事务引用后异步清理；长事务会拖住 purge，导致 undo 空间膨胀。
50%待验证InnoDB使用B+树而非B树的关键原因是B+树非叶子节点只存键不存数据，单页能容纳更多索引项，树高更低、磁盘IO更少。
50%待验证在相同硬件上MyRocks相比InnoDB实现了约50%的存储空间压缩，同时将写入IO减少约60%
50%