innodb是mysql默认存储引擎，核心支持事务、行级锁、外键及mvcc；采用聚簇索引（主键组织数据）、二级索引需回表、buffer pool缓存与wal机制保障性能与持久性。
InnoDB 是 MySQL 默认且最常用的存储引擎，核心优势在于支持事务、行级锁和外键约束，适合高并发、数据一致性要求高的业务场景。 它不是简单地把数据存到磁盘上，而是通过一套精密的结构设计，在内存与磁盘之间高效协同，兼顾性能、可靠性和并发能力。
基于 B+ 树的聚簇索引组织方式
InnoDB 表必须有主键，且数据按主键顺序物理存储在磁盘上，这种结构叫“聚簇索引”。整张表的数据文件（.ibd）本身就是一颗 B+ 树：叶子节点直接保存完整的行记录，而非指针。这意味着主键查询极快，范围扫描高效，但插入顺序若与主键无序（如用 UUID），会引发大量页分裂和碎片。
- 没有显式定义主键时，InnoDB 会自动创建隐藏的 6 字节 ROW_ID 作为聚簇索引，但不推荐依赖它
- 二级索引（非主键索引）的叶子节点不存行数据，只存主键值；查二级索引后需回表（再次查聚簇索引）才能拿到完整记录
- 联合索引遵循最左前缀原则，其 B+ 树按字段顺序逐层排序，可用于 WHERE、ORDER BY 和 GROUP BY 优化
多版本并发控制（MVCC）实现可重复读
InnoDB 不靠锁住整条记录来解决读写冲突，而是为每一行维护多个历史版本，配合事务系统视图（read view）判断哪些版本对当前事务可见。这使得普通 SELECT（快照读）无需加锁，大幅提升并发读性能。
- 每行记录包含两个隐藏字段：DB_TRX_ID（最后修改该行的事务 ID）、DB_ROLL_PTR（指向 undo log 中前一版本的指针）
- REPEATABLE READ 隔离级别下，事务启动时生成一个 read view，后续所有快照读都基于此视图判断可见性，从而避免不可重复读
- 当前读（如 SELECT ... FOR UPDATE、UPDATE、DELETE）会加行锁，并读取最新版本，可能触发 gap lock 或 next-key lock 防止幻读
缓冲池（Buffer Pool）与刷脏机制
InnoDB 在内存中维护一块大区域叫 Buffer Pool，用于缓存数据页和索引页。绝大多数读写操作先在内存中完成，大幅减少磁盘 I/O。但这也带来持久性挑战——崩溃后未写盘的数据会丢失，因此需要 WAL（Write-Ahead Logging）机制保障。
- Buffer Pool 默认占内存 50%～75%，可通过 innodb_buffer_pool_size 调整；命中率低于 95% 通常说明配置偏小
- 修改数据时，先写 redo log（顺序 I/O，快速落盘），再更新 Buffer Pool 中的页（称为“脏页”）；崩溃恢复时靠 redo log 重放操作
- 脏页由后台线程（如 Page Cleaner）异步刷回磁盘，刷盘时机包括：LRU 淘汰、空闲时、检查点（checkpoint）推进、或达到 innodb_max_dirty_pages_pct 阈值
事务日志（Redo Log & Undo Log）分工协作
InnoDB 的可靠性依赖两类日志：redo log 保证持久性（crash-safe），undo log 支持事务回滚和 MVCC 版本链构建。它们物理上独立于表空间，且设计为循环写入的小文件组。
- redo log 是固定大小的环形缓冲区（innodb_log_buffer_size），内容实时刷入磁盘上的 ib_logfile0/1；它记录的是“物理逻辑日志”，即“对某个页面的某个偏移量执行了什么修改”
- undo log 存储在共享表空间或独立 undo 表空间中，每个事务分配自己的 undo segment；除回滚外，它还被 purge 线程定期清理已无事务引用的历史版本
- 长事务会阻止 undo log 清理，导致 undo 表空间膨胀，甚至影响 MVCC 性能；应避免在生产环境长时间持有事务
理解 InnoDB 这些底层机制，不是为了手动调优每一个参数，而是能在慢查询、锁等待、主从延迟、OOM 等问题出现时，快速定位根因——是索引缺失？事务过长？Buffer Pool 不足？还是 redo log 写满阻塞了提交？掌握原理，才能真正用好它。
