简介：面向 MySQL 面试准备的精华知识点整理文档，以高频问答形式串联数据库核心考点，适合准备后端、数据库相关岗位面试或巩固 MySQL 基础的学习者，可作为考前快速回顾的提纲。内容覆盖关系型与非关系型数据库区别、一条 SQL 语句执行步骤、索引底层数据结构、B+ 树设计动机、聚簇索引与二级索引、MyISAM 与 InnoDB 索引实现差异、普通索引与唯一索引选择、覆盖索引、索引下推、索引失效场景，并延伸至 change buffer、redo log 与 binlog 等日志机制。每个问题都给出简要结论与关键原理说明，条理清晰、重点标注分明，便于理解记忆，也能帮助读者建立完整的 MySQL 知识框架。资源共 1 个 docx 文档，压缩包约 40KB，按题号逐条整理，方便打印或导入笔记工具；目前已有 251 人学习下载，适合考前冲刺与日常复盘。
1. MySQL 面试考的不是背答案：为什么同样一道题，有人答完就进下一轮，有人被追问到底
MySQL 面试题在网上流传很多，但你真去面一次就会发现问题：几乎每个面试官都会问“一条 SQL 的执行流程”“索引为什么用 B+ 树”“redo log 和 binlog 的区别”。这些确实是高频考点，但光背答案根本不够。同样答“先连接器、分析器、优化器、执行器”，有人能拿满分，有人被一句“那执行器怎么知道有没有权限”问住就卡壳了。原因很简单——MySQL 面试考的是你能不能用一条链路把这些知识点串起来：从语句执行走到索引，从索引回表走到日志，从日志崩溃恢复走到主从同步，每一步之间都是面试官顺手深挖的线索。这份 MySQL 面试题知识点总结就是按这条链路组织的，帮你把每个考点背后的逻辑、易错点、答题话术一次说透。
2. 高频考点：一条 SQL 从客户端到返回结果，每一步卡点在哪
2.1 Server 层执行链路：连接器、查询缓存、分析器、优化器、执行器各管什么
第一条被问烂了的题：一条 MySQL 语句的执行步骤。许多人的答案就一句话“连接器、分析器、优化器、执行器”，然后没了。这个问题其实是送分题，但也是分层题——面试官会顺着每一层追问一层，就看你对每一层职责是否有真实理解。
标准的执行链路是：客户端请求到连接器，连接器验证身份并管理权限；然后是查询缓存，命中就直接返回，但注意 MySQL 8.0 之后查询缓存被移除了，这也是一个可以主动说的加分点；分析器做词法分析和语法分析，语法错了会直接报错；优化器决定用哪个索引、表的连接顺序；执行器先判断有无执行权限，再调引擎接口去取数据。这个顺序本身并不难记，难在每一步的边界。
最有区分度的追问是“执行器到底判断的什么权限”。面试官想听的是：执行器会调用precheck校验，同时真正去引擎取数据时还会做权限判断。另一个常见追问是“分析器怎么识别表名字段名”，答案核心是词法分析把字符串切成 token，语法分析根据语法规则生成语法树。这题想答得漂亮，就把顺序说成一条流水线，并主动点出每一步失败时的表现，比如表不存在是分析器阶段报错，权限不足是执行器阶段报错。
2.2 查询缓存的坑与 8.0 之后的考法变化
老题库里必有“查询缓存命中直接返回”，但现在的面试题风向已经变了。你要主动提到：查询缓存失效非常频繁，只要对表做一次更新，所有缓存清空，所以在更新频繁的业务里收益是负的，这也是为什么 8.0 直接把查询缓存删掉了。这个信息点能让面试官觉得你不是背的旧答案。
回答模板可以这样组织：查询缓存位于连接器之后、分析器之前；缓存 key 是 SQL 文本加上当前库名等；命中直接返回，不命中才继续往下走；MySQL 8.0 起移除该模块。说完之后补一句“所以现在的执行链路实际是连接器直接到分析器”。这题就算答透了。
2.3 执行计划怎么成了面试官手里最顺手的“追问钩子”
执行链路接下来就会引到优化器怎么选索引，面试官最常拿“一个 SQL 没走索引，你怎么排查”来钩你。答题思路分三刀：先EXPLAIN看type和key，type显示ALL就是全表扫描；再看rows估值和filtered；自己动手ANALYZE TABLE更新统计信息。聊到这就顺势说出“优化器是根据区分度估算的，它并不精确知道有多少行”，这是原资料里反复强调过的点。
这题的易错点是直接答“没走索引就是索引失效”，其实还有表数据量太小优化器觉得没必要走索引、统计信息不准、或者走了索引但回表太多反而不如全扫。面试官最爱听的就是你能区分“索引失效”和“优化器选择”两种情况。从执行链路一路聊到执行计划和索引选择，这个开头就算开稳了。
3. 高频考点：索引——数据结构、类型、失效场景、下推与覆盖，一道题引出一串题
3.1 为什么是 B+ 树而不是哈希和 B 树：先讲场景再背结论
“InnoDB 为什么用 B+ 树”几乎是 MySQL 面试的必考题。它的标准答法不是直接背优缺点，而是先摆两个约束条件：InnoDB 要同时支持等值查询、范围查询、排序；CPU 从磁盘加载数据很慢，所以要尽量减少随机 IO。哈希虽然等值 O(1)，但范围查询直接废掉，只能全表扫；B 树的非叶子节点也存数据，导致相同的容量存更少的索引项，树更高，连续数据查询时可能产生更多随机 IO；B+ 树的数据全在叶子节点，叶子节点用指针串成链表，范围查询按链表顺序扫就行，天然适配磁盘预读。
面试官还可能追一个数字：N 叉树大概 N 是多少。原资料里给过一个具体推导：InnoDB 中一个整数字段索引 N 差不多 1200，树高 4 的时候能存 1200 的三次方，约 17 亿行；树根常驻内存，10 亿行表的整数索引查一个值最多访问 3 次磁盘。说完这个数字，面试官基本就能确定你是真理解而不是背稿子。注意点：哈希、有序数组、搜索树三种数据结构的对比表要按“等值、范围、更新成本、适用场景”四个维度说。
3.2 聚簇索引和二级索引：叶子节点存什么，决定了回表怎么发生
索引类型按叶子节点内容分，主键索引叶子节点存整行数据，叫聚簇索引；非主键索引叶子节点存主键值，叫二级索引。这句话谁都会背，真正拉开差距的是你能不能讲清楚回表是怎么发生的。典型场景：select * from t where k = 5，k 上有普通索引，过程是先到 k 的 B+ 树找到主键 id，再用这个 id 去主键索引树查整行数据，这就是回表。
这里有一个几乎必被追问的对比题：MyISAM 和 InnoDB 的 B 树索引实现有什么不同。核心区别一个就够了——InnoDB 的叶子节点保存数据本身，数据文件就是索引文件；MyISAM 叶子节点保存的是数据记录的物理地址，索引文件和表数据文件分离。面试官听完多半会补一句“那 MyISAM 的回表是什么意思”，你要能接住：MyISAM 的索引叶子节点直接指向物理地址，严格说不需要像 InnoDB 那样二次搜索主键树。
3.3 最容易翻车的实操题：like 模糊、函数计算、隐式转换、OR 条件，四类失效场景
索引失效是高频中的高频，原资料给了四类，但面试时你要答出“为什么失效”而不只是“什么情况失效”。like 左模糊或左右模糊失效，原因是不知道从哪个索引值开始比较；对索引字段做函数或表达式计算失效，因为索引存的是原始值，不是函数计算后的值；隐式转换相当于包了一层函数，比如字符串字段拿数字去比，MySQL 会把字段转成数字再比，索引直接废掉；OR 条件只要有一个列不是索引列，整个查询就可能全表扫描。
这题有个很妙的加分话术：先给结论“这些操作本质都是让索引列不再保持原始可比较状态”，再逐个举例。面试官如果追问“那 like ‘abc%’ 能不能走索引”，你要明确说能，只有左模糊不行。这正好是很多人背了四类场景却答错的地方——右模糊可以走索引，范围查询也能走索引。
3.4 覆盖索引与索引下推：两个让查询提速的“白嫖”机制
覆盖索引的理解关键在“减少树的搜索次数”。查询的字段恰好都包含在索引里，比如表里有普通索引 k，查select k from t where k between 3 and 5，索引 k 的叶子节点已经有 k 值，就不需要回表拿整行。原资料的表述是“索引 k 覆盖了查询需求”。这题面试官常接一个追问：覆盖索引适合什么场景，答案是高频查询的字段列表尽量都塞进联合索引。
索引下推是 MySQL 5.6 引入的优化，缩写 ICP。核心一句话：在索引遍历过程中，对索引包含的字段先做判断，过滤掉不满足条件的记录，减少回表次数。举例最直观：联合索引(name, age)，查询where name like '张%' and age = 10。没有 ICP 时，先按 name 范围把多条记录回表，再在回表后过滤 age；有 ICP 时，在索引遍历阶段直接判断 age 字段，回表次数就少了。答这题要把“减少回表”说成核心收益，面试官一般会追问“ICP 一定有效吗”，你要答“取决于过滤掉的记录比例，比例越高收益越大”。
3.5 普通索引和唯一索引怎么选：change buffer 才是真正的考点
“普通索引还是唯一索引”其实是个陷阱题，重点不在索引本身，而在 change buffer。唯一索引因为要立即判断唯一性约束，必须先把数据页读进内存做检查，所以用不上 change buffer；普通索引可以先把更新操作缓存在 change buffer 里，不影响一致性。原资料的结论是：业务能接受，优先选普通索引。
change buffer 的适用场景也要能展开说：写多读少的业务效果好，比如账单、日志类系统；反过来如果是写入后马上查询，数据页立刻被访问，会触发 merge，随机 IO 没减少，反而多了维护 change buffer 的开销。这题答到“唯一索引更新必须读页，所以无法缓存”就已经赢了，时间允许再补场景对比。
4. 高频考点：日志三兄弟——redo log、binlog、两阶段提交与崩溃恢复，面试深水区
4.1 WAL 技术：为什么先写日志再写磁盘，而不是先写磁盘
WAL 的意思是 Write-Ahead Logging，先写日志，再写数据磁盘。MySQL 更新操作把数据写进内存就返回，后续异步刷盘，这样能快速响应。但如果没写日志就崩溃，内存数据全丢，所以必须先把更新记录到 redo log。这个逻辑链条要理清楚：为了快速响应，所以异步写盘；为了 crash 后能恢复，所以先写日志。两条一拼，WAL 的理由就完整了。
面试官常用追问：redo log 写入方式。回答要点是 redo log 分内存缓冲 redo log buffer 和磁盘日志文件 redo log file，还有 OS buffer 这一层中转。关键参数是innodb_flush_log_at_trx_commit，三个取值必须有对比：0 每秒刷，事务提交不刷，性能最好但丢一秒数据；1 每次提交都刷，最安全，性能最差；2 每次提交写 OS buffer，每秒刷盘，性能和数据安全折中。这个参数表几乎是每次面试都会考的送分点。
4.2 redo log 和 binlog 的区别、为什么 redo log 能做 crash-safe
redo log 和 binlog 的区别题，建议用一张对比表来答，面试官会点头，因为信息密度高、不啰嗦。维度包括：归属层、写入方式、用途、是否具备 crash-safe 能力。redo log 是 InnoDB 引擎层的日志，循环写，记录的是未刷盘的数据变更，已经刷盘的就抹掉，所以数据库重启后只需重放 redo log 里的记录就能恢复到内存；binlog 是 Server 层日志，追加写，保存全量日志，但没有标志位区分哪些数据已刷盘、哪些没有，所以光靠 binlog 无法恢复未刷盘的数据到内存。结论一句：crash-safe 能力属于 redo log，binlog 不具备，binlog 的价值在主从复制和数据恢复。
这题还有一个深挖方向：redo log 内部结构是基于页的，记录的是页中哪些字段值变了，这样崩溃后重放就能恢复。binlog 在崩溃前可能没写完整，所以不能单独承担 crash-safe。回答时把“循环写 vs 追加写”作为核心差异反复扣住，这个区分能解释后面所有问题。
4.3 两阶段提交：为什么写 redo log 要拆成 prepare 和 commit
两阶段提交是所有日志题里最抽象的一个，也是最能拉开分数的一个。MySQL 把 redo log 的写入拆成 prepare 和 commit 两步，中间穿插写 binlog。原因一句话：redo log 和 binlog 是两个独立个体，必须逻辑一致才能让数据安全和备份恢复对齐。如果不拆，先写 redo log 后写 binlog，崩溃时 binlog 缺一次更新，备份恢复后数据不一致；先写 binlog 后写 redo log，崩溃时 redo log 没写入，事务无效，但 binlog 已经记录了这次操作，两边还是对不上。
恢复规则就两条，背下来就能回答后续所有恢复题：恢复时 redo log 状态是 commit，说明 binlog 也成功，直接恢复数据；redolog 状态是 prepare，则去查对应的 binlog 事务是否完整，完整就执行，不完整就回滚。另外要能说出“怎么判断 binlog 完整”——statement 格式的 binlog 最后有 COMMIT，row 格式最后有 XID event。把这两条接上，崩溃恢复问题的主干就答完了。
4.4 崩溃恢复的三种现场：从 redo log 和 binlog 的两个 fsync 节点说起
面试官最狠的追问是“数据库 crash 后，未刷盘的数据怎么恢复”。原资料直接给了三种情况，按 redo log 是否 fsync、binlog 是否 fsync、事务是否 commit 排列组合。第一种：change buffer 已写入，redo log 做了 fsync 但没 commit，binlog 没 fsync，这部分数据丢失；第二种：redo log fsync 未 commit，binlog 已经 fsync，先从 binlog 恢复 redo log，再从 redo log 恢复 change buffer；第三种：redo log 和 binlog 都已 fsync，直接从 redo log 恢复。
答题时要先说清楚判断依据，再说操作顺序。面试官真正想听的是“你能区分丢了和能恢复”的边界。这里有个非常重要的态度分：你要主动说“第一种情况严格说是丢失，但业务上一般可接受，因为事务没提交成功”。这句话能体现出你不是机械记忆，而是理解事务语义。
4.5 binlog 三种格式：什么时候选哪个，各有什么坑
binlog 格式是日志题的常客，三种格式是 statement、row、mixed。statement 记录 SQL 语句本身，日志量小，但主从复制时存储过程、函数、触发器可能复制出错；row 记录每行数据的变化，日志量大，但最精确；mixed 混合，一般语句用 statement，特殊函数用 row。原资料说得很明白：row 格式非常清楚记录每行修改细节，不会出现某些场景无法正确复制的问题。
实际面试中这种题的加分答法是主动提出生产环境推荐 row，并补一句“误删数据恢复必须依赖 row 格式，因为要反转 binlog”。这句话既表达了实操经验，又为后面误删恢复的题埋了伏笔。如果聊到 mixed 可以补一句：mixed 本身是 statement 和 row 的结合，MySQL 根据具体 SQL 判断用哪种。
5. 高频考点：存储引擎、大表查询、临时表、kill 命令和误删恢复——实战题的围剿区
5.1 InnoDB、MyISAM、MEMORY 三引擎对比与选型逻辑
引擎对比题是八股里最容易答但是也容易答偏的。正确打开方式是先把三个引擎的定位说清楚：InnoDB 支持事务 ACID、行锁、外键，5.5.5 之后是默认引擎；MyISAM 插入和查询速度快，但不支持事务，5.5.5 之前是默认；MEMORY 表存在内存里，访问快，但有两个致命问题——锁粒度大、重启丢数据。然后落到选型逻辑：要事务选 InnoDB，读写并发高选 InnoDB，临时性高速查询可以考虑 MEMORY 但不建议生产环境用。
MEMORY 引擎是面试官爱深挖的点，原资料专门有一条“都说 InnoDB 好，那还要不要用 MEMORY”。答题思路是先承认 MEMORY 适合快速访问，然后展开两大坑：锁粒度问题导致并发写入被卡；数据不持久化，重启丢数据，备库重启会导致主备同步线程停止，双 M 架构下甚至可能把主库内存表数据删掉。这题答得好不好，取决于你能不能讲清“重启丢数据”在主从架构里会引发连锁问题。
5.2 大表查询为什么不会爆内存：边读边发和 Buffer Pool 的改良 LRU
“大表查询为什么不会爆内存”是一道反直觉题，答好了很加分。核心原理是 MySQL 边读边发，server 端不保存完整结果集，取数据和发数据用 next_buffer 操作，客户端接收慢就会堵住查询过程，但不会把内存打爆。这部分原资料讲得非常清楚：服务端不需要保存完整结果集，内存里的数据页在 Buffer Pool 中操作。
Buffer Pool 用改进的 LRU 管理，链表按 5:3 分成 young 区域和 old 区域，冷数据全扫描的影响可控。面试官追问“什么是改进的 LRU”时，你要说出年轻区和老区的比例，以及全表扫描的页只进 old 区，避免把热点数据挤出内存。这条题表面在问内存，实际在考你对 InnoDB 缓冲池机制的理解深度。
5.3 临时表的特性与实际用途：session 可见、可与普通表重名、自动删除
临时表这题考的是概念准确度。三个特性先说全：只对当前 session 可见；可以和普通表重名，增删改查用的是临时表；线程退出自动删除。然后说用途：处理复杂计算逻辑。加分点是主动提一句“临时表因为是每个线程自己可见的，多线程执行同一处理逻辑时不用考虑重名问题”。这题的易错点是有人会把临时表和 MEMORY 内存表混在一起答，注意区分：临时表可以指定存储引擎，不一定在内存里。
5.4 kill 命令为什么杀不掉：三条原因，层层定位
kill 命令有两个：kill query 终止正在执行的语句，kill connection 断开连接。面试官问“kill 不掉的原因”其实是想听排查思路。原资料给了三层：kill 命令被堵了还没到位；到位了但没被立刻触发；被触发了但执行完需要时间。答题时按时间轴推进，像排查问题一样一层层说，每个环节补一个可能场景。这道题考的不只是记忆，而是排查思维，所以不要当概念题答。
5.5 drop、truncate、delete 三连问：不只是速度对比
drop、truncate、delete 的区别是数据库运维方向的必考题。delete 是逐行删除，作为事务记录在日志里可以回滚；truncate 一次性清空，不记逐行日志，不能回滚，不会触发删除触发器；drop 直接释放整张表的空间。速度排序 drop > truncate > delete。选型逻辑要背全：删部分数据用 delete 带 where，回滚段要够大；删表用 drop；保留表但要清空、与事务无关用 truncate；需要触发 trigger 用 delete；整理碎片可以 truncate 后重新导入数据。
6. 易错点专项：索引与日志题里最常踩的五个失分点
6.1 分不清“索引失效”和“优化器不选索引”
面试中非常多的人把“SQL 没走索引”直接答成“索引失效了”，这是失分重灾区。这两者本质不同：索引失效是索引结构上无法使用，比如函数计算、隐式转换；优化器不选索引是索引能用，但优化器根据区分度、回表成本、表行数估算，判断全表扫描更快。典型的例子是表只有几百行，怎么查都是全表扫更快。答法：先说原因分类，再说怎么验证，用 EXPLAIN 看 type 和 key，必要时用force index测试。原资料提到的“order by b limit 1 改成 order by b,a limit 1”就是引导优化器换索引的经典手法，可以当案例说。
6.2 like 查询的死记硬背：只说“like 不走索引”直接翻车
这题错得太常见。很多考生背了“like %xx 和 %xx% 不走索引”，一遇到“like abc% 走不走”就懵。实际上右模糊可以走索引，因为 MySQL 知道从哪个索引值开始比较，范围是明确的；只有左模糊和左右模糊才会失效。更隐蔽的坑是“前缀索引”场景：给字符串列建前缀索引后，因为选中的区分度不够，也可能不走索引。原资料给了四个解决方案：完整索引、前缀索引、倒序存储加前缀索引、hash 字段索引。答这题时把右模糊能走索引主动说出来，就能和背题的人拉开差距。
6.3 redo log 参数记反：把 innodb_flush_log_at_trx_commit 的三个值搞混
这个参数几乎人手一份答案，但很多人死在细节：0 是每秒刷、事务提交不刷；1 是每次提交都刷；2 是每次提交写 OS buffer、每秒刷盘。易错点是有人把 0 和 2 记反——0 不写 OS buffer，是延迟写，丢数据的窗口最大；2 每次都写 OS buffer，所以即使还没刷盘，操作系统层面已经有一条记录，安全性介于 0 和 1 之间。面试答题顺序建议按照“安全级别从高到低”说：1 最安全、2 折中、0 最快。再补一句生产环境一般用 1，追求性能的场景可以权衡用 2，但别主动建议 0，除非你聊的是明确能接受丢数据的日志场景。
6.4 两阶段提交恢复规则答反：prepare 和 commit 的状态判断反了
这是日志题里最容易答反的关键逻辑。正确规则是：redo log 状态为 commit，说明 binlog 也成功，直接恢复；redo log 状态为 prepare，需要查 binlog 是否完整，完整就继续执行，不完整就回滚。许多人一紧张就答成“prepare 都回滚”，直接把一半的恢复场景整错了。记忆方法：prepare 是“犹豫状态”，binlog 是本地的另一个参与方，它写完了就说明这事能成。答题时顺手把判断 binlog 完整的方法一起说出来——statement 格式末尾 COMMIT，row 格式末尾 XID event——既答全了又显得你见过真实场景。
6.5 误删数据恢复：没上来就先说“恢复前先恢复到临时实例”
误删数据恢复题，很多考生上来就背工具：xtrabackup、mysqldump、myflash，但漏掉了最重要的前置纪律。原资料给了一个关键细节：恢复数据时应该先恢复到临时实例，再恢复回主库。这条不先说，面试官会觉得你缺少生产意识。正确顺序：先做预防——权限控制、操作规范、SQL 审计、延迟备库、定期备份；备份选型——数据量大用物理备份 xtrabackup，数据量小用 mysqldump；DML 误操作用 flashback 类工具解析 binlog 反转，把 delete 反转 insert、update 前后 image 对调，前提是 binlog_format=row、binlog_row_image=full；DDL 误操作只能全量备份加 binlog 应用恢复；rm 删除就直接讲异地备份。把“先临时实例”放在最前面，后面的工具细节才显得有实战框架。
7. 把这些考点串成一套答题节奏：MySQL 面试的四种追问套路与应对顺序
7.1 套路一：从执行流程抽出一条逻辑主链
MySQL 面试的追问通常遵循四种固定套路，每种都有对应的思路框架。第一种是从执行流程切入，面试官会从一条 update 语句问你执行经过，你要快速决定把这条主链展示出来：连接器验证身份、分析器解析语法、优化器定执行计划、执行器走权限、InnoDB 在内存里改数据、写 redo log 进入 prepare、写 binlog、redo log 进入 commit、最终返回成功。这条链路里已经包含了索引选择、日志提交、两阶段提交三个高频子考点，一旦你能一气呵成地说完，面试官会在这条链的节点上继续深挖，你的知识网覆盖得越全，被问倒的概率越低。
7.2 套路二：顺着索引失效反推知识边界，先答原因再给验证
第二种是给一条慢 SQL 让你分析，这时候你要调动一套固定的排查顺序：先用 EXPLAIN 看扫描行数和索引使用情况，判断是没走索引还是走了索引但回表太多；再分析索引失效的四类原因，把函数计算、隐式转换、左模糊、OR 条件逐一排除；如果都不是，考虑统计信息过旧，执行 ANALYZE TABLE 或引导优化器换索引。原资料给出的 force index、修改语句写法、新建更合适索引这三种手段，就是慢 SQL 分析题的标准收尾动作。这个顺序就是先给结论再给验证，面试官会觉得你的答题结构是经过真实排障训练出来的。
7.3 套路三：面对崩溃恢复场景题，先分情况再给恢复动作
第三种最难，因为它是把日志概念变成场景题。常见问法：“突然数据库宕机，怎么保证数据不丢？”很多人上来就答“redo log 有 crash-safe 能力”，这不算错，但没有层次。更好的结构是三段式：第一段说正常路径——事务提交时 redo log 负责 crash-safe，binlog 负责备份恢复；第二段说异常路径——如果 redo log 状态是 commit，直接恢复数据；如果是 prepare，查 binlog 完整性决定执行还是回滚；第三段说更极端的情况——如果 binlog 没 fsync、redo log 没 commit，这部分数据就是丢失的，这是事务未提交的正常结果。这样答完之后，面试官如果再往深处挖，你已经提前把三种现场摆在他面前了。
7.4 套路四：误删数据类问题，用“预防优先级”代替“操作优先级”
误删恢复题很多人把它当成单纯的操作题，但其实它最像运维场景题。面试官想听的不是“你会不会用 myflash”，而是“你有没有预防意识”。正确节奏是：预防手段放在前面——权限控制、操作规范、SQL 审计、延迟备库、定期备份；备份的物理和逻辑两条路线要清晰——数据量大用 xtrabackup，数据量小用 mysqldump；然后才是误删后的恢复流程——DML 误操作靠 binlog 反转，先恢复到临时实例再回主库；DDL 误操作只能全量备份加 binlog 重建。这个顺序体现的是你对“数据完整性是 DBA 最核心的工作”（原资料原话）的理解，而不是你背了几个工具名。
7.5 我的答题习惯：先从最稳定的节点开始，再扩散到相邻考点
面试到最后，我发现能稳定拿高分的 MySQL 考生几乎都有同一个习惯：他们不从一个孤立背下来的答案开始，而从一个最稳定、最确定的节点开始。比如我被问到索引时，会从“InnoDB 的 B+ 树叶子节点存数据”这个最确定的点向外扩散——所以非主键索引要回表，所以覆盖索引能省掉回表，所以索引下推能减少回表，所以回表太多会让一条 SQL 变慢，所以优化器可能在回表成本高的时候不选索引。从一个节点扩散成一条因果链。从那以后我每次准备 MySQL 面试，都会强制自己把所有知识点串成“执行链路、索引链路、日志链路、恢复链路”四条线去复述。这个习惯让我在遇到自己没准备过的偏题时，也能迅速找到最近的确定节点，顺着逻辑推下去。希望这份思路能帮你在下一场面试里少一点慌乱，多一点稳定。
本文还有配套的精品资源，点击获取
