推荐回答结构
结论 → 原因 → 排查/设计步骤 → 风险边界 → 验证与复盘。 场景信息不足时，先向面试官补问数据量、版本、业务影响和恢复目标。
一、基础与事务
1. InnoDB 的事务隔离级别解决了什么问题？
先说明四个标准隔离级别及并发异常，再结合 InnoDB 的一致性读、当前读、MVCC 与锁解释。回答重点不是背定义，而是说明不同读操作在同一隔离级别下行为可能不同，并指出隔离越强通常并发代价越高。
追问准备：快照读与当前读、幻读、Read View、next-key lock。
2. MVCC 是怎么让读写并发的？
InnoDB 通过隐藏事务信息、Undo 版本链和 Read View 判断某个版本对当前事务是否可见，使一致性读通常无需阻塞正在修改数据的事务。需要补充：MVCC 主要服务一致性读，当前读仍要读取最新版本并配合锁。
3. 一条 UPDATE 从客户端发出到提交，经历哪些关键步骤？
可沿连接与权限、解析与优化、执行器、InnoDB 查找与加锁、Undo 记录、修改 Buffer Pool、Redo、Binlog、两阶段提交、返回结果这条链路回答。追问时说明 Redo 保证崩溃恢复、Binlog 服务复制与时间点恢复，两阶段提交用于保持两者逻辑一致。
二、索引与性能
4. 为什么 InnoDB 常用 B+Tree，而不是普通二叉树或 Hash？
B+Tree 分支多、层级低，适合以页为单位的磁盘访问；叶子节点有序，既支持等值又支持范围、排序与前缀扫描。Hash 更适合等值查找，不天然支持范围与有序遍历。还应补充：索引是否有效取决于查询模式和数据分布，不是结构本身“绝对更快”。
5. SQL 很慢，你的完整排查顺序是什么？
先确认影响与基线，再拿真实 SQL、参数和执行频率；查看慢日志和执行计划；判断扫描行数、索引、排序、临时表、锁等待；同时关联 CPU、IO、Buffer Pool 与并发；形成改写、索引或架构方案；最后用压测、灰度和业务指标验证。
6. 建了索引但优化器没用，可能有哪些原因？
可能是联合索引顺序不匹配、函数计算、隐式转换、前导模糊、返回数据比例太高、统计信息偏差，或存在成本更低的其他路径。回答时强调先判断“不走索引”是否真的有问题，不直接 FORCE INDEX。
三、备份、复制与高可用
7. MySQL 主从延迟突然升高，怎么排查？
先确认延迟口径与业务影响，再判断是主库生成日志过快、网络传输慢、从库回放慢还是复制报错。关联主库大事务/DDL、从库 SQL 线程并行度、锁等待、IO/CPU、网络与复制状态。止损可考虑暂停异常任务、扩容读流量承载或调整业务，但不能跳过数据一致性验证。
8. 如何设计一套可靠的 MySQL 备份方案？
从业务 RPO/RTO 出发，组合物理全量、增量、Binlog 与必要的逻辑备份；备份文件要校验、加密、独立权限、异地保存和生命周期管理；最关键的是周期性在隔离环境完成恢复并做业务校验。
9. 高可用切换中，如何避免脑裂？
核心是可靠故障判断与旧主隔离。通过多点探测或仲裁减少误判，在提升新主前确认旧主无法继续写入；切换后验证路由、写入和复制拓扑。不能只追求更短切换时间，还要明确网络分区下的安全优先级。
四、生产场景题
10. 凌晨告警 MySQL 连接数 100%，你第一分钟做什么？
先确认错误率、接口与实例范围，冻结发布和高风险操作；采集 Threads_connected、Threads_running、processlist、锁和系统资源；区分空闲连接过多、慢 SQL/锁导致连接堆积，还是流量突增。根据根因限流、暂停任务或隔离异常应用，再验证业务与数据库指标共同恢复。
11. 误删了生产表，如何决定恢复方案？
立即停止扩大影响并保护 Binlog，记录误操作时间与事务信息。根据数据量、影响范围和 RTO 选择隔离实例的时间点恢复、从备份恢复后抽取对象，或利用可审计的反向操作。不能未经验证直接把恢复结果覆盖生产；应先校验数据，再通过受控变更回写。
12. 大表加索引如何降低业务影响？
先确认版本、表大小、写入量、磁盘余量、复制延迟与 DDL 能力；在影子环境估算耗时和空间；选择原生在线 DDL 或经过验证的在线变更工具；设置流控、暂停条件与监控；低峰灰度执行，并持续观察锁、延迟、IO、复制与业务错误率。
五、练习方法
- 先给自己 90 秒，不看答案口述结论与思路。
- 把答案录音，检查有没有业务影响、证据、风险和验证。
- 让同伴继续追问版本、数据量、RPO/RTO 与异常指标。
- 把不会的部分放进 Docker 故障环境亲手复现。