吊打面试官？MySQL 高频面试题/知识点全收录（2026 最新版）

填满你的记忆

773人浏览 · 2026-01-12 21:29:50

填满你的记忆 · 2026-01-12 21:29:50 发布

兄弟们，面试里最尴尬的场景是什么？

不是你完全不会，而是你背了标准答案，面试官追问一句“为什么”，你却卡住了。

面试官：“为什么 MySQL 用 B+ 树做索引？”

你：“因为……快？”

面试官：“Hash 不快吗？B 树不快吗？红黑树不快吗？”

你：“……”

到了 2026 年，单纯的“八股文”已经不够用了。现在的面试官更看重你的技术深度和设计思维。今天这篇，我把 MySQL 拆解成 “架构篇”、“索引篇”、“事务篇”、“锁与日志篇” 四大板块。

我不教你死记硬背，我教你理解数据库的底层逻辑。掌握了这些，面试官不论怎么换着法问，你都能稳稳接住。

第一章：架构篇 —— 别上来就聊 SQL，先看全貌

面试官潜台词：“这小子是只知道 CRUD，还是真的懂数据库是怎么跑起来的？”

1.1 一条 SQL 的奇幻漂流

当你在客户端敲下 select * from user where id = 1 时，MySQL 内部发生了什么？

很多人只知道“去磁盘查数据”，这就太浅了。

MySQL 的架构其实非常像一个“正规公司”：

第一层：Server 层（公司管理层）

这里不存数据，只负责处理业务逻辑。

连接器（前台）：负责跟你握手、验权。长连接太久导致 OOM？因为 MySQL 在执行查询过程中临时内存管理的问题，5.7 以后可以用 mysql_reset_connection 来重置，别傻傻地重启服务。
分析器（秘书）：先词法分析（识别 select、from），再语法分析（看你 SQL 写没写错）。
优化器（核心大脑）：决定是用索引 A 还是索引 B，是先 Join 还是先 Filter。注意： 有时候你觉得索引没生效，其实是优化器觉得全表扫描比走索引回表更划算（基于 Cost 成本模型）。
执行器（项目经理）：它不干活，它调用底下“打工仔”的接口拿数据。

第二层：存储引擎层（底层打工仔）

这才是真正存数据的地方。最常见的就是 InnoDB（支持事务、行锁，现在的老大）和 MyISAM（不支持事务，过气网红）。

1.2 面试避坑指南

如果面试官问：“MySQL 的 Query Cache（查询缓存）去哪了？”

切记：MySQL 8.0 已经把查询缓存删掉了！因为这玩意儿弊大于利——只要表有更新，缓存就全清空，对于更新频繁的库来说，命中率极低。

第二章：索引篇 —— 数据库的灵魂

这是面试的重灾区，80% 的性能问题都出在这里。

2.1 为什么偏偏是 B+ 树？（经典三连问）

别上来就背 B+ 树的定义，要有对比才有伤害。

为什么不用 Hash？
- Hash 是 O(1)，确实最快。但它是一盘散沙，不支持范围查询（where age > 18），也不支持排序。
为什么不用二叉树/红黑树？
- 树太高了！ 数据库的数据是存在磁盘上的。如果红黑树有 1000 万数据，树高可能有几十层。每一层查询都是一次磁盘 I/O，磁盘读写那么慢，这查询速度能急死人。
为什么不用 B 树（B-Tree）？
- B 树的每个节点都存 Data。但一页内存（Page）通常只有 16KB。如果 Data 很大，一页也存不了几个节点，树依然很深。
- B+ 树的进化：只有叶子节点才存 Data，非叶子节点只存索引。一页能存几千个索引，这棵树就变得**“矮胖矮胖”**的。通常 3 层就能存 2000 万行数据，意味着查一次数据最多只要 3 次磁盘 I/O。

2.2 聚簇索引 vs 非聚簇索引

这两个词听起来很高大上，其实很简单：

聚簇索引（Clustered）：索引即数据。找到索引就找到了整行数据。在 InnoDB 里，主键就是聚簇索引。
非聚簇索引（Secondary）：索引即指针。叶子节点存的是“主键 ID”。
- 回表（Back to table）：这就引出了一个性能杀手。比如 select * from user where name='zs'。你先在 name 树上找到 ID，再拿 ID 去 主键 树上找整行数据。多跑了一趟路，这就叫回表。
- 优化思路：利用覆盖索引（Select ID, Name...），只查索引树上有的字段，就不用回表了。

2.3 索引失效的本质

不要死记硬背那句口诀（什么模棱两可、最左前缀...）。失效的本质只有一句话：

“操作破坏了 B+ 树的有序性”。

like '%xx'：前面都不确定，怎么用二分法找？有序性破了。
func(age) > 10：对字段做函数计算，树里存的是 age，不是 func(age)，有序性破了。
类型隐式转换：字符串不加引号，数据库得隐式转换成数字，相当于加了函数，有序性破了。

第三章：事务与锁 —— ACID 的守护神

3.1 事务四大特性（ACID）的底层实现

背下 ACID 没用，你要知道是谁保证了它们：

A (原子性)：靠 Undo Log。事务失败了？没关系，根据 Undo Log 里的记录反向操作回去（回滚）。
C (一致性)：这是最终目的，靠 AID 共同保证。
I (隔离性)：靠 MVCC + 锁。
D (持久性)：靠 Redo Log（WAL 机制）。

3.2 隔离级别与 MVCC（面试反杀点）

MySQL 默认级别是 RR（可重复读）。

面试官问：“RR 级别下，怎么解决不可重复读的？”

答案：MVCC（多版本并发控制）。

原理人话版：

MySQL 里的每一行数据，其实都有好几个“影分身”（历史版本），存放在 Undo Log 链条里。

事务开启时，会拍一张**“快照”（Read View）**。

RC 级别：每次 Select 都重新拍一张快照（所以能读到别人刚提交的）。
RR 级别：只有事务里第一次 Select 拍快照，后面都复用这一张。不管别人怎么改，我看的数据永远是我进门时看到的样子。

第四章：日志篇 —— MySQL 为什么不会丢数据？

这里要对比 Redis 的 AOF/RDB 来聊，显得你知识体系通透。MySQL 有两本账本：Redo Log（物理帐） 和 Binlog（逻辑帐）。

4.1 为什么需要两份日志？

Binlog：归 Server 层管，所有引擎都有。主要用于归档、主从复制。但它追加写，没有 Crash-safe 能力。
Redo Log：归 InnoDB 管。它是循环写的（写完了回头覆盖）。它让 MySQL 拥有了“崩溃恢复”的能力。

4.2 两阶段提交（Two-Phase Commit）

这是为了保证 Redo Log 和 Binlog 的逻辑一致性。

Prepare 阶段：写 Redo Log，标记为 prepare。
Write 阶段：写 Binlog。
Commit 阶段：提交事务，Redo Log 标记为 commit。

反杀点：如果中间断电了怎么办？

MySQL 重启后会检查：

如果 Binlog 没写完 -> 回滚。
如果 Binlog 写完了，Redo Log 只有 prepare -> 自动提交（因为 Binlog 已经有了，为了主从一致，这笔账得认）。

第五章：实战优化篇 —— 假如给你一条慢 SQL

面试官：“系统突然变慢了，怎么查？”

这是一个考察工程能力的题目，千万别只回答“加索引”。要按步骤来：

看监控：先确认是数据库的问题，还是网络/CPU 的问题。
找凶手：开启 Slow Query Log（慢查询日志），设置阈值（比如 1s），抓出那些拖后腿的 SQL。
做体检：用 EXPLAIN 命令分析。
- 看 type：是不是 ALL（全表扫描）？最好优化到 ref 或 range。
- 看 key：实际走了哪个索引？有没有走错？
- 看 Extra：有没有 Using filesort（在磁盘做排序，很慢）或者 Using temporary（用了临时表，巨慢）。
开药方：
- 索引优化：满足最左前缀，把区分度高的字段放前面。
- 覆盖索引：select id, name 代替 select *，消灭回表。
- 大分页优化：limit 1000000, 10 改为 where id > 1000000 limit 10（利用主键索引快速定位）。

🎁 附赠：面试题参考答案集锦（可直接背诵）

为了让你面试时更从容，我整理了几个核心问题的“高分回答范本”。

Q1: 说说 MySQL 的索引结构？为什么用 B+ 树？

参考回答：

MySQL InnoDB 引擎默认使用 B+ 树。相比于 Hash，B+ 树支持范围查询和排序；相比于二叉树或红黑树，B+ 树更“矮胖”，层高通常只有 3 层，大大减少了磁盘 I/O 次数。

另外，B+ 树只有叶子节点存储数据，非叶子节点只存索引，这让一页内存能容纳更多索引。且叶子节点之间有双向指针，非常适合做全表扫描和范围查询。

Q2: 什么是 MVCC？它是怎么工作的？

参考回答：

MVCC 是多版本并发控制，主要用于在 RC 和 RR 隔离级别下实现“读写不冲突”。

它通过数据行的隐藏字段（Roll Pointer）和 Undo Log 构建数据的历史版本链。在事务查询时，会生成一个 Read View（快照）。

RR 级别下，事务全程复用同一个 Read View，从而保证可重复读；RC 级别下，每次查询都会生成新的 Read View，所以能读到已提交的数据。

Q3: 慢 SQL 优化有哪些思路？

参考回答：

首先通过慢查询日志定位到具体 SQL，然后用 Explain 分析执行计划。

索引层面：检查是否走了索引，是否符合最左前缀原则，是否有索引失效（如对字段计算、隐式转换）。

语句层面：避免 Select *，尽量用覆盖索引；优化 limit 深分页；用小表驱动大表。

架构层面：如果单表过大，考虑分库分表或读写分离。