# 1. InnoDB 死锁的检测与回滚？ A 死锁检测与锁类型无关 B InnoDB 无法检测死锁，只能等待超时 C 死锁发生时回滚所有相关事务 D InnoDB 通过等待图检测循环等待，回滚代价最小的事务，并用锁等待超时兜底 ✓ 正确答案
# 2. InnoDB 自增锁（AUTO-INC Lock）的模式，传统、连续、交叉？ A 自增锁模式与并发无关 B 三种模式都对所有 INSERT 加表级锁 C 模式 0 并发度最高 D 模式 2（交叉）并发度最高但自增值可能不连续有间隙；模式 1（连续，默认）对简单 INSERT 不锁表、批量 INSERT 加锁以保连续 ✓ 正确答案
# 3. InnoDB 行锁的算法，Record Lock、Gap Lock、Next-Key Lock？ A Next-Key Lock 是记录锁 + 间隙锁的组合，在 RR 下用于范围加锁防止幻读；RC 下只使用 Record Lock ✓ 正确答案 B Gap Lock 锁住记录本身，不锁区间 C Record Lock 锁住整个表 D 三种锁都只加在主键上，与索引无关
# 4. InnoDB 锁类型，共享锁（S）、排他锁（X）、意向锁（IS、IX）？ A 意向锁是行级锁 B S 锁与 X 锁不兼容，X 锁互斥；意向锁（IS/IX）是表级锁，用于避免加表锁时逐行检查行锁 ✓ 正确答案 C S 锁与 X 锁完全兼容 D X 锁允许其他事务加 S 锁
# 5. InnoDB MVCC 如何通过 undo log 版本链 + Read View 实现多版本读（沿 roll pointer 回溯，按 trx_id 与活跃事务列表比较判定可见性）？ A 通过 roll pointer 形成 undo 版本链，Read View 记录活跃事务列表，按 trx_id 与活跃事务比较判定某版本是否可见 ✓ 正确答案 B MVCC 需要加锁才能读取历史版本 C 版本链只保留最新版本，不支持历史读取 D Read View 与事务 id 无关
# 6. 当前读（SELECT ... FOR UPDATE/LOCK IN SHARE MODE、UPDATE、DELETE）与快照读在加锁行为上有何区别？RR 下如何用 Next-Key Lock 配合快照读共同防止幻读？ A 快照读不加锁、基于 MVCC 读历史版本；当前读加锁读最新版本，RR 下当前读靠 Next-Key Lock 防幻读 ✓ 正确答案 B 两种读都加锁 C 快照读也读取最新版本并加锁 D RR 下当前读不防幻读
# 7. RC 下 UPDATE 遇到被锁定的行为何要读取最新版本（当前读）并重新评估 WHERE（semi-consistent read）？这与 RR 的行为有何不同？ A 该优化只在 RR 下生效 B 该优化与会话冲突 C semi-consistent read 会读取未提交的数据 D RC 下 UPDATE 遇锁定时读取最新已提交版本重新评估 WHERE，不满足则跳过减少锁等待；RR 下不会使用该优化 ✓ 正确答案
# 8. MySQL 主从复制（Master-Slave）的搭建步骤？ A 复制无需 binlog B 主库配置 server-id 并开启 binlog、创建复制账号；从库配置 server-id、初始化数据后执行 CHANGE MASTER TO 与 START SLAVE ✓ 正确答案 C 只需从库配置，主库无需任何配置 D CHANGE MASTER 只指定主库 IP，无需 binlog 位置
# 9. 主从延迟（Replication Lag）的成因与监控，Seconds_Behind_Master？ A 主从延迟无法缓解 B Seconds_Behind_Master 永远精确反映延迟 C 成因包括大事务、从库单线程执行慢等；Seconds_Behind_Master 有局限，可用 GTID 差集或心跳表更精确监控 ✓ 正确答案 D 主从延迟只发生在异步复制，半同步无延迟
# 10. 并行复制（Multi-Threaded Slave）的演进，DATABASE、WRITESET、LOGICAL_CLOCK？ A DATABASE 模式并行度最高 B 演进为 DATABASE（按库）→ LOGICAL_CLOCK（按提交时间划分并行组）→ WRITESET（按写集合冲突精确判断），并行度依次提高 ✓ 正确答案 C WRITESET 模式按数据库并行 D 并行复制只能并行不同库的事务
# 11. 过滤复制（replicate-do-db、replicate-ignore-db）的应用？ A 过滤复制不影响从库数据完整性 B 过滤复制在 GTID 模式下无任何风险 C replicate-do-db 只复制表，不复制库 D 通过 replicate-do-db/replicate-ignore-db 等参数只复制指定库/表，但易造成数据不完整，需谨慎使用 ✓ 正确答案
# 12. 多源复制（Multi-Source Replication）的应用？ A 多源复制无需配置 channel B 多源复制只能从一个主库复制 C 一个从库通过多个 channel 同时从多个主库复制，常用于数据汇聚与分库汇总 ✓ 正确答案 D 多源复制不能用于数据汇聚
# 13. writeset-based 并行复制的依赖追踪？ A writeset 模式不需要 binlog B writeset 与事务修改的行无关 C writeset 模式判断任意两个事务都冲突 D 通过比较事务写集合是否有交集判断是否可并行，无交集则无冲突可并行，需 ROW 格式且比 LOGICAL_CLOCK 更精确 ✓ 正确答案
# 14. MySQL 半同步复制的原理与取舍，ack 时机（AFTER_COMMIT/AFTER_SYNC）对数据安全与延迟的影响，退化降级为异步复制的条件如何设置？ A 半同步复制永不降级为异步 B AFTER_COMMIT 比 AFTER_SYNC 更安全 C 半同步复制不等待从库确认 D AFTER_SYNC 先写/fsync binlog 再等从库 ack 后提交，数据更安全；超时（rpl_semi_sync_master_timeout）会临时降级为异步 ✓ 正确答案
# 15. Percona Xtrabackup 物理备份的原理（拷贝数据文件的同时持续追记 redo 变化，--prepare 阶段前滚 redo 达到一致）是什么？为什么结束阶段仍需短暂加全局锁？ A 备份时拷贝数据文件并持续追记 redo，--prepare 阶段前滚 redo 使数据一致；结束阶段短暂加全局锁以获取一致 binlog 位置 ✓ 正确答案 B --prepare 阶段丢弃 redo 变化 C 备份结束无需加锁也能获取 binlog 位置 D Xtrabackup 只记录 redo 不拷贝数据文件
# 16. Xtrabackup 增量备份如何基于 --incremental-lsn 只拷贝 LSN 之后变化的页？恢复时如何把多个增量依次合并（apply）到全量？ A 增量备份可独立恢复，无需全量 B 增量备份每次都拷贝全部数据 C 增量备份基于 --incremental-lsn 只拷贝 LSN 之后变化的页；恢复时用 --apply-log-only 依次把增量前滚合并到全量 ✓ 正确答案 D 恢复时合并增量的顺序可以任意
# 17. binlog 闪回工具（binlog2sql、MyFlash）如何从 ROW 格式 binlog 生成反向 SQL（DELETE↔INSERT、UPDATE 前后镜像互换）实现误删恢复？前提条件（binlog_format=ROW、binlog_row_image=FULL）是什么？ A 闪回工具直接修改 binlog 文件 B 靠解析 ROW 格式 binlog 的 before/after 镜像生成反向 SQL（DELETE↔INSERT、UPDATE 镜像互换），前提是 binlog_format=ROW 且 binlog_row_image=FULL ✓ 正确答案 C binlog_row_image=MINIMAL 也能提供完整镜像 D 闪回只需 STATEMENT 格式 binlog
# 18. MySQL PITR 的完整流程（还原全量备份 → 用 mysqlbinlog 按 --stop-datetime/--stop-position 重放到误删前一刻）是怎样的？如何跳过引发故障的事务？ A --stop-datetime 不能指定位置 B PITR 只需重放 binlog，无需还原全量备份 C 流程是还原全量备份后用 mysqlbinlog 按 --stop-datetime/--stop-position 重放到误删前，通过定位故障事务位置跳过该事务 ✓ 正确答案 D PITR 无法跳过引发故障的事务
# 19. mysqldump 的 --source-data/--master-data 与 --set-gtid-purged 如何记录备份点坐标/GTID 集合？它们在搭建从库与增量衔接中的作用是什么？ A --master-data 只记录表结构，不记录位置 B 这两个参数与复制无关 C --set-gtid-purged 记录 binlog 位置 D --source-data/--master-data 记录 binlog 文件名与位置，--set-gtid-purged 记录 GTID 集合，用于从备份点继续复制与增量衔接 ✓ 正确答案
# 20. 并行备份恢复工具（mydumper/myloader、mysqlpump）如何按表/按块提升效率？在一致性保证与线程数上有哪些取舍？ A 线程数越多永远越好，无副作用 B mydumper/myloader 按表/按块多线程并行导出/导入，配合 --single-transaction 保证一致性；线程数需在速度与线上负载间权衡 ✓ 正确答案 C 并行工具无法保证一致性 D mydumper 只能单线程备份
# 21. 如何验证备份可用性（恢复到沙箱实例、pt-table-checksum 与生产比对、关键表行数与校验和）？ A 沙箱恢复不能验证数据完整性 B 备份生成后无需验证，必定可用 C 验证只需看备份文件大小 D 通过恢复到沙箱实例、pt-table-checksum 比对、关键表行数与校验和比对来验证备份可恢复，并应定期演练 ✓ 正确答案
# 22. 物理备份有哪些版本兼容性限制（Xtrabackup 版本需匹配 MySQL 版本、不能跨大版本或降级恢复）？ A Xtrabackup 版本与 MySQL 版本无关 B 物理备份可跨任意大版本恢复 C Xtrabackup 版本需匹配 MySQL 版本，物理备份不能跨大版本或降级恢复，跨版本通常改用逻辑备份 ✓ 正确答案 D 物理备份可以降级恢复
# 23. MHA vs Orchestrator 的取舍？ A Orchestrator 比 MHA 更简单 B MHA 轻量简单、脚本驱动、切换较慢；Orchestrator 功能强、有拓扑管理与 Web UI、支持 Raft 集群化、切换更快 ✓ 正确答案 C MHA 自带可视化管理界面 D 两者功能完全相同
# 24. MHA（Master High Availability）的选主与切换流程？ A 检测主库故障后，选择数据最完整、最接近主库的从库作为新主，补 binlog 后提升并让其他从库指向新主 ✓ 正确答案 B MHA 随机选择任意从库做新主 C MHA 切换不需要补 binlog D MHA 切换后原从库不再作为从库
# 25. Orchestrator（GitHub）的工作原理与拓扑管理？ A Orchestrator 无法持久化拓扑信息 B 它自动发现并持久化 MySQL 复制拓扑，提供 Web UI 与自动故障切换，自身基于 Raft 实现集群高可用 ✓ 正确答案 C Orchestrator 不提供故障切换 D Orchestrator 只能管理单主拓扑
# 26. ProxySQL 的应用，读写分离、查询路由？ A ProxySQL 不提供连接池 B ProxySQL 只能做负载均衡，不能路由 C ProxySQL 会修改 SQL 语句 D 通过 hostgroup 分组主从库，用 query rules 按 SQL 特征把写路由到主库、读路由到从库，实现读写分离 ✓ 正确答案
# 27. MHA Orchestrator ProxySQL 的协同架构？ A ProxySQL 自己完成主从切换，无需 HA 工具 B MHA 负责读写分离，ProxySQL 负责复制 C ProxySQL 负责读写分离与路由，MHA/Orchestrator 负责故障切换，切换后需让 ProxySQL 感知新主库并更新路由 ✓ 正确答案 D 三者功能完全重叠
# 28. innodb_buffer_pool_size 的设置原则，物理内存的 50%-80%？ A 通常取物理内存的 50%-80%，需为操作系统、连接、线程等预留内存，过大可能 OOM、过小命中率低 ✓ 正确答案 B 应设为物理内存的 100%，充分利用内存 C Buffer Pool 大小与内存无关 D Buffer Pool 越大越好，无需预留
# 29. innodb_flush_log_at_trx_commit 的语义，0、1、2？ A 该参数越大越安全 B 0 是默认且最安全 C 2 每次提交都立即 fsync D 1 每次提交 fsync 刷盘最安全，0 每秒刷盘最快但可能丢最多数据，2 写 OS 缓存每秒刷盘折中 ✓ 正确答案
# 30. innodb_log_file_size、innodb_log_files_in_group 的设置？ A redo 总容量等于两者乘积，过小会频繁触发 checkpoint 刷脏增加 IO，过大则占用磁盘与恢复时间越长 ✓ 正确答案 B 两者乘积与 redo 容量无关 C redo log 越小，性能越好 D 这两个参数只影响 binlog
# 31. sync_binlog 的语义，0、1、N？ A 0 是最安全配置 B N 每次提交都 fsync C 1 每次提交 fsync 最安全，0 由 OS 决定刷盘最快但可能丢 binlog，N 每 N 次提交刷盘一次折中 ✓ 正确答案 D sync_binlog 控制 redo log 刷盘
# 32. after_sync 模式下从库确认后主库才提交，主库故障时为何不丢已确认事务？ A after_sync 确认时 binlog 尚未落盘 B after_sync 先提交再等 ack，所以更安全 C 因为 after_sync 先写 binlog 并 fsync、等从库 ack 后才提交，确认时事务 binlog 已持久化且从库已持有，故障时可由从库补回 ✓ 正确答案 D after_sync 下从库不保存 binlog
# 33. MySQL 参数的全局与会话设置？ A 全局变量影响整个实例、新连接生效，会话变量只影响当前连接；SET GLOBAL/SET SESSION 分别设置，会话默认继承全局值 ✓ 正确答案 B 所有变量都只能全局设置 C 会话变量影响所有连接 D 全局变量只能查看不能修改
