# 1. Buffer Pool 的 LRU 改进，midpoint insertion、young/old 区？ A 新页先插入 young 与 old 区的分界点，在 old 区停留超过 innodb_old_blocks_time 再被访问才提升到 young 区 ✓ 正确答案 B 新读入的页直接插入到 LRU 链表头部，保证最热访问 C old 区占比由配置固定为 50%，不可调整 D 全表扫描的页会立即被提升到 young 区以加速后续访问
# 2. InnoDB Buffer Pool 的工作机制，缓存数据页与索引页？ A 数据修改直接写磁盘，仅在内存中保留只读副本 B Buffer Pool 只缓存数据页，不缓存索引页 C 页的修改在内存中完成并标记为脏页，通过 redo 日志保证持久性，脏页异步写回磁盘 ✓ 正确答案 D 每次修改都会立即把整页写回磁盘以降低风险
# 3. Redo Log 与 Binlog 的协同（两阶段提交）？ A 先写 binlog，再写 redo log，崩溃时以 binlog 为准 B 先 redo prepare，再写 binlog，最后 redo commit；崩溃时若 binlog 有对应 XID 则提交，否则回滚 ✓ 正确答案 C Redo Log 与 Binlog 互相独立，无需协调 D 两阶段提交中 binlog 先于 redo 写入磁盘
# 4. Redo Log（InnoDB Log）的作用，崩溃恢复、写入路径？ A Redo Log 记录逻辑 SQL 语句，用于主从复制 B 遵循 WAL，先写 redo log 再写数据页；崩溃时重放 redo 恢复已提交事务 ✓ 正确答案 C Redo Log 大小无限，无需 checkpoints 回收 D 事务提交时总是先写数据页再写 redo log
# 5. Undo Log 的作用，MVCC、回滚、purge？ A Undo Log 保存旧版本镜像，支撑事务回滚与 MVCC 版本链，由 purge 线程异步清理不再被引用的旧版本 ✓ 正确答案 B Undo Log 只用于主从复制，不参与回滚 C Undo Log 记录物理页修改，用于崩溃恢复 D Undo Log 在事务提交后立即全部删除，不保留历史版本
# 6. InnoDB Change Buffer 的原理（对非唯一二级索引的增删改先缓存、待页读入时合并，减少随机 IO）是什么？为什么唯一索引无法使用 Change Buffer？ A 它缓存所有索引的增删改操作，包括唯一索引与主键 B 它只缓存非唯一二级索引的增删改，待页读入时合并以减少随机 IO；唯一索引因需实时校验唯一性而无法使用 ✓ 正确答案 C 它把数据页直接写入磁盘，减少内存占用 D 它只用于读取优化，与写操作无关
# 7. 自适应哈希索引（AHI）如何对热点 B-Tree 页自动建立哈希加速等值查找？为什么高并发写入场景常建议关闭（哈希锁/latch 竞争反而降速）？ A AHI 需人工创建，用于加速范围查询 B AHI 存储在磁盘上，不占用内存 C AHI 由 InnoDB 自动为热点页建立的哈希索引，加速等值查找；高并发写入时哈希 latch 竞争可能反降性能，故建议关闭 ✓ 正确答案 D AHI 只适用于唯一索引
# 8. InnoDB 自适应刷脏（根据 redo 生成速度与 checkpoint 年龄调整脏页刷新率）如何避免 redo 写满导致阻塞？与 innodb_io_capacity/innodb_max_dirty_pages_pct 的关系是什么？ A 刷脏速率固定不变，与 redo 生成速度无关 B 自适应刷脏与 redo log 无关，只影响 undo log C innodb_io_capacity 越大，脏页永远不会被刷盘 D 根据 redo 生成速度与 checkpoint 年龄动态调整刷盘力度，避免 redo 写满阻塞；innodb_io_capacity 是刷盘 IO 上限，innodb_max_dirty_pages_pct 是脏页比例阈值 ✓ 正确答案
# 9. InnoDB 的聚簇索引（Clustered Index），数据按主键顺序存储？ A 每张表可以有多个聚簇索引，分别存储不同列的数据 B 聚簇索引的叶子节点直接存储整行数据，数据按主键逻辑顺序排列，每表只能有一个 ✓ 正确答案 C 聚簇索引只存主键列，需回表才能取整行 D 没有主键的表无法使用聚簇索引
# 10. 二级索引（Secondary Index）的查找，先查主键再回表？ A 二级索引叶子节点存整行数据，无需回表 B 先查二级索引得到主键，再回聚簇索引取整行，这个过程叫回表；覆盖索引可避免回表 ✓ 正确答案 C 二级索引查找一次即可，与主键无关 D 回表只在非唯一二级索引查询时发生
# 11. 覆盖索引（Covering Index）在 InnoDB 的实现？ A 二级索引包含查询所需全部列（含主键列）时即覆盖索引，可避免回表，EXPLAIN 显示 Using index ✓ 正确答案 B 覆盖索引只能用于唯一索引 C 覆盖索引是聚簇索引的一种，存储整行数据 D 覆盖索引会降低查询性能，因需读取更多列
# 12. MySQL 8.0 的原子 DDL（Atomic DDL），DDL 操作的回滚支持？ A 借助 redo/undo 与数据字典 InnoDB 化，使 DDL 要么全部成功要么全部回滚，避免部分完成的中间状态 ✓ 正确答案 B 原子 DDL 仅适用于 MyISAM 表 C 原子 DDL 与普通 DML 无关，不记录任何日志 D 原子 DDL 只支持 CREATE TABLE，不支持 ALTER/DROP
# 13. GTID 的并行复制，writeset-based、LOGICAL_CLOCK？ A LOGICAL_CLOCK 依据提交时间近似划分并行组，WRITESET 依据写集合是否冲突，WRITESET 并行度更高且需 ROW 格式 ✓ 正确答案 B LOGICAL_CLOCK 依据事务修改的行集合是否冲突判断并行，WRITESET 依据提交时间 C 两种方式都基于数据库名称划分并行 D WRITESET 模式无需 binlog 即可运行
# 14. GTID（Global Transaction Identifier），全局事务标识？ A GTID 只用于日志归档，不影响复制 B GTID 格式是"binlog 文件名 + 偏移量" C GTID 由 server_uuid 与事务序号组成，全局唯一，可自动确定复制位置，简化主从切换与从库搭建 ✓ 正确答案 D GTID 在每个从库上独立生成，不随 binlog 传播
# 15. Group Replication（MGR），基于 Paxos 的强同步复制？ A MGR 只支持 MyISAM 引擎 B MGR 基于 Paxos 共识，写事务需组内多数派确认后才提交，实现强同步复制，支持单主与多主模式 ✓ 正确答案 C MGR 是异步复制，可能丢失已提交事务 D MGR 无需网络通信，节点之间完全独立
# 16. Buffer Pool 大小规划（数据量、热点集、命中率）与多实例（instance）分片 A Buffer Pool 大小应尽量小以节省内存，命中率无关紧要 B 命中率越低说明 Buffer Pool 越大越好，与热点集无关 C 依据热点集与命中率规划大小（常为物理内存 50%-80%）；多实例分片为每个实例独立 LRU 与锁，分散并发竞争 ✓ 正确答案 D 实例数量越多，每个实例的 LRU 链表越共享，锁竞争越大
# 17. MySQL Binlog 的格式，STATEMENT、ROW、MIXED 的取舍？ A ROW 记录行级镜像，一致性强但日志量大，生产环境多推荐 ROW 以保证一致性与闪回能力 ✓ 正确答案 B STATEMENT 记录行级变更，日志大但精确 C MIXED 始终使用 ROW 格式 D STATEMENT 完全一致，无任何不确定性
# 18. MySQL 复制的一致性，异步/半同步/组复制在数据一致性上的差异，主从延迟导致的读写不一致如何检测与缓解？ A 异步复制主库等待从库确认后才提交，一致性最强 B 三种复制的一致性完全一致 C 异步复制一致性最弱、半同步降低丢失窗口、组复制基于多数派确认提供强一致；主从延迟时强一致读可强制走主库 ✓ 正确答案 D 半同步复制比组复制一致性更强
# 19. sys schema 的应用，sys.diagnostics、sys.io_global_by_file_by_latency？ A sys schema 是独立于 Performance Schema 的新监控数据源 B sys schema 只能查看 binlog 内容 C sys schema 基于 Performance Schema 数据封装成易用视图/存储过程，如 sys.diagnostics 收集诊断、sys.io_global_by_file_by_latency 按文件统计 IO 延迟 ✓ 正确答案 D sys schema 需要手动创建才能使用
# 20. Buffer Pool 的预读（Read-Ahead）机制？ A 当检测到区中页面被顺序访问时，提前把相邻页批量读入 Buffer Pool，减少随机 IO 次数，提升顺序扫描性能 ✓ 正确答案 B 预读会显著降低顺序扫描性能 C 预读结果不放入 Buffer Pool，直接返回给客户端 D 预读只用于随机访问，不适用于顺序读
# 21. Online DDL 的工作原理，ALGORITHM=INPLACE、LOCK=NONE？ A 所有 DDL 都支持 ALGORITHM=INPLACE 和 LOCK=NONE B ALGORITHM=COPY 表示原地修改，不重建表 C LOCK=NONE 表示禁止任何读写 D ALGORITHM=INPLACE 多数操作不重建表，LOCK=NONE 允许 DDL 期间并发读写，靠增量日志捕获并发 DML ✓ 正确答案
# 22. Online DDL 的执行阶段，准备、执行、提交？ A 只有执行阶段有锁，准备与提交阶段无锁 B 三个阶段分别是准备、执行、提交，执行阶段最长，提交阶段需短暂独占锁更新元数据 ✓ 正确答案 C 三个阶段都使用 COPY 算法 D 提交阶段可以长时间与 DML 并发
# 23. Online DDL 与 pt-online-schema-change 的取舍？ A pt-osc 会长时间锁住原表 B 原生 Online DDL 永远优于 pt-osc，无需评估 C 两者原理完全相同，没有区别 D pt-osc 通过镜像表 + 增量同步 + 表名切换实现在线变更，适合 COPY 类操作与低版本；原生 Online DDL 适合新版本且支持 INPLACE 的操作 ✓ 正确答案
# 24. Performance Schema 的开销控制？ A 关闭 instrument 会破坏数据字典 B 通过 instrument 与 consumer 的双层开关、采样率及历史表容量限制来控制采集开销 ✓ 正确答案 C 只能通过重启 MySQL 控制开销 D Performance Schema 没有任何开销，无需控制
# 25. Performance Schema 的架构，instrument、consumer、table？ A instrument 决定是否消费数据 B table 负责采集，instrument 负责存储 C consumer 是代码中的埋点 D instrument 采集事件，consumer 决定是否消费，table 保存采集结果，三者构成采集流水线 ✓ 正确答案
# 26. InnoDB 数据页与行格式（COMPACT/DYNAMIC）对存储与索引的影响 A 所有行格式都把所有字段完整存储在行内 B 行格式不影响存储空间与索引性能 C DYNAMIC 对长字段（TEXT/BLOB）完全溢出存储，行内只留指针，适合大字段表；COMPACT 行内保留 768 字节前缀（超出部分溢出存储） ✓ 正确答案 D COMPACT 是 MySQL 8.0 的唯一默认格式
# 27. Buffer Pool 命中率下降时的排查，从容量、SQL 模式与预热角度分析？ A Buffer Pool 命中率永远不变，无需排查 B 命中率下降只与磁盘故障有关 C 命中率下降只能通过增大内存解决 D 应从容量（Buffer Pool 过小）、SQL 模式（全表扫描等冷读）、预热（冷启动未缓存）三个角度排查 ✓ 正确答案
