在Java后端面试中，MySQL是“绕不开的硬骨头”——尤其是事务隔离级别和索引优化，几乎每家公司（理想汽车、神策、微盟、得物）都会追问。很多人要么记混隔离级别的作用，要么讲不清“为什么用B+树做索引”，今天就拆解这两大高频考点，附带“避坑指南”，帮你3分钟记牢核心要点，面试不慌。

第一题：MySQL事务隔离级别有哪些？默认级别解决了什么问题？

这道题是“基础中的基础”，但90%的人只会背四个级别，说不出“MySQL默认级别特殊在哪”，更讲不清“可重复读怎么实现的”。

先搞懂：4个隔离级别+核心作用（表格记，面试直接答）

隔离级别

核心规则

解决的问题

未解决的问题（默认InnoDB除外）

读未提交（RU）

能读其他事务未提交的数据

无

脏读、不可重复读、幻读

读提交（RC）

只能读其他事务已提交的数据

脏读

不可重复读、幻读

可重复读（RR）

同一事务内多次读同一数据结果一致

脏读、不可重复读

传统幻读（InnoDB已解决）

串行化（Serializable）

事务串行执行，加表锁

所有问题

并发性能极差

关键补充：MySQL默认级别（RR）的“特殊之处”默认是RR，不是RC：很多人记成“读提交”，其实MySQL InnoDB默认是可重复读；RR解决了幻读：传统RR无法避免幻读（同一事务查两次，其他事务插数据导致条数变），但InnoDB用Next-Key Locking（间隙锁+行锁） 解决了——比如查id>5的行，会锁定5到下一个存在id的间隙（如5-10），防止其他事务插id=6的数据；RR靠MVCC实现：不用加表锁就能保证可重复读，核心是3个组件：隐藏列：每行有DB_TRX_ID（最后修改事务ID）、DB_ROLL_PTR（指向Undo Log）；Undo Log：保存数据旧版本，形成版本链；Read View：事务启动时生成，决定能读哪个版本的数据（避免读未提交的新数据）。踩坑点提醒（90%人会错）

❌ 错误回答：“RR解决不了幻读”——只知理论不知InnoDB特性！实际InnoDB用Next-Key Locking避免了幻读，必须提；

❌ 漏答MVCC：只说“RR是默认级别”，不讲怎么实现的，会让面试官觉得你只背概念；

❌ 混淆RC和RR：把“读提交解决不可重复读”说成RR的作用，记准“RC解决脏读，RR解决不可重复读”。

第二题：为什么MySQL用B+树做索引？联合索引的“最左匹配”怎么用？

这道题考“索引底层逻辑”，很多人只会说“B+树层数少”，却讲不清“为什么比B树好”，也记不准最左匹配的细节。

正确解答1：B+树比B树好在哪？（记3个核心优势）

对比维度

B树（Balance Tree）

B+树（Balance Plus Tree）

数据存储位置

索引节点+叶子节点都存数据

只在叶子节点存数据，索引节点只存索引

叶子节点关联

无（离散）

双向链表（支持范围查询）

查数据效率

可能在非叶子节点找到，也可能在叶子

必须到叶子节点（效率稳定）

适用场景

内存数据库（如Redis sorted set）

磁盘数据库（MySQL索引）

MySQL选B+树的核心原因（面试必答2点）：

减少磁盘IO：B+树索引节点不存数据，能存更多索引（扇出大），树高更低（一般3-4层），查一次数据只需3-4次IO（磁盘IO是MySQL性能瓶颈）；范围查询快：叶子节点是双向链表，查“id>10 and id<20”时，找到10后直接遍历链表，不用回溯父节点（B树要整棵树遍历）。正确解答2：最左匹配原则

联合索引（如idx_userId_orderTime）的匹配规则：从左到右，一旦遇到“范围查询（>、<、between）”或“不匹配”，后续字段无法使用索引。

能命中索引的情况：where userId=100（用左1字段）；where userId=100 and orderTime='2024-05-01'（用左1+左2字段）；不能命中索引的情况：where orderTime='2024-05-01'（跳过左1字段，索引失效）；where userId>100 and orderTime='2024-05-01'（userId是范围查询，orderTime无法用索引）。

关键技巧：创建联合索引时，把“过滤性强、无范围查询”的字段放左边（如userId过滤性比orderTime强，放左边）。

踩坑点提醒

❌ 说“B+树比B树快是因为层数少”——不完整！必须提“范围查询快”和“IO次数少”，这才是MySQL选它的核心；

❌ 最左匹配漏答“范围查询中断”：比如以为userId>100 and orderTime=...能用到orderTime索引，实际不行；

❌ 联合索引顺序乱设：把“范围查询字段”放左边（如idx_orderTime_userId），导致userId无法用索引，这是生产常见错误。

第三题：高频追问：select for update锁null时，会发生什么？（神策一面/得物必问）

这道题是“区分懂锁机制和不懂”的关键——很多人以为“没匹配到数据就不锁”，其实大错特错。

正确解答：分2种情况（看是否匹配到数据+有无主键）情况1：没匹配到数据（如select * from goods where id=999 for update，id=999不存在）InnoDB会加间隙锁（Gap Lock）：锁定“不存在数据的间隙”（比如id=999在id=998和1000之间，就锁定998-1000的间隙）；作用：防止其他事务插入id=999的数据（避免幻读），这是RR级别下InnoDB的默认锁策略。情况2：表没主键/唯一索引（如select * from goods where name='不存在' for update）间隙锁会“扩大范围”，甚至退化成表锁：因为没有主键/唯一索引，InnoDB无法定位具体间隙，只能锁定整个表；后果：其他事务对该表的所有操作都会被阻塞，严重影响并发。踩坑点提醒

❌ 错误回答：“没匹配到数据就不锁”——完全错！InnoDB为了防幻读，没匹配到也加间隙锁；

❌ 漏答“无主键的情况”：只说间隙锁，不提“退化成表锁”，会暴露你没踩过生产锁阻塞的坑；

❌ 混淆行锁和间隙锁：以为for update只加行锁，其实在RR级别下，没匹配数据时加的是间隙锁，这点必须明确。

互动话题

你面试被问过MySQL锁问题吗？有没有遇到过“锁表导致线上故障”的情况？评论区留个言，我会选1位同学，免费帮你分析MySQL索引设计或锁机制的问题~

#Java##面试##MySQL#