MySQL/InnoDB

B+ 树是多路平衡搜索树，非叶子节点只存键与指针不存数据，单页（16KB）能放更多键，树高通常三到四层即可支撑千万行，一次查询只要三四次页 IO；所有数据在叶子层且叶子间有双向链表，范围查询与排序沿链表顺序扫极高效，这是磁盘型数据库的核心诉求。对比哈希索引：等值查询 O(1) 但不支持范围与排序、不支持最左前缀，InnoDB 主索引不用哈希（仅自适应哈希做热点加速）。对比 B 树：数据分布全树导致非叶子节点扇出变小、树更高，且范围查询要中序回溯。对比红黑树与跳表：二叉结构树高过大页 IO 太多；跳表实现简单适合内存（Redis），磁盘场景 B+ 树的页局部性与扇出更优。能从「页 IO 次数等于树高」推导即满分。

聚簇索引按主键组织整行数据，表本身就是这棵 B+ 树，因此主键要短且趋势递增（随机主键导致页分裂与碎片，推荐自增或雪花 id）。二级索引（辅助索引）的叶子存索引列加主键值：按二级索引查到主键后还要回聚簇索引取整行，即回表，代价是两次树查找。覆盖索引指查询所需列全部包含在某个索引中（联合索引包含 where、order by、select 全部列），无需回表直接返回，explain 出现 using index 即命中，是高频优化手段。联合索引最左前缀原则：索引（a,b,c）支持 a、a加b、a加b加c 前缀匹配，列顺序把等值与高区分度列放前，范围列放最后（范围之后的列失效）。能讲回表流程与用覆盖索引消回表的例子即优秀。

原子性靠 undo log：事务修改前记录反向操作（insert 记 delete），回滚时逆序重放撤销，保证要么全做要么全不做。持久性靠 redo log：修改先写物理变更日志（顺序写、WAL 先写日志后写数据页），宕机后重放 redo 恢复已提交变更，redo 循环写且组提交保证性能，innodb_flush_log_at_trx_commit 控制刷盘策略。隔离性靠 MVCC 加锁：读走快照不加锁，写加行锁与间隙锁，配合隔离级别定义并发行为。一致性是目标而非机制，由前三者加应用层约束（唯一键、外键、业务校验）共同达成。答题按 A、D、I 各指名日志或锁，并补一句 redo 是物理日志循环写、undo 是逻辑日志可读（MVCC 依赖）即完整。

每行隐藏两个列：trx_id 最近修改它的事务 id、roll_pointer 指向 undo log 版本链，多次修改形成按时间倒序的链。ReadView 是快照读的一致性视图，含活跃事务集合、下一个事务 id 等信息，判断某版本可见的规则：trx_id 小于最小活跃 id 则已提交可见；大于等于 next id 则未开始不可见；在活跃集合中则未提交不可见；否则可见，不可见就沿 roll_pointer 找上一版本重判。RC 与 RR 的差别只在 ReadView 生成时机：RC 每次查询新建（能看到别的事务最新提交），RR 事务内第一次查询生成并复用（整个事务同视角）。快照读（普通 select）走 MVCC 不加锁，当前读（update、delete、select 加 lock in share mode 或 for update）读最新版并加锁。能讲可见性判断规则与两种隔离级别差异即满分。

redo log 是 InnoDB 引擎层物理日志，记录页级变更，循环写、崩溃恢复保证持久性，也是 WAL 性能基石。undo log 记录反向逻辑操作，用于回滚与 MVCC 版本链，存于回滚段。binlog 是服务器层逻辑日志（statement、row、mixed 格式），追加写，用于主从复制与时间点恢复，所有引擎共享。两阶段提交解决 redo 与 binlog 的一致性：提交流程写 redo 并标记 prepare，写 binlog，再写 redo 标记 commit；崩溃恢复时 redo 处于 prepare 则查对应 binlog 是否完整——完整就提交、不完整就回滚，保证两份日志要么都有要么都没有，否则主从与恢复点会脑裂。参数 sync_binlog 与 innodb_flush_log_at_trx_commit 的双一配置是最安全组合。组提交与 binlog 刷盘时机是延伸考点。能画时序并讲恢复判断即优秀。