每年到 8 月准备 Java 面试的人就会集中焦虑起来。尤其是 MySQL看起来会一点但真到面试现场从“事务隔离级别”到“索引为什么快”再到“慢 SQL 怎么排查”一问深就卡壳。这篇文章不打算给你贴一个几十题的题库而是按 3 天复习节奏把 MySQL 面试里最常考、最容易被连环追问的知识点拆成“高频问题 核心原理 回答思路 避坑点”。内容以 Java 后端面试最常见的考察维度为准适合准备秋招、跳槽、或者工作几年想系统补一遍 MySQL 的人。为什么 MySQL 值得单独花 3 天因为它在 Java 面试中几乎必考而且不只是背概念面试官很喜欢从一个点往下追问。你把事务、MVCC、索引、执行计划、日志、主从复制这些主线搞清楚比刷 200 道零散题更有用。1. 先搞清楚 MySQL 面试题到底在考什么很多人的复习方式是从网上找一份“MySQL 面试 300 题”然后一道一道背。这种方式的效率很低原因很简单面试题不是标准答案集合而是“高频问题清单”。它帮你划出考点范围但真正的竞争力在于理解背后的设计思路和实际应用场景。MySQL 相关面试题大致可以分成四层第一层能说出是什么。比如 BTree、事务隔离级别、索引类型、binlog 是什么。第二层能解释为什么。比如 InnoDB 为什么用 BTree可重复读为什么还需要间隙锁redo log 和 binlog 为什么需要两份。第三层能结合场景。比如一条 SQL 很慢怎么排查一张表数据量很大要不要分库分表分片键怎么选。第四层能体现工程经验。比如批量更新时怎么避免主从延迟死锁出现后怎么从业务代码层面解决。8 月这个时间点多数人是在准备秋招或暑期实习转正时间紧目标明确。我的建议是不要按顺序刷题库而是按“面试官最常追问的主线”去复习。MySQL 最容易形成连环追问的几块就是事务与 MVCC、索引与执行计划、SQL 优化、表结构与分库分表、日志体系、锁与死锁。这篇文章按 3 天来安排刚好覆盖这些主线。每天的内容都以“高频问题 关键原理 回答思路 避坑点”为结构你可以直接按这个节奏执行。2. 第 1 天先搞定事务、隔离级别和 MVCC第一天不要一上来就刷题先把 MySQL 里最容易翻车、又最容易被连环追问的“事务 MVCC 锁”这块稳住。MySQL 面试题里关于事务的提问非常多而且喜欢从一个大问题往下追。比如面试官先问“事务是什么”接着就会问“ACID 里哪个最难保证”“事务隔离级别有哪些”“默认隔离级别是什么”“可重复读为什么还会出现幻读”“MVCC 怎么实现的”“当前读和快照读有什么区别”。这一串如果只背概念很容易在某一个环节卡住。先理解几个最基本的概念。事务是数据库操作的最小执行单元要么全部成功要么全部回滚。ACID 中A 是原子性C 是一致性I 是隔离性D 是持久性。MySQL 里隔离性依赖锁和 MVCC持久性依赖 redo log原子性和一致性主要依赖 undo log。事务隔离级别按严格程度从低到高包括读未提交Read Uncommitted、读已提交Read Committed、可重复读Repeatable Read、串行化Serializable。MySQL InnoDB 默认是可重复读。这是很常见的考点但更常考的是“为什么默认是可重复读”。这时候不要只说“因为官方默认”而是要说MySQL 在早期基于日志复制体系里可重复读配合 binlog 在 statement 格式下更容易保证主从一致。同时 InnoDB 通过 MVCC 和临键锁Next-Key Lock可以在可重复读级别下大幅抑制幻读。虽然后续版本主从复制也支持 row 格式但从历史原因和兼容性考虑默认级别没有改成读已提交。接着是 MVCC。MVCC 是 InnoDB 用来实现高并发读的一种机制核心思路是让普通查询不加锁通过多版本数据来保证不同事务看到的数据快照一致。它依赖几个关键设计每行记录中的隐藏事务 ID 字段、undo log 里的版本链以及 ReadView 可见性判断。面试官很喜欢问“可重复读和读已提交在 MVCC 上的区别”。回答要点是读已提交每次普通查询都生成新的 ReadView所以能读到其他事务已提交的数据可重复读只在第一次普通查询时生成 ReadView后面复用同一份可见性判断所以同一事务内多次查到的结果保持一致。还要知道“当前读”和“快照读”的区别。普通 select 是快照读不加锁。update、delete、insert以及 select ... for update、select ... lock in share mode 是当前读需要加锁。可重复读下幻读问题主要发生在当前读场景InnoDB 用间隙锁Gap Lock和临键锁Next-Key Lock来处理。第一天建议这样安排上午把 ACID、事务隔离级别、默认级别、redo log、undo log、binlog 的概念全部理一遍画出三条日志分别做什么。下午把 MVCC 的隐藏字段、undo 版本链、ReadView 生成时机、快照读和当前读的差异写清楚。晚上找 10 道事务和隔离级别相关面试题不给看答案自己先口头回答再对答案。这里要提醒一个很典型的误区很多人把“可重复读”理解成“永远不会出现幻读”。实际上可重复读只保证快照读的结果一致当前读场景下如果锁范围没有覆盖到新增数据或者没有正确使用间隙锁依然可能出现幻读。面试时如果能主动提到这一层会明显比背概念更有优势。3. 第 2 天索引、执行计划与慢 SQL 优化第二天的重点是索引因为索引是 MySQL 面试题里出现频率最高的一类而且和实际开发结合最紧密。高频问题包括索引有哪些类型BTree 和 BTree 有什么区别为什么用 BTree 不用二叉树或哈希索引聚簇索引和非聚簇索引的区别什么是回表什么是覆盖索引什么情况下索引会失效联合索引最左前缀原则怎么理解explain 里的 type、key、rows、Extra 分别怎么判断。先回答最常见的“为什么 InnoDB 用 BTree”。BTree 的数据都存放在叶子节点并且叶子节点之间通过指针串联适合范围查询和顺序扫描。非叶子节点只存索引键和指针单页能存更多索引项树更矮磁盘 IO 更少。相比哈希索引BTree 支持范围查询、排序、前缀匹配。相比 BTreeBTree 的叶子节点更紧凑遍历更方便层高更稳定。如果只背到这里可能还不够。面试官很可能会继续问“那聚簇索引呢”。InnoDB 的数据文件本身就是按主键索引组织的主键索引的叶子节点存放整行数据所以主键索引就是聚簇索引。非主键索引的叶子节点存放主键值所以根据非主键索引查询时如果查询列不在索引里就要再回表到主键索引里拿整行数据。这里最值得掌握的是“覆盖索引”。如果查询只需要索引里包含的列就不需要回表可以减少 IO。面试和实际优化中覆盖索引都是非常重要的优化手段。比如select id, name from user where name 张三如果 name 上有索引而 id 在叶子节点里也有查询就不需要回表。索引失效问题也是高频。常见场景包括对索引列使用函数或计算比如where YEAR(create_time) 2026。隐式类型转换比如字符串索引列用数字比较。模糊匹配用了前导通配符比如like %abc。联合索引没有按最左前缀使用。使用or且其中一个条件没有索引。优化器判断全表扫描比索引扫描更优时也会放弃索引。注意索引失效不是所有情况都绝对。比如like abc%是可以走索引的。or如果两侧字段都有索引优化器也可能走索引。回答这类问题时不要说“一定失效”更稳的说法是“在优化器选择时可能不选索引需要结合 explain 和实际数据量判断”。联合索引最左前缀原则也要讲清楚。联合索引(a, b, c)相当于建立了a、ab、abc几套索引。查询条件包含a时能命中只有在包含a的前提下才能继续匹配b再继续匹配c。如果跳过b直接查a和c那么a能走索引c只能在索引筛选后做进一步过滤不能完整使用索引。执行计划同样不能跳过。explain 输出里的几个重点type从好到差大致是 system、const、eq_ref、ref、range、index、ALL。ALL 通常意味着全表扫描。key实际使用的索引。rows估算要扫描的行数值越大风险越高。Extra出现 Using filesort、Using temporary 时要重点优化Using index 说明使用了覆盖索引是加分项。慢 SQL 优化的排查顺序我一般是这样先拿到慢查询日志确认 SQL 是哪些。看 SQL 的 where、order by、group by、join 条件涉及哪些列。对这些列检查索引是否存在。explain 看执行计划重点看 type、rows、Extra。如果索引存在但没走先排查索引失效原因。如果是统计信息不准或数据量太大可能要考虑重新分析表或调整 SQL。如果单条 SQL 已经优化到极限再考虑表结构、缓存、读写分离、分库分表。慢 SQL 优化最忌讳一上来就加索引。加索引不是万能的写多读少的表、频繁更新的列、低选择性的列加索引反而会拖慢写入和维护成本。实际项目中应该先通过 explain 确认是全表扫描、回表太多、排序临时表、还是数据规模本身的问题。第二天复习安排上午梳理索引类型、BTree 原理、聚簇索引、回表、覆盖索引、最左前缀。下午找 5 条不同类型 SQL自己写 explain 分析然后再看实际面试题里给出的执行计划。晚上整理一份“索引失效自查清单”并准备一个慢 SQL 优化案例从现象到 explain 到改动到效果逐步说清。这里多说一句实际面试时能把 explain 输出读明白的人已经超过很多人了。大部分候选人能说出 BTree 概念但一看到具体执行计划就说不清楚所以要单独练。4. 第 3 天SQL 写法、表结构、分库分表与大数据量方案第三天不要再看散题而是把重点放在“实际业务里怎么设计表、怎么写 SQL、数据大了怎么办”。8 月面试题里SQL 语句类、表设计类、分库分表类问题数量非常多而且很多是在项目经验考察阶段被问到的。先说说 SQL 写法。高频基础点包括delete、truncate、drop 的区别where 和 having 的区别group by 聚合时注意什么order by 排序的走索引问题limit 深分页为什么慢join 和子查询怎么选union 和 union all 的区别count(*)、count(1)、count(列名) 有区别吗。delete、truncate、drop 是很容易被连环问的一组概念。delete 是 DML逐行删除可以通过事务回滚不释放表空间truncate 是 DDL清空整表速度快不能按条件删除不能回滚会释放表空间drop 是 DDL直接删除表结构和数据。面试时可以顺带提一句生产环境删除大表数据尽量不要一次 delete 全量要分批删除否则会产生大量 binlog、锁竞争和主从延迟。where 和 having 的区别经常被搞混。where 在分组前过滤having 在分组后过滤where 不能使用聚合函数having 可以使用聚合函数。实际项目中能用 where 过滤就尽量用 where因为提前过滤可以减少分组数据量效率更高。count 系列也是高频。count(*) 和 count(1) 在 InnoDB 里基本可以认为没有实质区别都是统计符合条件的结果行数。count(列名) 会跳过该列为 null 的记录所以如果某列有 nullcount(列名) 可能和其他两个结果不同。如果只是想知道表总行数且不要求实时精确可以看show table status里的 rows但它是估算值。join 相关的问题要注意。实际项目中如果一个小表和一个大表做 join优化器通常会把小表作为驱动表。但真实场景还要看索引和连接字段。面试中常问“left join 和 inner join 有什么区别”“如果 join 很慢怎么办”回答时先确认是否有索引、是否大表之间 join、是否产生了临时表、连接字段类型是否一致。再看表结构。高频问题有char 和 varchar 怎么选int(11) 里的 11 是什么意思decimal 和 float 有什么区别text 字段能直接建索引吗时间字段用 datetime 还是 timestamp为什么要设置自增主键唯一索引和普通索引怎么选逻辑删除和物理删除怎么选。int(11) 是很容易踩坑的题。int(11) 中的 11 表示显示宽度不是存储长度。int 占用 4 字节能存储的范围固定显示宽度只影响在 zerofill 时的显示格式。MySQL 8.0 对显示宽度也有调整所以不要再说 int(11) 表示最多存储 11 位数字。char 和 varchar 的选择要考虑存储和可变长度。char 定长适合长度固定的场景比如手机号、订单号但也要注意字符集和字节占用。varchar 变长适合长度经常变化的场景使用时要设置合理长度不要一上来就 varchar(1000) 或 text避免行溢出和索引不能完整覆盖。decimal 用于精确小数比如金额float 和 double 是浮点数会有精度损失。面试题里出现过“金额字段为什么不用 float”这类问题回答时先说明二进制无法精确表示所有十进制小数再说明 decimal 是定点数能保证精度。这里还可以补充一句实际业务中金额计算也可以考虑使用整数分存储很多金融场景就是这么做的。时间字段的坑也比较多。datetime 和 timestamp 的区别包括占用空间、时区支持、可表示范围。timestamp 受时区影响范围到 2038 年datetime 不随系统时区变化范围更大。存储日志、创建时间、更新时间时建议统一使用 datetime 或 bigint 存毫秒时间戳但要看团队约定和查询需求。这里没有唯一标准关键是前后一致。分库分表和大数据量方案是这个阶段最有含金量的部分。面试官常问什么情况下需要分库分表分库分表有哪几种方式水平拆分和垂直拆分有什么区别分片键怎么选全局唯一 ID 怎么生成扩容和迁移怎么做分页查询怎么处理跨节点 join 怎么处理事务怎么保证。回答分库分表之前先把前提说清楚不要一上来就分库分表。一般先做 SQL 优化、加索引、开启缓存、做读写分离数据量达到一定程度单表写入或查询明显变慢后再考虑分库分表。分库分表会增加复杂度涉及分布式事务、全局 ID、跨库查询、数据迁移、扩容成本很高。水平拆分和垂直拆分是重点。垂直拆分是把不同业务字段拆到不同表或不同数据库比如把用户基本信息、用户订单信息分开水平拆分是把同一张表的数据按规则分布到多个表或多个库比如按用户 ID 取模、按时间分表。分片键的选择是水平拆分的关键。常见的策略有按主键 hash 取模、按范围分片、按业务键分片。选分片键时要注意业务查询要尽量带分片键否则会变成全库扫描。比如订单表按用户 ID 分片那查询单个用户的订单可以直接定位如果按订单做全局查询就需要遍历所有分片复杂度会很高。全局唯一 ID 生成方案也是面试热点。常见有使用 UUID、数据库自增 ID、Redis incr、雪花算法Snowflake等。雪花算法生成的是 64 位 long 型 ID包含时间戳、机器 ID、序列号具备趋势递增和全局唯一的特点。需要注意如果系统时钟回拨可能会出现重复 ID所以实现时要对时钟回拨做处理。事务问题在分库分表后尤其难。原来单库本地事务可以保证 ACID分库后跨库事务就不能靠普通本地事务解决了。常见方案包括分布式事务、事务消息、本地消息表、最大努力通知等。面试时不用把每一种都背得很深但至少要知道大致思路和适用场景。大数据量场景下的分页和排序也是常见问题。limit 900000, 10这种深分页很慢因为数据库需要扫描前面 90 万行后再丢弃。优化思路包括使用主键或唯一索引做游标分页比如where id 上一页最大 id limit 10或者先查到符合条件的 ID 列表再关联回原表获取完整数据。第三天复习安排上午过一遍 SQL 语法差异、常用聚合函数、join 写法、limit 深分页、count 系列问题。下午整理表结构设计原则把 char、varchar、decimal、int、datetime 这些字段类型高频题全部口头回答一遍。晚上重点准备分库分表面试题包括水平拆分、垂直拆分、分片键、全局 ID、分布式事务、跨库分页。5. 日志体系redo log、undo log、binlog 与主从一致性MySQL 面试题里日志体系是一个容易拉开差距的模块。很多候选人会背“redo log 是崩溃恢复用的binlog 是归档用的”但被追问“为什么需要两份日志”“两阶段提交解决了什么问题”时就开始含糊。先把三个日志分别说清楚。redo log 是 InnoDB 的物理日志记录的是“对数据页做了哪些修改”主要用于崩溃恢复。MySQL 在更新数据时不会每次提交都直接刷新数据页到磁盘而是先写 redo log这样即使数据库崩溃也可以通过 redo log 重放恢复数据从而保证持久性。undo log 是 InnoDB 的逻辑日志主要用于事务回滚和 MVCC。修改数据前会把旧值记录到 undo log事务回滚时可以通过 undo log 恢复旧数据MVCC 的多版本链也依赖 undo log 中的版本记录。binlog 是 MySQL Server 层的归档日志记录的是逻辑变更主要用于主从复制、数据恢复和审计。binlog 有 statement、row、mixed 三种格式。row 格式记录的是行变更前后内容更安全statement 格式记录的是 SQL 原文日志量小但可能因为函数、时间函数等导致主从不一致mixed 是混合格式。现在高可用和数据一致性要求高的场景普遍推荐使用 row 格式。redo log 和 binlog 是两份不同的日志一个在存储引擎层一个在 Server 层。两个日志写入时机不同如果没有机制保证一致性就会出现“binlog 里有记录但 redo log 没有”或反过来导致主从数据不一致。所以 InnoDB 在提交事务时采用两阶段提交先写 redo log 并标记 prepare再写 binlog最后把 redo log 标记为 commit。这样无论哪个环节崩溃都能通过对比两个日志的状态来恢复或回滚保证数据一致性。面试中如果被问到“主从复制延迟数据不一致怎么办”可以这样回答先确认是延迟还是不一致。延迟可以通过show slave status查看 Seconds_Behind_Master或对比主从 binlog pos。主从延迟常见原因包括从库硬件性能低于主库、大事务执行时间长、主库写入并发高、从库回放配置不足。优化思路包括避免长时间大事务、控制批量更新和删除的行数、优化慢 SQL、提高从库配置、开启并行复制、读写分离时路由策略留出延迟容忍度。如果出现数据不一致可以借助校验工具对比数据再核对 binlog 位置定位差异范围。日志这块面试官还喜欢问“一个 update 语句从执行到提交MySQL 大概经历了什么”。回答流程大致是客户端发送 update 到 MySQL Server。分析器做语法解析优化器生成执行计划。执行器调用 InnoDB 接口执行更新。要更新的数据页如果在 Buffer Pool 里就直接用不在就先从磁盘读入 Buffer Pool。记录 undo log用于回滚和 MVCC。更新 Buffer Pool 中的数据页。写入 redo log buffer事务提交时按配置刷新到 redo log。写入 binlog。两阶段提交完成。等待客户端确认。不用把每一步背得一字不差但要知道大致顺序尤其要能说清 undo log、redo log、binlog 分别在哪个阶段起作用。这里补一句经验如果面试官问的是“为什么要写 redo log 而不是直接刷数据页”可以从顺序写和随机写角度回答。redo log 是顺序追加写入比随机刷数据页开销小、性能高同时又能保证持久性。这个点在真实工作里也很有用批量更新数据时磁盘 IO 和提交频率的设计都会涉及这个底层原理。主从复制部分还需要知道复制的基本流程主库把变更写入 binlog从库的 IO 线程拉取 binlog 并写入 relay logSQL 线程读取 relay log 并回放。从库可能出现延迟因为回放是重放主库写过的 SQL 或行变更如果主库压力高、事务大、从库性能差延迟就会放大。面试时如果能主动说一句“row 格式下产生的大事务在从库回放时也会造成延迟所以批量更新要分批”会显得有实际项目经验而不是只背概念。6. 锁、死锁与一致性读的高频追问锁这块在 MySQL 面试题里往往不会单独一次性考完而是穿插在事务和索引问题里。常见问题有表锁和行锁有什么区别InnoDB 的行锁是怎么实现的共享锁和排他锁有什么区别间隙锁和临键锁是什么什么时候会加表锁什么是死锁怎么排查和避免。InnoDB 的行锁不是直接锁“行记录”那么抽象而是基于索引来实现的。如果更新语句没有使用索引InnoDB 可能会通过全表扫描来加锁实际上锁的范围会扩大严重时表现为“行锁变表锁”。这是面试高频误区实际开发中也经常踩。共享锁S 锁和排他锁X 锁共享锁之间兼容因为都只是读共享锁和排他锁互斥排他锁之间互斥。select ... for update加的是排他锁select ... lock in share mode加的是共享锁。普通 select 不加锁走 MVCC 快照读。间隙锁是锁一个范围而不是某条具体记录主要用来防止在可重复读级别下出现幻读。比如where id between 10 and 20的当前读如果范围内没有全部被记录命中InnoDB 可能对不存在的间隙加锁阻止其他事务插入符合条件的新记录。临键锁是记录锁和间隙锁的组合锁住左开右闭区间。死锁是面试官比较喜欢问的场景题。出现死锁的必要条件包括两个或多个事务持有对方需要的锁并且互相等待加上锁无法剥夺和循环等待就会形成死锁。InnoDB 会检测死锁并回滚其中一个事务所以直接报错一般是 1213 错误Deadlock found when trying to get lock。实际排查死锁时我会按这个顺序看报错信息确认是死锁还是锁等待超时。死锁是 1213锁等待超时是 1205。使用show engine innodb status查看最近一次死锁的详情看涉及哪些表、哪些索引、哪条 SQL。看事务的加锁顺序是不是多个事务按相反顺序更新了多张表或相同范围的数据。看是否因为无索引导致锁范围过大把行锁升级成大面积锁。调整业务代码让事务按固定顺序访问表和行缩小事务范围减少持锁时间。如果是批量更新考虑分批提交避免一个超长事务持有大量锁。出现死锁不一定是数据库配置问题很多时候是业务代码里的加锁顺序不统一。面试题如果问“怎么避免死锁”不要说“优化数据库参数”应该先说业务层面统一加锁顺序、减少事务执行时间、避免大事务、尽量避免在事务里做远程调用和外部 IO。数据库层面可以调整锁等待超时时间和隔离级别但根因通常还在业务逻辑和 SQL 写法上。MVCC 和锁之间的关系也是一个很好的回答切入点。普通查询走 MVCC不加锁适合读多写少当前读需要加锁适合需要严格一致性的场景。如果对同一行数据并发的 update 和 select普通 select 读到的快照可能是旧值这并不代表数据错了而是隔离级别的可见性规则决定的。所以面试时被问“为什么加了事务后别的事务读不到我修改的数据”这类问题本质上就是 MVCC 可见性和锁的效果。7. 常见面试题快答和避坑清单8 月面试准备时间紧很多人会直接去刷“MySQL 面试 200 题”但刷题时如果只记住答案不理解“为什么”面试现场换一种问法就答不上来。下面这些是高频题里最容易答错或者答得含糊的我把容易踩坑的地方标出来。第一组隔离级别和事务。问MySQL 默认事务隔离级别是什么答InnoDB 默认 Repeatable Read可重复读。面试时最好补一句可重复读通过 MVCC 和间隙锁来避免很多幻读场景但当前读下仍可能出现幻读需要临键锁和间隙锁配合。坑点不要把默认级别说成 Read Committed也不要只说“默认就是可重复读”没有解释。第二组索引和 BTree。问为什么 InnoDB 用 BTree 存储索引答BTree 叶子节点集中存放数据且叶子节点之间有链表连接范围查询和扫描效率高非叶子节点可以放更多键树更矮IO 更少。坑点不要只说“BTree 查询快”要结合磁盘 IO、范围查询、聚簇结构说。第三组索引失效。问哪些情况下索引会失效答函数操作、隐式类型转换、like 前导模糊匹配、联合索引不按最左前缀、or 中某个条件无索引、优化器选择全表扫描。坑点不要把所有情况说成“一定会失效”要强调优化器决策和实际数据。第四组count。问count(*) 和 count(1) 有区别吗答在 InnoDB 下基本无区别都是统计行数count(列) 会跳过 null。坑点不要听到一些旧文章就说 count(*) 比 count(1) 慢MySQL 5.7 和 8.0 主流实现已经不是这个结论。第五组limit 深分页。问limit 1000000, 10 为什么慢答需要扫描并丢弃前面 100 万行。优化方案是游标分页或基于主键定位。坑点不要只说“加索引就能优化”深分页即使有索引也要扫描大量记录重点是减少扫描范围。第六组char 和 varchar。问选择 char 还是 varchar答长度固定用 char长度变化大用 varchar。但要注意字符集和字节占用不要盲目使用超长 varchar。坑点不要认为 varchar 一定比 char 省空间varchar 本身有额外长度字节如果数据长度都很接近char 可能更合适。第七组分库分表。问什么时候需要分库分表答先排除 SQL 问题和索引问题再通过读写分离、缓存、归档等方式缓解当单表数据量极大写入和查询都出现明显瓶颈后再考虑水平或垂直拆分。坑点不要把分库分表当作银弹回答时先说代价和前提再讲方案。第八组日志和主从一致性。问binlog 和 redo log 有什么区别答binlog 是 Server 层逻辑日志用于复制和恢复redo log 是 InnoDB 物理日志用于崩溃恢复。提交事务时用两阶段提交保证两者一致。坑点不要混淆“主从复制”和“崩溃恢复”各自的日志来源。第九组死锁。问死锁怎么排查答先确认报错是 1213 还是 1205再通过show engine innodb status看锁等待和事务状态检查加锁顺序、事务大小、有无索引。坑点不要一上来就改数据库参数先看业务代码和 SQL 的执行计划。第十组慢查询。问线上一条 SQL 很慢怎么排查答先看慢查询日志explain 看执行计划再看索引、数据量、锁等待、主从延迟。逐步排除环境因素后再改 SQL 或表结构。坑点不要不看 explain 就开始加索引先确认瓶颈是查询路径还是锁或 IO。除了上面这些还有一个容易忽略的常识MySQL 8.0 和 5.7 在很多细节上有差异。比如 8.0 对窗口函数、CTE、默认字符集 utf8mb4 的支持都更完善8.0 还在优化器行为上做了调整。面试时如果项目还在用 5.7可以先说明自己项目里的版本再回答功能性问题这样更严谨。如果复习时间只有 3 天我不建议每天刷大量新题。正确做法是先建立知识框架再用题目自测最后针对答不上来的点回看原理和场景。刷题是为了检验漏洞不是为了背标准答案。最后再补充一份通用的 MySQL 面试准备清单适合贴在电脑前能画出事务隔离级别、MVCC、当前读和快照读的概念图。能画出 BTree 索引结构说清聚簇索引、辅助索引、回表、覆盖索引。能自己 explain 一条慢 SQL说出 type、key、rows、Extra 的含义和优化方向。能说清 redo log、undo log、binlog 各自的写入时机和用途。能说清一个 update 语句从请求到提交经过哪些核心环节。能说清主从复制的流程、延迟原因、常见处理方式。能说清死锁的成因、排查命令、业务层优化手段。能给出至少 3 个 SQL 优化案例从现象到方案到结果。能说清什么时候该分库分表分片键怎么选全局 ID 怎么生成。能说出 MySQL 8.0 与 5.7 在你项目里最明显的差异点。这十个点如果都能做到“能讲、能画、能写”而不是“听说过、看过”那 8 月面试里 MySQL 这一块的胜率会高很多。我个人的建议是第 1 天把事务和 MVCC 彻底搞懂第 2 天把索引和 explain 练熟第 3 天把 SQL、表结构、分库分表和日志串起来。三天时间足够让一个有一定基础的人把零散知识点变成可输出的体系。关键是每学一个点都要能用一句话给面试官讲清楚“它解决什么问题、为什么这样设计、实际使用中会踩什么坑”。MySQL 面试不是背答案比赛而是考察你能不能把数据库原理和平时的开发场景连接起来。抓住事务、索引、日志、锁、优化这五条主线8 月面试基本就不会慌。
MySQL面试3天冲刺：事务、索引、日志与优化全攻略
每年到 8 月准备 Java 面试的人就会集中焦虑起来。尤其是 MySQL看起来会一点但真到面试现场从“事务隔离级别”到“索引为什么快”再到“慢 SQL 怎么排查”一问深就卡壳。这篇文章不打算给你贴一个几十题的题库而是按 3 天复习节奏把 MySQL 面试里最常考、最容易被连环追问的知识点拆成“高频问题 核心原理 回答思路 避坑点”。内容以 Java 后端面试最常见的考察维度为准适合准备秋招、跳槽、或者工作几年想系统补一遍 MySQL 的人。为什么 MySQL 值得单独花 3 天因为它在 Java 面试中几乎必考而且不只是背概念面试官很喜欢从一个点往下追问。你把事务、MVCC、索引、执行计划、日志、主从复制这些主线搞清楚比刷 200 道零散题更有用。1. 先搞清楚 MySQL 面试题到底在考什么很多人的复习方式是从网上找一份“MySQL 面试 300 题”然后一道一道背。这种方式的效率很低原因很简单面试题不是标准答案集合而是“高频问题清单”。它帮你划出考点范围但真正的竞争力在于理解背后的设计思路和实际应用场景。MySQL 相关面试题大致可以分成四层第一层能说出是什么。比如 BTree、事务隔离级别、索引类型、binlog 是什么。第二层能解释为什么。比如 InnoDB 为什么用 BTree可重复读为什么还需要间隙锁redo log 和 binlog 为什么需要两份。第三层能结合场景。比如一条 SQL 很慢怎么排查一张表数据量很大要不要分库分表分片键怎么选。第四层能体现工程经验。比如批量更新时怎么避免主从延迟死锁出现后怎么从业务代码层面解决。8 月这个时间点多数人是在准备秋招或暑期实习转正时间紧目标明确。我的建议是不要按顺序刷题库而是按“面试官最常追问的主线”去复习。MySQL 最容易形成连环追问的几块就是事务与 MVCC、索引与执行计划、SQL 优化、表结构与分库分表、日志体系、锁与死锁。这篇文章按 3 天来安排刚好覆盖这些主线。每天的内容都以“高频问题 关键原理 回答思路 避坑点”为结构你可以直接按这个节奏执行。2. 第 1 天先搞定事务、隔离级别和 MVCC第一天不要一上来就刷题先把 MySQL 里最容易翻车、又最容易被连环追问的“事务 MVCC 锁”这块稳住。MySQL 面试题里关于事务的提问非常多而且喜欢从一个大问题往下追。比如面试官先问“事务是什么”接着就会问“ACID 里哪个最难保证”“事务隔离级别有哪些”“默认隔离级别是什么”“可重复读为什么还会出现幻读”“MVCC 怎么实现的”“当前读和快照读有什么区别”。这一串如果只背概念很容易在某一个环节卡住。先理解几个最基本的概念。事务是数据库操作的最小执行单元要么全部成功要么全部回滚。ACID 中A 是原子性C 是一致性I 是隔离性D 是持久性。MySQL 里隔离性依赖锁和 MVCC持久性依赖 redo log原子性和一致性主要依赖 undo log。事务隔离级别按严格程度从低到高包括读未提交Read Uncommitted、读已提交Read Committed、可重复读Repeatable Read、串行化Serializable。MySQL InnoDB 默认是可重复读。这是很常见的考点但更常考的是“为什么默认是可重复读”。这时候不要只说“因为官方默认”而是要说MySQL 在早期基于日志复制体系里可重复读配合 binlog 在 statement 格式下更容易保证主从一致。同时 InnoDB 通过 MVCC 和临键锁Next-Key Lock可以在可重复读级别下大幅抑制幻读。虽然后续版本主从复制也支持 row 格式但从历史原因和兼容性考虑默认级别没有改成读已提交。接着是 MVCC。MVCC 是 InnoDB 用来实现高并发读的一种机制核心思路是让普通查询不加锁通过多版本数据来保证不同事务看到的数据快照一致。它依赖几个关键设计每行记录中的隐藏事务 ID 字段、undo log 里的版本链以及 ReadView 可见性判断。面试官很喜欢问“可重复读和读已提交在 MVCC 上的区别”。回答要点是读已提交每次普通查询都生成新的 ReadView所以能读到其他事务已提交的数据可重复读只在第一次普通查询时生成 ReadView后面复用同一份可见性判断所以同一事务内多次查到的结果保持一致。还要知道“当前读”和“快照读”的区别。普通 select 是快照读不加锁。update、delete、insert以及 select ... for update、select ... lock in share mode 是当前读需要加锁。可重复读下幻读问题主要发生在当前读场景InnoDB 用间隙锁Gap Lock和临键锁Next-Key Lock来处理。第一天建议这样安排上午把 ACID、事务隔离级别、默认级别、redo log、undo log、binlog 的概念全部理一遍画出三条日志分别做什么。下午把 MVCC 的隐藏字段、undo 版本链、ReadView 生成时机、快照读和当前读的差异写清楚。晚上找 10 道事务和隔离级别相关面试题不给看答案自己先口头回答再对答案。这里要提醒一个很典型的误区很多人把“可重复读”理解成“永远不会出现幻读”。实际上可重复读只保证快照读的结果一致当前读场景下如果锁范围没有覆盖到新增数据或者没有正确使用间隙锁依然可能出现幻读。面试时如果能主动提到这一层会明显比背概念更有优势。3. 第 2 天索引、执行计划与慢 SQL 优化第二天的重点是索引因为索引是 MySQL 面试题里出现频率最高的一类而且和实际开发结合最紧密。高频问题包括索引有哪些类型BTree 和 BTree 有什么区别为什么用 BTree 不用二叉树或哈希索引聚簇索引和非聚簇索引的区别什么是回表什么是覆盖索引什么情况下索引会失效联合索引最左前缀原则怎么理解explain 里的 type、key、rows、Extra 分别怎么判断。先回答最常见的“为什么 InnoDB 用 BTree”。BTree 的数据都存放在叶子节点并且叶子节点之间通过指针串联适合范围查询和顺序扫描。非叶子节点只存索引键和指针单页能存更多索引项树更矮磁盘 IO 更少。相比哈希索引BTree 支持范围查询、排序、前缀匹配。相比 BTreeBTree 的叶子节点更紧凑遍历更方便层高更稳定。如果只背到这里可能还不够。面试官很可能会继续问“那聚簇索引呢”。InnoDB 的数据文件本身就是按主键索引组织的主键索引的叶子节点存放整行数据所以主键索引就是聚簇索引。非主键索引的叶子节点存放主键值所以根据非主键索引查询时如果查询列不在索引里就要再回表到主键索引里拿整行数据。这里最值得掌握的是“覆盖索引”。如果查询只需要索引里包含的列就不需要回表可以减少 IO。面试和实际优化中覆盖索引都是非常重要的优化手段。比如select id, name from user where name 张三如果 name 上有索引而 id 在叶子节点里也有查询就不需要回表。索引失效问题也是高频。常见场景包括对索引列使用函数或计算比如where YEAR(create_time) 2026。隐式类型转换比如字符串索引列用数字比较。模糊匹配用了前导通配符比如like %abc。联合索引没有按最左前缀使用。使用or且其中一个条件没有索引。优化器判断全表扫描比索引扫描更优时也会放弃索引。注意索引失效不是所有情况都绝对。比如like abc%是可以走索引的。or如果两侧字段都有索引优化器也可能走索引。回答这类问题时不要说“一定失效”更稳的说法是“在优化器选择时可能不选索引需要结合 explain 和实际数据量判断”。联合索引最左前缀原则也要讲清楚。联合索引(a, b, c)相当于建立了a、ab、abc几套索引。查询条件包含a时能命中只有在包含a的前提下才能继续匹配b再继续匹配c。如果跳过b直接查a和c那么a能走索引c只能在索引筛选后做进一步过滤不能完整使用索引。执行计划同样不能跳过。explain 输出里的几个重点type从好到差大致是 system、const、eq_ref、ref、range、index、ALL。ALL 通常意味着全表扫描。key实际使用的索引。rows估算要扫描的行数值越大风险越高。Extra出现 Using filesort、Using temporary 时要重点优化Using index 说明使用了覆盖索引是加分项。慢 SQL 优化的排查顺序我一般是这样先拿到慢查询日志确认 SQL 是哪些。看 SQL 的 where、order by、group by、join 条件涉及哪些列。对这些列检查索引是否存在。explain 看执行计划重点看 type、rows、Extra。如果索引存在但没走先排查索引失效原因。如果是统计信息不准或数据量太大可能要考虑重新分析表或调整 SQL。如果单条 SQL 已经优化到极限再考虑表结构、缓存、读写分离、分库分表。慢 SQL 优化最忌讳一上来就加索引。加索引不是万能的写多读少的表、频繁更新的列、低选择性的列加索引反而会拖慢写入和维护成本。实际项目中应该先通过 explain 确认是全表扫描、回表太多、排序临时表、还是数据规模本身的问题。第二天复习安排上午梳理索引类型、BTree 原理、聚簇索引、回表、覆盖索引、最左前缀。下午找 5 条不同类型 SQL自己写 explain 分析然后再看实际面试题里给出的执行计划。晚上整理一份“索引失效自查清单”并准备一个慢 SQL 优化案例从现象到 explain 到改动到效果逐步说清。这里多说一句实际面试时能把 explain 输出读明白的人已经超过很多人了。大部分候选人能说出 BTree 概念但一看到具体执行计划就说不清楚所以要单独练。4. 第 3 天SQL 写法、表结构、分库分表与大数据量方案第三天不要再看散题而是把重点放在“实际业务里怎么设计表、怎么写 SQL、数据大了怎么办”。8 月面试题里SQL 语句类、表设计类、分库分表类问题数量非常多而且很多是在项目经验考察阶段被问到的。先说说 SQL 写法。高频基础点包括delete、truncate、drop 的区别where 和 having 的区别group by 聚合时注意什么order by 排序的走索引问题limit 深分页为什么慢join 和子查询怎么选union 和 union all 的区别count(*)、count(1)、count(列名) 有区别吗。delete、truncate、drop 是很容易被连环问的一组概念。delete 是 DML逐行删除可以通过事务回滚不释放表空间truncate 是 DDL清空整表速度快不能按条件删除不能回滚会释放表空间drop 是 DDL直接删除表结构和数据。面试时可以顺带提一句生产环境删除大表数据尽量不要一次 delete 全量要分批删除否则会产生大量 binlog、锁竞争和主从延迟。where 和 having 的区别经常被搞混。where 在分组前过滤having 在分组后过滤where 不能使用聚合函数having 可以使用聚合函数。实际项目中能用 where 过滤就尽量用 where因为提前过滤可以减少分组数据量效率更高。count 系列也是高频。count(*) 和 count(1) 在 InnoDB 里基本可以认为没有实质区别都是统计符合条件的结果行数。count(列名) 会跳过该列为 null 的记录所以如果某列有 nullcount(列名) 可能和其他两个结果不同。如果只是想知道表总行数且不要求实时精确可以看show table status里的 rows但它是估算值。join 相关的问题要注意。实际项目中如果一个小表和一个大表做 join优化器通常会把小表作为驱动表。但真实场景还要看索引和连接字段。面试中常问“left join 和 inner join 有什么区别”“如果 join 很慢怎么办”回答时先确认是否有索引、是否大表之间 join、是否产生了临时表、连接字段类型是否一致。再看表结构。高频问题有char 和 varchar 怎么选int(11) 里的 11 是什么意思decimal 和 float 有什么区别text 字段能直接建索引吗时间字段用 datetime 还是 timestamp为什么要设置自增主键唯一索引和普通索引怎么选逻辑删除和物理删除怎么选。int(11) 是很容易踩坑的题。int(11) 中的 11 表示显示宽度不是存储长度。int 占用 4 字节能存储的范围固定显示宽度只影响在 zerofill 时的显示格式。MySQL 8.0 对显示宽度也有调整所以不要再说 int(11) 表示最多存储 11 位数字。char 和 varchar 的选择要考虑存储和可变长度。char 定长适合长度固定的场景比如手机号、订单号但也要注意字符集和字节占用。varchar 变长适合长度经常变化的场景使用时要设置合理长度不要一上来就 varchar(1000) 或 text避免行溢出和索引不能完整覆盖。decimal 用于精确小数比如金额float 和 double 是浮点数会有精度损失。面试题里出现过“金额字段为什么不用 float”这类问题回答时先说明二进制无法精确表示所有十进制小数再说明 decimal 是定点数能保证精度。这里还可以补充一句实际业务中金额计算也可以考虑使用整数分存储很多金融场景就是这么做的。时间字段的坑也比较多。datetime 和 timestamp 的区别包括占用空间、时区支持、可表示范围。timestamp 受时区影响范围到 2038 年datetime 不随系统时区变化范围更大。存储日志、创建时间、更新时间时建议统一使用 datetime 或 bigint 存毫秒时间戳但要看团队约定和查询需求。这里没有唯一标准关键是前后一致。分库分表和大数据量方案是这个阶段最有含金量的部分。面试官常问什么情况下需要分库分表分库分表有哪几种方式水平拆分和垂直拆分有什么区别分片键怎么选全局唯一 ID 怎么生成扩容和迁移怎么做分页查询怎么处理跨节点 join 怎么处理事务怎么保证。回答分库分表之前先把前提说清楚不要一上来就分库分表。一般先做 SQL 优化、加索引、开启缓存、做读写分离数据量达到一定程度单表写入或查询明显变慢后再考虑分库分表。分库分表会增加复杂度涉及分布式事务、全局 ID、跨库查询、数据迁移、扩容成本很高。水平拆分和垂直拆分是重点。垂直拆分是把不同业务字段拆到不同表或不同数据库比如把用户基本信息、用户订单信息分开水平拆分是把同一张表的数据按规则分布到多个表或多个库比如按用户 ID 取模、按时间分表。分片键的选择是水平拆分的关键。常见的策略有按主键 hash 取模、按范围分片、按业务键分片。选分片键时要注意业务查询要尽量带分片键否则会变成全库扫描。比如订单表按用户 ID 分片那查询单个用户的订单可以直接定位如果按订单做全局查询就需要遍历所有分片复杂度会很高。全局唯一 ID 生成方案也是面试热点。常见有使用 UUID、数据库自增 ID、Redis incr、雪花算法Snowflake等。雪花算法生成的是 64 位 long 型 ID包含时间戳、机器 ID、序列号具备趋势递增和全局唯一的特点。需要注意如果系统时钟回拨可能会出现重复 ID所以实现时要对时钟回拨做处理。事务问题在分库分表后尤其难。原来单库本地事务可以保证 ACID分库后跨库事务就不能靠普通本地事务解决了。常见方案包括分布式事务、事务消息、本地消息表、最大努力通知等。面试时不用把每一种都背得很深但至少要知道大致思路和适用场景。大数据量场景下的分页和排序也是常见问题。limit 900000, 10这种深分页很慢因为数据库需要扫描前面 90 万行后再丢弃。优化思路包括使用主键或唯一索引做游标分页比如where id 上一页最大 id limit 10或者先查到符合条件的 ID 列表再关联回原表获取完整数据。第三天复习安排上午过一遍 SQL 语法差异、常用聚合函数、join 写法、limit 深分页、count 系列问题。下午整理表结构设计原则把 char、varchar、decimal、int、datetime 这些字段类型高频题全部口头回答一遍。晚上重点准备分库分表面试题包括水平拆分、垂直拆分、分片键、全局 ID、分布式事务、跨库分页。5. 日志体系redo log、undo log、binlog 与主从一致性MySQL 面试题里日志体系是一个容易拉开差距的模块。很多候选人会背“redo log 是崩溃恢复用的binlog 是归档用的”但被追问“为什么需要两份日志”“两阶段提交解决了什么问题”时就开始含糊。先把三个日志分别说清楚。redo log 是 InnoDB 的物理日志记录的是“对数据页做了哪些修改”主要用于崩溃恢复。MySQL 在更新数据时不会每次提交都直接刷新数据页到磁盘而是先写 redo log这样即使数据库崩溃也可以通过 redo log 重放恢复数据从而保证持久性。undo log 是 InnoDB 的逻辑日志主要用于事务回滚和 MVCC。修改数据前会把旧值记录到 undo log事务回滚时可以通过 undo log 恢复旧数据MVCC 的多版本链也依赖 undo log 中的版本记录。binlog 是 MySQL Server 层的归档日志记录的是逻辑变更主要用于主从复制、数据恢复和审计。binlog 有 statement、row、mixed 三种格式。row 格式记录的是行变更前后内容更安全statement 格式记录的是 SQL 原文日志量小但可能因为函数、时间函数等导致主从不一致mixed 是混合格式。现在高可用和数据一致性要求高的场景普遍推荐使用 row 格式。redo log 和 binlog 是两份不同的日志一个在存储引擎层一个在 Server 层。两个日志写入时机不同如果没有机制保证一致性就会出现“binlog 里有记录但 redo log 没有”或反过来导致主从数据不一致。所以 InnoDB 在提交事务时采用两阶段提交先写 redo log 并标记 prepare再写 binlog最后把 redo log 标记为 commit。这样无论哪个环节崩溃都能通过对比两个日志的状态来恢复或回滚保证数据一致性。面试中如果被问到“主从复制延迟数据不一致怎么办”可以这样回答先确认是延迟还是不一致。延迟可以通过show slave status查看 Seconds_Behind_Master或对比主从 binlog pos。主从延迟常见原因包括从库硬件性能低于主库、大事务执行时间长、主库写入并发高、从库回放配置不足。优化思路包括避免长时间大事务、控制批量更新和删除的行数、优化慢 SQL、提高从库配置、开启并行复制、读写分离时路由策略留出延迟容忍度。如果出现数据不一致可以借助校验工具对比数据再核对 binlog 位置定位差异范围。日志这块面试官还喜欢问“一个 update 语句从执行到提交MySQL 大概经历了什么”。回答流程大致是客户端发送 update 到 MySQL Server。分析器做语法解析优化器生成执行计划。执行器调用 InnoDB 接口执行更新。要更新的数据页如果在 Buffer Pool 里就直接用不在就先从磁盘读入 Buffer Pool。记录 undo log用于回滚和 MVCC。更新 Buffer Pool 中的数据页。写入 redo log buffer事务提交时按配置刷新到 redo log。写入 binlog。两阶段提交完成。等待客户端确认。不用把每一步背得一字不差但要知道大致顺序尤其要能说清 undo log、redo log、binlog 分别在哪个阶段起作用。这里补一句经验如果面试官问的是“为什么要写 redo log 而不是直接刷数据页”可以从顺序写和随机写角度回答。redo log 是顺序追加写入比随机刷数据页开销小、性能高同时又能保证持久性。这个点在真实工作里也很有用批量更新数据时磁盘 IO 和提交频率的设计都会涉及这个底层原理。主从复制部分还需要知道复制的基本流程主库把变更写入 binlog从库的 IO 线程拉取 binlog 并写入 relay logSQL 线程读取 relay log 并回放。从库可能出现延迟因为回放是重放主库写过的 SQL 或行变更如果主库压力高、事务大、从库性能差延迟就会放大。面试时如果能主动说一句“row 格式下产生的大事务在从库回放时也会造成延迟所以批量更新要分批”会显得有实际项目经验而不是只背概念。6. 锁、死锁与一致性读的高频追问锁这块在 MySQL 面试题里往往不会单独一次性考完而是穿插在事务和索引问题里。常见问题有表锁和行锁有什么区别InnoDB 的行锁是怎么实现的共享锁和排他锁有什么区别间隙锁和临键锁是什么什么时候会加表锁什么是死锁怎么排查和避免。InnoDB 的行锁不是直接锁“行记录”那么抽象而是基于索引来实现的。如果更新语句没有使用索引InnoDB 可能会通过全表扫描来加锁实际上锁的范围会扩大严重时表现为“行锁变表锁”。这是面试高频误区实际开发中也经常踩。共享锁S 锁和排他锁X 锁共享锁之间兼容因为都只是读共享锁和排他锁互斥排他锁之间互斥。select ... for update加的是排他锁select ... lock in share mode加的是共享锁。普通 select 不加锁走 MVCC 快照读。间隙锁是锁一个范围而不是某条具体记录主要用来防止在可重复读级别下出现幻读。比如where id between 10 and 20的当前读如果范围内没有全部被记录命中InnoDB 可能对不存在的间隙加锁阻止其他事务插入符合条件的新记录。临键锁是记录锁和间隙锁的组合锁住左开右闭区间。死锁是面试官比较喜欢问的场景题。出现死锁的必要条件包括两个或多个事务持有对方需要的锁并且互相等待加上锁无法剥夺和循环等待就会形成死锁。InnoDB 会检测死锁并回滚其中一个事务所以直接报错一般是 1213 错误Deadlock found when trying to get lock。实际排查死锁时我会按这个顺序看报错信息确认是死锁还是锁等待超时。死锁是 1213锁等待超时是 1205。使用show engine innodb status查看最近一次死锁的详情看涉及哪些表、哪些索引、哪条 SQL。看事务的加锁顺序是不是多个事务按相反顺序更新了多张表或相同范围的数据。看是否因为无索引导致锁范围过大把行锁升级成大面积锁。调整业务代码让事务按固定顺序访问表和行缩小事务范围减少持锁时间。如果是批量更新考虑分批提交避免一个超长事务持有大量锁。出现死锁不一定是数据库配置问题很多时候是业务代码里的加锁顺序不统一。面试题如果问“怎么避免死锁”不要说“优化数据库参数”应该先说业务层面统一加锁顺序、减少事务执行时间、避免大事务、尽量避免在事务里做远程调用和外部 IO。数据库层面可以调整锁等待超时时间和隔离级别但根因通常还在业务逻辑和 SQL 写法上。MVCC 和锁之间的关系也是一个很好的回答切入点。普通查询走 MVCC不加锁适合读多写少当前读需要加锁适合需要严格一致性的场景。如果对同一行数据并发的 update 和 select普通 select 读到的快照可能是旧值这并不代表数据错了而是隔离级别的可见性规则决定的。所以面试时被问“为什么加了事务后别的事务读不到我修改的数据”这类问题本质上就是 MVCC 可见性和锁的效果。7. 常见面试题快答和避坑清单8 月面试准备时间紧很多人会直接去刷“MySQL 面试 200 题”但刷题时如果只记住答案不理解“为什么”面试现场换一种问法就答不上来。下面这些是高频题里最容易答错或者答得含糊的我把容易踩坑的地方标出来。第一组隔离级别和事务。问MySQL 默认事务隔离级别是什么答InnoDB 默认 Repeatable Read可重复读。面试时最好补一句可重复读通过 MVCC 和间隙锁来避免很多幻读场景但当前读下仍可能出现幻读需要临键锁和间隙锁配合。坑点不要把默认级别说成 Read Committed也不要只说“默认就是可重复读”没有解释。第二组索引和 BTree。问为什么 InnoDB 用 BTree 存储索引答BTree 叶子节点集中存放数据且叶子节点之间有链表连接范围查询和扫描效率高非叶子节点可以放更多键树更矮IO 更少。坑点不要只说“BTree 查询快”要结合磁盘 IO、范围查询、聚簇结构说。第三组索引失效。问哪些情况下索引会失效答函数操作、隐式类型转换、like 前导模糊匹配、联合索引不按最左前缀、or 中某个条件无索引、优化器选择全表扫描。坑点不要把所有情况说成“一定会失效”要强调优化器决策和实际数据。第四组count。问count(*) 和 count(1) 有区别吗答在 InnoDB 下基本无区别都是统计行数count(列) 会跳过 null。坑点不要听到一些旧文章就说 count(*) 比 count(1) 慢MySQL 5.7 和 8.0 主流实现已经不是这个结论。第五组limit 深分页。问limit 1000000, 10 为什么慢答需要扫描并丢弃前面 100 万行。优化方案是游标分页或基于主键定位。坑点不要只说“加索引就能优化”深分页即使有索引也要扫描大量记录重点是减少扫描范围。第六组char 和 varchar。问选择 char 还是 varchar答长度固定用 char长度变化大用 varchar。但要注意字符集和字节占用不要盲目使用超长 varchar。坑点不要认为 varchar 一定比 char 省空间varchar 本身有额外长度字节如果数据长度都很接近char 可能更合适。第七组分库分表。问什么时候需要分库分表答先排除 SQL 问题和索引问题再通过读写分离、缓存、归档等方式缓解当单表数据量极大写入和查询都出现明显瓶颈后再考虑水平或垂直拆分。坑点不要把分库分表当作银弹回答时先说代价和前提再讲方案。第八组日志和主从一致性。问binlog 和 redo log 有什么区别答binlog 是 Server 层逻辑日志用于复制和恢复redo log 是 InnoDB 物理日志用于崩溃恢复。提交事务时用两阶段提交保证两者一致。坑点不要混淆“主从复制”和“崩溃恢复”各自的日志来源。第九组死锁。问死锁怎么排查答先确认报错是 1213 还是 1205再通过show engine innodb status看锁等待和事务状态检查加锁顺序、事务大小、有无索引。坑点不要一上来就改数据库参数先看业务代码和 SQL 的执行计划。第十组慢查询。问线上一条 SQL 很慢怎么排查答先看慢查询日志explain 看执行计划再看索引、数据量、锁等待、主从延迟。逐步排除环境因素后再改 SQL 或表结构。坑点不要不看 explain 就开始加索引先确认瓶颈是查询路径还是锁或 IO。除了上面这些还有一个容易忽略的常识MySQL 8.0 和 5.7 在很多细节上有差异。比如 8.0 对窗口函数、CTE、默认字符集 utf8mb4 的支持都更完善8.0 还在优化器行为上做了调整。面试时如果项目还在用 5.7可以先说明自己项目里的版本再回答功能性问题这样更严谨。如果复习时间只有 3 天我不建议每天刷大量新题。正确做法是先建立知识框架再用题目自测最后针对答不上来的点回看原理和场景。刷题是为了检验漏洞不是为了背标准答案。最后再补充一份通用的 MySQL 面试准备清单适合贴在电脑前能画出事务隔离级别、MVCC、当前读和快照读的概念图。能画出 BTree 索引结构说清聚簇索引、辅助索引、回表、覆盖索引。能自己 explain 一条慢 SQL说出 type、key、rows、Extra 的含义和优化方向。能说清 redo log、undo log、binlog 各自的写入时机和用途。能说清一个 update 语句从请求到提交经过哪些核心环节。能说清主从复制的流程、延迟原因、常见处理方式。能说清死锁的成因、排查命令、业务层优化手段。能给出至少 3 个 SQL 优化案例从现象到方案到结果。能说清什么时候该分库分表分片键怎么选全局 ID 怎么生成。能说出 MySQL 8.0 与 5.7 在你项目里最明显的差异点。这十个点如果都能做到“能讲、能画、能写”而不是“听说过、看过”那 8 月面试里 MySQL 这一块的胜率会高很多。我个人的建议是第 1 天把事务和 MVCC 彻底搞懂第 2 天把索引和 explain 练熟第 3 天把 SQL、表结构、分库分表和日志串起来。三天时间足够让一个有一定基础的人把零散知识点变成可输出的体系。关键是每学一个点都要能用一句话给面试官讲清楚“它解决什么问题、为什么这样设计、实际使用中会踩什么坑”。MySQL 面试不是背答案比赛而是考察你能不能把数据库原理和平时的开发场景连接起来。抓住事务、索引、日志、锁、优化这五条主线8 月面试基本就不会慌。