MySQL面试考点地图：索引、事务、锁与优化全攻略

很多 Java 开发者面试前都会做一件事：疯狂刷 MySQL 八股文。索引、事务、MVCC、explain、慢查询……背得滚瓜烂熟，结果真到了面试现场，面试官换一个问法就答不上来。

原因很简单：你背的是答案，不是解决问题的思路。

MySQL 在 Java 技术栈里太重要了。它几乎是国内互联网公司的标配数据库，而 Java 面试中 MySQL 相关问题的出现频率，常年排在 JVM、并发、Spring 之后的第一梯队。面试官问 MySQL，不是在考你记性好不好，而是想确认两件事：第一，你写出来的 SQL 是不是真的能扛住生产环境的并发和压力；第二，系统出了问题，你是两眼一抹黑，还是能顺着日志和锁机制快速定位。

这篇文章不会把网上能找到的所有 MySQL 面试题都抄一遍。我会从「面试官实际考察点」出发，把 MySQL 面试高频考点拆成几个核心模块——存储引擎、索引、事务、锁、日志、SQL 优化、主从复制——每个模块都讲清楚原理、常见问法、容易踩的坑，以及面试官期待的回答逻辑。

如果你正在准备 Java 面试，建议按照文末的 3 天复习路线来规划 MySQL 部分。看完这篇文章，你能建立一张完整的 MySQL 考点地图，后面再看到任何一道 MySQL 面试题，你都能立刻判断它考的是哪个模块、应该从哪些角度回答。

1. 面试前的 MySQL 考点地图：先知道考什么，再决定学什么

很多准备面试的人有一个习惯：打开搜索框，搜「MySQL 面试题」，然后照着长篇大论的题库从头刷到尾。这样做的效率极低，因为你把时间平均分配给了高频题和冷门题，最后记住的反而是最不常考的东西。

MySQL 面试题可以按考察频率和重要性分成三层。

第一层是必考题。索引的原理和失效场景、事务的 ACID 和隔离级别、MVCC 的实现机制、InnoDB 和 MyISAM 的区别。这四块内容几乎每家公司的面试都会问到，而且经常是连环追问。比如面试官先问「为什么 InnoDB 用 B+ 树」，你答完索引结构后，他又会追问「那最左前缀原则是怎么回事」「什么情况下索引会失效」「覆盖索引和回表是什么」。这些问题的底层知识是连在一起的。

第二层是高概率题。SQL 优化和慢查询排查、行锁与表锁、死锁的原因和排查、redo log 和 binlog 的区别与两阶段提交、主从复制的原理。如果面试的是高级岗位，或者面试官想考察你有没有真实项目经验，这些内容会很自然地出现在对话里。

第三层是加分题。MySQL 8 的新特性、int(5) 的含义、utf8mb4 字符集的选择、连接数、Buffer Pool 等参数调优思路。这些内容不一定每家都问，但答好了能明显提升面试官对你的印象。

这篇文章的正文就按照这个分层来展开。你现在要做的不是马上开始背答案，而是先跟着这篇文章把每个模块的核心原理搞清楚。原理懂了，面试现场不管问题怎么变，你都能用底层逻辑去回答。

2. MySQL 存储引擎：为什么 InnoDB 成了事实标准

存储引擎几乎是 MySQL 面试的第一个话题，因为它是理解后续所有内容的基础。MyISAM 和 InnoDB 的对比是经典送分题，但很多人答不完整，总是在枚举特性，没有讲清楚「为什么」。

2.1 MyISAM 和 InnoDB 的核心区别

先看一张对比表：

光记住这张表还不够。面试官更关注的是：你知道这些区别，对实际开发有什么影响？

2.2 面试官追问：为什么现在默认用 InnoDB

这个问题的标准回答思路是「因为业务场景需要事务和并发控制」。

互联网业务的典型场景是：用户下单扣库存、转账、订单状态变更，这些操作必须保证一致性。以转账为例，A 账户扣钱和 B 账户加钱必须同时成功或同时失败。MyISAM 不支持事务，一个 UPDATE 执行到一半系统崩溃，数据就处于中间状态，没有人知道应该回滚还是继续。InnoDB 通过事务和 redo/undo 日志解决了这个问题。

并发控制是另一个关键点。MyISAM 使用表级锁，意味着对一张表的任何写操作都会锁住整张表。在低并发场景下问题不大，但互联网业务动辄上千的 QPS，一个 UPDATE 锁住整张表，后面所有读写请求都会被阻塞，性能会断崖式下降。InnoDB 的行级锁只锁定涉及的行，其他行的读写完全不受影响。

还有一个隐藏点：InnoDB 在崩溃恢复方面远胜于 MyISAM。数据库宕机后，InnoDB 可以通过 redo log 重放未完成的事务，保证数据不丢失；MyISAM 则可能直接出现表损坏，需要长时间修复。

2.3 MyISAM 还有没有用武之地

这个问题属于加分项。MyISAM 在某些场景下仍有一点价值：表数据极少、完全只读、不需要事务、并发极低的历史归档表。它的索引结构更简单，某些全表扫描场景下可能更快。但从 MySQL 8.0 开始，MyISAM 被进一步边缘化，官方建议所有新业务都使用 InnoDB。回答时可以说：「从技术选型上我不会再选 MyISAM，除非是极特殊的历史只读场景。」

3. 索引：MySQL 面试的半壁江山

索引是 MySQL 面试中占比最大、追问最深的一块。如果把 Java 面试比作一场考试，索引就是最后的压轴大题，前面的基础题答得再好，压轴题答崩了照样挂。

3.1 为什么是 B+ 树而不是 B 树、哈希表

先想一个问题：数据库索引到底要解决什么问题？

答案是：在数据量很大的情况下快速定位数据。磁盘读取很慢，一次磁盘 I/O 能读到的数据有限，如果每次查找都做很多次随机磁盘 I/O，系统性能会废掉。B+ 树就是为此设计的。

B+ 树和 B 树的区别，要从两个维度看。

第一，B+ 树的非叶子节点不存储数据，只存储键值和指针。这意味着每个非叶子节点能容纳更多的键，树的高度更矮。一棵 3 层的 B+ 树可以存储千万级甚至上亿条数据，而查询只需要 3 次左右的磁盘 I/O。B 树的非叶子节点也存数据，同样的数据量，树会更高，I/O 次数更多。

第二，B+ 树的所有数据都存储在叶子节点，并且叶子节点之间有链表相连，天然支持范围查询。WHERE age > 20 AND age < 30 这样的条件，在 B+ 树上找到一个起点后，可以顺着链表依次扫描。B 树的叶子节点没有链表，范围查询需要回到树中间做中序遍历，性能远不如 B+ 树。

那哈希表呢？哈希索引的查找复杂度是 O(1)，单行查询非常快，但它有两个致命问题：不支持范围查询、不支持排序。哈希表是一一映射，age > 20 这种操作需要把所有数据都哈希一遍，完全走不了索引。所以 MySQL 的 InnoDB 引擎在绝大多数场景下都使用 B+ 树，哈希索引只存在于自适应哈希索引这种辅助结构中。

3.2 聚簇索引、二级索引和回表

这是面试里最容易被问懵的一组概念，但它们非常重要，因为直接关系到 SQL 的性能。

InnoDB 的表数据本身就是索引结构。聚簇索引的叶子节点存储的是完整的行数据，所以一个表只能有一个聚簇索引。默认情况下，InnoDB 会用主键作为聚簇索引；如果表没有主键，InnoDB 会选一个非空唯一索引；再不行就用隐藏的 rowid 生成一个。

二级索引（也叫非聚簇索引）的叶子节点存储的是索引列的值和主键值。当你要通过二级索引查数据时，流程是先查二级索引找到主键，再用主键回聚簇索引查完整行数据。这个「用主键再查一次」的过程就叫回表。

举个例子：

-- 表 person，主键 id，二级索引 idx_name SELECT * FROM person WHERE name = '张三';

执行过程分两步：第一步，通过 idx_name 索引找到 name 为「张三」的记录，得到主键 id；第二步，用 id 回到聚簇索引，取出完整记录。如果 name 索引覆盖了你要查的所有字段，那就不用回表了，这就是覆盖索引。

覆盖索引是 SQL 优化的常用手段。比如SELECT id, name FROM person WHERE name = '张三'，idx_name 索引里既有 name 又有 id，直接查索引导出结果，不需要回表。面试官问「怎么优化 SQL」，你答一句「用覆盖索引避免回表」，他立刻知道你有实战经验。

3.3 最左前缀原则

联合索引 (a, b, c) 在匹配时会遵守最左前缀原则：查询条件必须从最左边的列开始连续匹配。WHERE a = 1、WHERE a = 1 AND b = 2、WHERE a = 1 AND b = 2 AND c = 3都能走索引，但WHERE b = 2或WHERE c = 3走不了。

这个原则背后是 B+ 树的结构决定的。联合索引的排序规则是先按 a 排，a 相同再按 b 排，b 相同再按 c 排。所以你想直接跳过 a 用 b 查询，索引顺序上 b 不是全局有序的，没法用二分查找。

实际开发中最常见的坑是：建了联合索引，但查询条件的顺序不对。WHERE b = 2 AND a = 1其实能走索引，因为 MySQL 查询优化器会自动调整条件顺序。真正让索引失效的是WHERE a = 1 AND c = 3，c 跳过了 b，只能用 a 来缩小范围，c 的筛选就要回表后做了。

3.4 索引失效的常见场景

面试官问索引失效，通常是在考察你写 SQL 时有没有基本意识。高频失效场景包括：

• 对索引列使用函数或表达式，如WHERE UPPER(name) = 'ZHANG'、WHERE age + 1 = 30
• 隐式类型转换，如索引列是字符串类型，查询条件用数字
• 使用 LIKE 且通配符在开头，如WHERE name LIKE '%张'
• OR 连接非索引列
• 联合索引不满足最左前缀原则

回答时可以补一句「索引失效不是绝对的，最终以执行计划为准」，然后拿出 explain 来验证。这种回答方式明显比死记硬背更有说服力。

4. 事务与隔离级别：脏读、不可重复读、幻读的底层逻辑

事务是 MySQL 面试必考内容，只背四个隔离级别不够，要理解每个隔离级别解决的问题，以及 InnoDB 是怎么实现隔离的。

4.1 ACID 到底在说什么

事务有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。面试官喜欢让候选人用自己的话解释这四个概念，目标是看你能不能把抽象概念讲得清晰。

原子性：一个事务里的所有操作要么全部成功，要么全部失败，不能只做一半。比如转账 100 元，A 扣钱成功但 B 加钱失败，整个事务就要回滚到转账前状态。

一致性：事务执行前后，数据都处于合法状态。这个特性最抽象，底层依赖原子性、隔离性和持久性共同保证。举个例子：转账前后，A 和 B 的账户余额总和不变。

隔离性：多个事务并发执行时，互相之间不能产生干扰。比如两个人同时改同一条订单记录，事务隔离要保证他们看到的数据是合理的。

持久性：事务提交后，修改必须永久保存，即使数据库崩溃也不能丢。InnoDB 通过 redo log 实现这一点。

4.2 四种隔离级别与三类问题

SQL 标准定义了四种隔离级别：

先解释三个问题：

脏读：事务 A 修改了一条数据，还没提交；事务 B 读到了这条修改后的数据；事务 A 回滚，事务 B 读到的数据就是脏数据。

不可重复读：事务 A 先读取 id=1 的记录，然后事务 B 修改并提交了这条记录，事务 A 再读一次，发现数据变了。同一个事务内两次读取结果不一致。

幻读：事务 A 查询某条件下的记录集合，事务 B 插入了一条满足该条件的新记录并提交，事务 A 再次查询时，发现结果集合多了一行，像「幻觉」一样。

MySQL 默认隔离级别是可重复读（REPEATABLE READ）。InnoDB 通过 MVCC 和间隙锁，在可重复读级别下解决了幻读问题，这是它和标准 SQL 术语的一个差异点，也是面试中很有含金量的一句话。

4.3 MVCC：多版本并发控制的核心机制

MVCC 全称 Multi-Version Concurrency Control，多版本并发控制。它的核心思想是：读写不互相阻塞。写事务修改数据时，读事务仍然可以读到之前版本的数据，前提是隔离级别允许读旧版本。

InnoDB 在每行数据后面隐藏了两个字段：trx_id（最近修改该行的事务 id）和 roll_pointer（指向 undo log 中的旧版本链）。当一个事务要读取某行时，它会检查自己的 Read View，判断哪些版本对它可见。

Read View 是一个事务启动时生成的快照，里面记录了系统中活跃事务的 id 列表。判断规则大致是：如果行的 trx_id 小于 Read View 中最小活跃事务 id，说明这个版本在 Read View 生成前已经提交，可见；如果 trx_id 大于最大活跃事务 id，说明这个版本在 Read View 生成后才创建，不可见；如果 trx_id 在活跃列表中，说明该版本对应的修改事务还未提交，不可见，需要沿 undo log 找更早的版本。

这就是可重复读的实现原理：事务在第一次读取时生成 Read View，之后每次读取都用同一个 Read View，所以同一事务内多次读取结果一致。而读已提交级别每次读取都会生成新的 Read View，所以能读到其他事务新提交的数据。

回答 MVCC 时，能画出 Read View 的判断逻辑就比单纯背诵「MVCC 解决了读写阻塞问题」要高一个档次。

5. 锁机制与死锁排查：从行锁到间隙锁

锁是和事务并发强相关的主题。面试官问锁，通常不是要你背锁的类型列表，而是考察你在高并发场景下，能不能判断出哪一类锁可能导致性能问题、死锁怎么发生、怎么排查。

5.1 行锁、表锁、意向锁

InnoDB 支持行级锁和表级锁。行级锁粒度小、并发度高，但有加锁开销；表级锁粒度大、并发度低，适合整表操作。InnoDB 默认使用行级锁，但某些场景下 MySQL 会升级为表锁，比如需要扫描全表才能执行 UPDATE 时。

意向锁比较抽象。它的作用是快速判断表里是否有行被锁住。事务要给某行加锁前，必须先给表加意向锁。这就避免了另一个事务加表锁时，需要逐行扫描看是否有行锁冲突。意向锁之间是兼容的，意向锁与表级排他锁冲突。

5.2 记录锁、间隙锁、临键锁

这部分是 InnoDB 锁的核心细节，也是一个比较难讲清楚的知识点。三类行锁对应的场景不同。

记录锁（Record Lock）：锁定的是索引记录本身。SELECT * FROM t WHERE id = 1 FOR UPDATE会对 id=1 的记录加锁，其他事务要修改这一行必须等待。

间隙锁（Gap Lock）：锁定的是索引记录之间的间隙，用于防止其他事务在间隙中插入新记录，从而解决幻读问题。比如索引里有 1、3、5 三行，间隙锁可能锁住 (1,3) 这个区间，其他事务不能插入 id=2 的记录。

临键锁（Next-Key Lock）：是记录锁和间隙锁的组合，锁定的范围包括当前记录以及其前面的间隙。例如 (1,3] 表示锁住 3 这条记录以及 (1,3) 的间隙。InnoDB 在可重复读级别下，默认使用临键锁来防止幻读。

面试官问死锁时，常用场景是两个事务互相持有对方需要的锁。比如事务 A 更新了 id=1 的行，事务 B 更新了 id=2 的行；然后 A 请求更新 id=2，B 请求更新 id=1，两个事务互相等待，死锁就出现了。回答时可以补充一句：InnoDB 有死锁检测机制，发现死锁后会回滚代价较小的事务，让另一个事务继续执行。

5.3 死锁排查思路

真实项目中，死锁不是像上面例子那样刚好反向更新两条记录，更多是因为范围锁、间隙锁叠加导致。排查死锁的第一步是查看死锁日志：

SHOW ENGINE INNODB STATUS;

执行后，重点看 LATEST DETECTED DEADLOCK 部分，里面会显示两个事务各持有什么锁、在等待什么锁。根据这几条信息，通常能定位到是哪两个事务发生了互相等待。

死锁的预防手段包括：所有事务按固定顺序访问资源、尽量缩短事务时间、合理设计索引避免扫描范围过大、用低隔离级别减少间隙锁。

6. MySQL 三大日志：redo log、undo log、binlog 的配合

日志是 MySQL 面试中偏难的一部分，因为涉及数据库底层工作机制。很多候选人能背出三个日志的名字，但说不清它们各自的职责和协作关系。

6.1 三者的核心职责

redo log 是重做日志，属于 InnoDB 存储引擎层。它的作用是保证事务的持久性。当你执行一条 UPDATE 时，InnoDB 不会立刻把数据页刷写到磁盘，因为磁盘随机写太慢。它会先把修改记录写到 redo log 中，这是顺序写，速度快得多。事务提交时，只要 redo log 刷到磁盘，事务就算持久化了，数据页可以以后慢慢刷。如果数据库在数据页刷盘前崩溃，重启后 InnoDB 会通过 redo log 重放操作，恢复数据。

undo log 是回滚日志，也属于 InnoDB 存储引擎层。它保存了事务修改前的数据版本，用于事务回滚和 MVCC 的多版本链。事务执行中需要回滚时，通过 undo log 把数据恢复到修改前状态。同时，MVCC 中提到的旧版本读取，就是通过 undo log 回溯历史版本实现的。

binlog 是二进制日志，属于 MySQL Server 层，记录的是数据的逻辑变更，比如「id=1 的行的 age 从 20 改成 30」。binlog 的主要用途有三个：主从复制、数据恢复、审计。主从架构中，从库通过拉取主库的 binlog 并在本地重放，实现与主库数据一致。

6.2 为什么需要两阶段提交

redo log 和 binlog 是两个独立的日志系统，分别记录在当前事务里。问题来了：如果 redo log 写了但 binlog 没写，或者反过来，主库和从库的数据就会不一致。

举一个例子：事务执行到一半，redo log 写入成功并提交，但 binlog 还没来得及写，数据库在此时崩溃。重启后，主库通过 redo log 恢复了更新，但从库没有收到 binlog，就没有更新。主从数据不一致。

为了解决这个问题，InnoDB 引入了两阶段提交：事务在提交时，先写 redo log，进入 prepare 状态；然后写 binlog；最后把 redo log 改为 commit 状态。如果在 prepare 阶段后、binlog 写入前崩溃，重启后发现 redo log 是 prepare 但 binlog 未写，就会回滚事务；如果 binlog 已写、准备提交 redo log 前崩溃，重启后会继续提交事务。通过这个机制，redo log 和 binlog 的状态始终一致。

这部分如果能主动写出「XID 被写入 binlog，用于 redo log 和 binlog 的关联」，面试官对你的底层理解会非常认可。

7. SQL 优化与慢查询排查：从 explain 到索引失效

SQL 优化是 Java 面试中「实战感」最强的模块。面试官会给你一条慢查询日志，或者直接问：「线上有个 SQL 跑了 5 秒，你怎么排查？」

7.1 开启慢查询日志

首先要能说出慢查询日志怎么配置。MySQL 提供了两个关键参数和一条常用命令：

-- 查看是否开启慢查询及阈值 SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'long_query_time'; -- 开启慢查询（当前会话/实例生效） SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;

需要说明的是，long_query_time的单位是秒，设为 1 意味着执行时间超过 1 秒的 SQL 会被记录到慢查询日志中。生产环境建议设为 1 或更低，具体根据业务情况调整。

7.2 用 explain 分析执行计划

拿到慢查询 SQL 后，第一步不是猜，而是看执行计划。explain 是 MySQL 用来展示 SQL 执行计划的关键字：

EXPLAIN SELECT u.id, u.name, o.order_no FROM user u LEFT JOIN orders o ON u.id = o.user_id WHERE u.status = 1 ORDER BY u.create_time DESC;

执行后，重点看这几个字段：

常见的优化动作包括：为 WHERE 条件列建立索引、为 ORDER BY 列建立索引避免 filesort、把 SELECT * 改成只查需要的列、拆分复杂 join 为多次简单查询。

7.3 经典索引失效 SQL 示例

下面这条 SQL 是在真实项目中非常容易出现的问题类型：

-- 错误示例：对索引列使用函数，导致索引失效 SELECT * FROM orders WHERE DATE(create_time) = '2026-08-01'; -- 正确示例：改成范围查询，走索引 SELECT * FROM orders WHERE create_time >= '2026-08-01 00:00:00' AND create_time < '2026-08-02 00:00:00';

另外一个高频优化点是在深分页场景：

-- 错误示例：深分页扫描大量数据 SELECT * FROM orders ORDER BY id LIMIT 100000, 20; -- 优化示例：先通过覆盖索引拿到起始 id，再回表查完整数据 SELECT * FROM orders WHERE id > (SELECT id FROM orders ORDER BY id LIMIT 100000, 1) ORDER BY id LIMIT 20;

面试时能给出这两类案例，比单纯说「加索引」「避免 SELECT *」要有说服力得多。

8. 主从复制与高可用：binlog 到中继日志的传递链路

主从复制是分布式系统面试中和 MySQL 关联最深的一块。Java 开发者虽然不一定要部署 MySQL 主从，但必须理解读写分离的原理和常见问题。

8.1 主从复制原理

MySQL 主从复制的过程分为三个步骤：

1. 主库把数据变更记录写入 binlog。
2. 从库的 I/O 线程连接主库，请求指定位置的 binlog，并把收到的内容写入从库的中继日志（relay log）。
3. 从库的 SQL 线程读取中继日志，在本地重放日志事件，更新到自身的数据库中。

这里有一个细节需要区分：从库有一个 I/O 线程负责拉取 binlog，有一个 SQL 线程负责执行中继日志。两个线程是异步的，所以从库数据通常比主库有延迟，这就是主从延迟问题的根源。

8.2 binlog 的三种格式

面试官问 binlog 格式，是想考察你是否清楚主从复制在不同格式下的行为差异。

• Statement：记录的是 SQL 语句本身。优点是日志量小；缺点是非确定性函数如 NOW()、UUID() 在主从两端执行结果可能不同，导致数据不一致。
• Row：记录的是每行数据的具体变更内容。优点是最精确，不受函数影响；缺点是日志量大。
• Mixed：MySQL 自动判断，在可能产生不一致时使用 Row，否则使用 Statement。

从实践角度看，目前主流推荐使用 Row 格式，尤其是要求数据强一致的业务场景。

8.3 主从延迟的常见原因和应对

主从延迟的常见原因有：从库硬件性能不如主库、从库同时承担了多份复制任务、主库大事务导致 binlog 积压、从库上执行了耗时的查询或备份任务。

应对手段包括：提升从库配置、缩短主库大事务、拆分为多个从库分摊读取压力、监控 Seconds_Behind_Master 指标。对于必须实时读到最新数据的业务，可以在中间件层面做强制走主库的策略。

9. 容易被细问的细节题：int(5)、utf8mb4、连接数

这类题目不一定每家都问，但面试官如果提到，通常是在传「你到底是真用过，还是只会背概念」的信号。

9.1 int(5) 到底是什么意思

这是一个非常经典的前后端协作误解。int(5)不是指「这个整数最多只能存 5 位数」。int 类型在 MySQL 中永远占 4 个字节，能存储的范围是 -2147483648 到 2147483647，约 21 亿。

int(5) 中的 5 指的是显示宽度，并且只在搭配ZEROFILL时有效。比如INT(5) ZEROFILL，存的值为 42，查询时会显示 00042。如果没有 ZEROFILL，int(5) 和 int(11) 在存储上没有区别。

9.2 utf8 和 utf8mb4 的区别

MySQL 的 utf8 字符集不是真正的四字节 UTF-8，它最多只支持 3 个字节，无法存储 emoji 表情和一些生僻汉字。如果业务需要存 emoji 或四字节字符，必须使用 utf8mb4，并在连接层也指定对应的字符集。

MySQL 8.0 的默认字符集已经是 utf8mb4，这是一个很大的改进。如果你还在用 MySQL 5.7，建议在建库时显式指定：

CREATE DATABASE demo_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

9.3 max_connections 和连接数问题

Java 项目使用连接池连接 MySQL，默认连接池大小可能在 10 到 50 之间。但如果存在连接泄漏，连接池会不断申请新连接，最终把数据库的连接数打满，报Too many connections错误。排查思路是：先看 MySQL 当前连接数和状态：

SHOW STATUS LIKE 'Threads_connected'; SHOW GLOBAL VARIABLES LIKE 'max_connections';

查完之后定位到具体业务应用，检查连接池是否有正确的归还连接逻辑、连接空闲超时配置是否合理。同时，一个数据库实例的连接数不是越大越好，每个连接都会消耗线程和内存，过大的连接数反而会拖垮数据库。

10. Java 面试 MySQL 的 3 天复习路线

现在回到文章开头的问题：3 天时间，怎么最高效地把 MySQL 面试准备到位？

我不建议你按网上的长题库逐题刷，而是按知识模块做「原理 + 练习 + 自测」的循环。下面是一套可执行的分配方案。

Day 1：存储引擎 + 索引

上午把 InnoDB 和 MyISAM 的区别讲清楚，重点理解「为什么 InnoDB 用 B+ 树」和「聚簇索引与回表」。下午做索引实战：建一张测试表，模拟插入 10 万条数据，分别用无索引、单列索引、联合索引执行查询，再用 explain 看执行计划的差异。

自测题：

• InnoDB 为什么用 B+ 树而不用 B 树？
• 联合索引 (a, b, c)，WHERE b = 1能不能走索引？
• 什么是回表？覆盖索引为什么能提升查询性能？
• LIKE '%张' 为什么会导致索引失效？

Day 2：事务 + 锁 + 日志

上午整理 ACID、隔离级别、MVCC 的执行流程，画出事务读取数据时 Read View 的判断过程。下午研究锁机制，重点搞清楚记录锁、间隙锁、临键锁的区别。晚上用 1 小时复习 redo log、undo log、binlog 的职责和两阶段提交。

自测题：

• MySQL 默认隔离级别是什么？它是怎么避免幻读的？
• MVCC 在可重复读级别的实现和读已提交有什么区别？
• Redo log 和 binlog 为什么需要两阶段提交？
• 两个事务互相更新不同行，为什么会死锁？

Day 3：SQL 优化 + 主从复制 + 综合模拟

上午练习慢查询排查流程：开启慢查询日志、造一条慢 SQL、解释执行计划、给出优化方案。下午复习主从复制原理、binlog 格式、主从延迟原因。晚上挑 20 道高频 MySQL 面试题，不看答案，口述回答并录音，检查自己能不能把关键逻辑说完整。

自测题：

• 线上一条 SQL 执行了 2 秒，你怎么定位和优化？
• SHOW ENGINE INNODB STATUS 里怎么找死锁信息？
• 主从延迟的根本原因是什么？业务上如何应对？
• 你遇到过 Too many connections 吗？怎么排查？

这套复习路线有一个特点：始终把「为什么」放在「怎么回答」前面。你可以在此基础上结合自己的项目经验做补充。比如你处理过一个慢 SQL，就在 Day 3 的模拟面试里把它讲出来；你在项目里做过读写分离，就把主从复制部分讲成自己的实践案例。

11. 最后给 Java 面试者的几点提醒

MySQL 面试题再多，也逃不出存储引擎、索引、事务、锁、日志、优化、复制这几个核心模块。真正拉开差距的，从来不在于你背了多少道题，而在于你能不能把概念串成一条逻辑链，并且用真实场景去解释它们。

面试官问索引，你不要只回答 B+ 树，而是可以从全表扫描的代价讲到 B+ 树的层数，再讲到聚簇索引和回表，最后用 explain 举例。面试官问事务隔离级别，你不要只背四种隔离级别，而是可以指出 MySQL 默认是可重复读，并解释 InnoDB 如何通过 MVCC 和间隙锁解决幻读。这种回答方式会让你的知识体系显得非常完整。

准备面试的过程中，有一个容易被忽视的点：不要脱离 MySQL 实际运行环境去背概念。建议你在自己电脑上装一个 MySQL，用几万条测试数据跟着这篇文章的示例跑一遍。亲自看一次创建索引前后执行计划的变化，效果比刷 50 道题都管用。

另外，面试中如果被问到不熟悉的问题，不要慌张。面试官更看重的是你能否用已有知识去推理。比如你忘了间隙锁的定义，你可以从「可重复读级别要解决幻读」出发，推出 InnoDB 需要一个能阻止其他事务插入数据的锁机制，自然就能说出间隙锁。答错的成本很低，冷场硬编的成本很高。

把 MySQL 拿下，Java 面试的后端基础环节就稳了一大半。建议把本文收藏起来，按照 3 天复习路线逐段消化。面试当天，把索引、事务、锁、日志这几个核心模块的重点，在脑子里过一遍，祝你少走弯路，顺利拿到满意的 Offer。