MySQL面试必看：7大领域50题搞定B+树、事务锁与高可用

你啃过很多MySQL面试题，为什么一上考场还是会被一个“为什么选B+树”问得卡壳？大概率不是背得少，而是没弄明白面试官把题目放在一张卷子上时，到底在考你什么。MySQL面试从来不是单纯考“会不会写SQL”，而是分层考核：能不能写对、懂不懂原理、有没有架构观、能不能收场。

这篇文章会把50道经典题目拆进7大领域里，从SQL基本功、索引优化、事务锁、InnoDB底层、主从复制、分库分表，到运维排查调优，每类都给你一套可以直接用的准备思路。无论你是准备校招、跳槽，还是想系统性补一遍MySQL知识体系，这篇内容都值得花一晚上认真过一遍。我尽量说人话，少讲废话，把面试官真正想听的逻辑讲透。

1. 先花5分钟摸清MySQL面试的出题逻辑

1.1 不管搜到多少题，面试官其实只看四件事

很多人备考面试喜欢刷题，刷完200道觉得自己稳了，结果面试官换个问法就崩。原因很简单：你记的是“这道题的答案”，而不是“这类问题的底层逻辑”。从面试官视角看，MySQL考察从来不是割裂的，而是围绕四个维度层层深入。

第一个维度是SQL基本功。能不能快速写出正确、可读、不走全表扫的SQL，这是基础，通常放在开场热场。第二个维度是原理深度，即事务、索引、锁、存储引擎这些机制到底怎么实现，为什么MySQL要这么设计。第三个维度是架构扩展能力，涉及主从复制、读写分离、分库分表、分布式事务，主要面向2-3年经验以上的岗位。第四个维度是运维排查能力，慢SQL定位、死锁分析、误删恢复、连接数暴增，考的是遇到线上故障时的冷静程度和排查方法论。

这四个维度不是让你“平均用力”，而是要根据目标岗位调整。初级岗重点在SQL和索引，中高级岗必须在事务锁、复制、分库分表上有自己的理解。当你把一堆看似零散的问题按这四个维度归好类，再去看所谓的“50道经典题”，就会觉得清晰很多。

1.2 7大领域的划分和50道题的比例

我把常见的MySQL面试命题点归纳为7大领域，正好对应文章标题里的“7大领域”。这样做的好处是：你准备的时候有地图，面试官追问的时候有边界。只要他在这7个领域里出牌，你都能快速定位到对应的知识模块。

领域A是SQL查询与常用函数，考的是写得出写不对；领域B是索引与执行计划，考的是查询性能敏感度；领域C是事务、隔离级别、锁与MVCC，这是MySQL并发控制的核心；领域D是存储引擎与InnoDB底层结构，考你对数据落盘机制的理解；领域E是主从复制与高可用，考架构容灾；领域F是分库分表与海量数据方案，考扩展性设计；领域G是运维、备份与性能调优，考线上救火能力。

50道题的比例我建议这样分配：SQL约6道，索引约8道，事务锁约8道，InnoDB约7道，复制约7道，分库分表约8道，运维约6道。这个比例基本符合面试真题分布：索引、事务、锁永远是大头，SQL和复制次之，分库分表在高级岗出现率更高。你不需要真的数着题号去背，但心里要有数，别把时间全砸在背某个冷门参数上。

1.3 这套题怎么用才不浪费

很多人的备考方式是把题和答案抄进笔记，完了。说实话，这样效率极低。我的建议是分三轮过。

第一轮先做“摸底检测”，不看任何答案，每道题给自己10分钟口头回答，能讲清楚就过，讲不清楚做标记。第二轮针对没讲清楚的题看原理，看的时候不要只背结论，而是追问一句“为什么会有这样的机制”“如果换一种实现会有什么问题”。第三轮再做“模拟面试”，可以对着镜子或让朋友随机抽题，你要做到不看笔记也能把这个概念讲得让外行听懂。

这套方法的核心原因是：面试本质上是一次口头表达，你的大脑只有在不依赖外部提示的情况下能流畅组织语言，才算真正掌握了这块知识。别嫌麻烦，考场上你就能体会到好处了。

2. 领域一：SQL查询题，现场写不对就直接送

2.1 常考SQL题的类型与真实意图

SQL题是很多面试的开场，表现好坏直接决定面试官对你基础能力的判断。如果你的SQL连基本join、group by、窗口函数都写不利索，后面聊索引和底层原理基本不会再给你高评价。常见题型分三类：多表关联与聚合统计、排名与TopN问题、窗口函数和去重问题。

面试官出这些题其实不是考你会不会背语法，而是观察你的解题思路。比如查“每个部门工资最高的员工”，你会先想到子查询、再想到关联join，还是直接想到窗口函数？解法本身没有唯一答案，但你能不能给出一个“先分组取最大值，再回表匹配”的清晰步骤，才是关键。遇到这种题先别急着写代码，先问清楚表结构、有没有重复数据、要不要并列排名，这些需求边界搞清了，SQL反而好写。

2.2 三道高频SQL题目的拆分演示

第一道典型题：给出员工表和部门表，查出每个部门工资最高的员工。普通解法先按部门分组求出最高工资，再用这个结果关联员工表。如果要稳妥处理多个员工的工资并列第一，直接用DENSE_RANK窗口函数更安全。

sql复制SELECT d.name AS dept_name, e.name AS emp_name, e.salary
FROM (
    SELECT name, salary, department_id,
           DENSE_RANK() OVER(PARTITION BY department_id ORDER BY salary DESC) AS rk
    FROM employee
) e
JOIN department d ON e.department_id = d.id
WHERE e.rk = 1;

这道题我给你的建议是：先说出“按部门分组取最大值”这个思路，再问面试官是否看重要并列，最后再决定用不用窗口函数。不要一上来就写窗口函数，虽然写得溜，但也容易暴露出你对业务场景边界考虑不足。

第二道典型题：查出连续登录3天的用户。这类题的通用套路是把login_date减去按用户分组的行号，得到一个分组标识，再按用户和这个标识聚合，看连续天数是否达标。网上很多答案会忽略用户一天多次登录的去重操作，导致同一用户重复计入，这是面试中最容易失分的点。

第三道典型题：“存在则更新，不存在则插入”应该怎么写。MySQL里最常用的方案是INSERT ... ON DUPLICATE KEY UPDATE，底层依赖唯一索引或主键冲突触发更新。面试官会顺势追问“如果表没有唯一键怎么办”，你要能回答出“这个语法无法生效，只能先SELECT判断再决定INSERT或UPDATE，但要注意并发下会有竞态”，这说明你真的理解这条语法的前提条件。

2.3 现场写SQL的三个实用提醒

我见过太多候选人栽在一些小细节上，这里总结三条。

第一条，写完后一定要口头“跑一遍数据”。不要交卷就完了，找一组有边界的数据，比如部门为空、同分多人、日期重复，从结果反推SQL是否正确。面试官很愿意看到这种自测习惯。第二条，确认MySQL版本和模式。MySQL 8.0开始支持窗口函数，如果是5.7环境，DENSE_RANK不可用，你可以用用户变量或连表方式替代。第三条，随手提一下性能考虑。面试官问你SQL时，通常潜台词还包括“这条SQL会不会慢”，在答案里补一句“这个sql可以在department_id和salary上建联合索引”，立刻会让你的回答高一个层次。

3. 领域二：索引与SQL优化，99%的候选人会在这翻车

3.1 为什么面试必问B+树，又该怎么答

不管你是面开发还是面DBA，索引题总会占两到三成。而“为什么InnoDB用B+树”是绝对绕不开的名题，因为它能同时考你数据结构、磁盘IO、MySQL存储方式三个层面。

标准回答框架是这样：数据库索引存储在磁盘上，读取磁盘是代价很高的操作，我们希望查找次数越少越好。B+树是一种多路平衡搜索树，一个节点能存储多个key，所以树的高度很低，一般3到4层就能存千万级数据，意味着查询时最多几次磁盘IO就能定位到记录。和B树相比，B+树的非叶子节点不存数据，只存key，因此同样大小的页能容纳更多key，树更矮；同时B+树的叶子节点通过链表串联，范围查询非常舒服，B树的叶子节点没有这种连续链表，范围查询往往要做多次回溯。

如果你还能补一句“InnoDB的叶子节点直接存放整行数据，聚簇索引和二级索引都基于B+树，但二级索引叶子节点存的是主键”，面试官对你这题的评价会直接拉高。面试官喜欢的不是把定义背得完整，而是能把“为什么选它”和“其他结构哪里不行”对比清楚。

3.2 联合索引最左前缀与索引失效场景

联合索引是面试里另一座大山。面试官常给出类似“联合索引(a,b,c)，WHERE a=1 AND c=3能用索引吗”这样的题，考的就是最左前缀原则。基本原则很简单：MySQL只能从联合索引的最左列开始连续匹配，跳过中间列会导致后续列无法用于索引定位。

举个例子，联合索引建立在(a,b,c)上，如果你的查询条件是a=1 AND c=3，那么a能用于索引定位，c就不能继续用于索引检索，只能做索引下推或回表后的过滤。面试官再追问“什么是索引下推”，你要能答出：MySQL 5.6之后引入的ICP特性，允许存储引擎在索引遍历过程中直接对索引字段进行条件过滤，减少回表次数。比如上面的例子，a定位后，c可以在索引层先过滤一遍，而不是把所有满足a=1的整行记录都捞出来再where过滤。

索引失效的经典场景我也帮你整理一下：对索引列使用函数或表达式、隐式类型转换、LIKE以%开头、联合索引不使用最左前缀、OR连接时两侧列没有都被索引覆盖。这里要特别注意，现在MySQL的优化器可能对部分场景做优化，比如OR的两边都有索引，可能走index merge，所以回答不要用“一定失效”这种绝对说法，说“大概率会退化成全表扫描”更严谨。

3.3 用EXPLAIN快速判断一条SQL有没有走对索引

面试手撕SQL优化题时，EXPLAIN是核心工具。主考的几个列要能脱口而出：type、key、rows、Extra。

type列从好到坏大致是：system、const、eq_ref、ref、range、index、ALL。一旦看到ALL，基本说明这条SQL在扫全表。看到index，说明虽然扫了索引树，但依然是把整棵索引都过了一遍，一般是因为查询列都在二级索引里但缺少更优条件。rows列是估算扫描行数，虽然不精确，但量级差异能反映索引是否生效。Extra列里出现Using temporary或Using filesort就要警惕了，这说明排序或分组没有利用索引，需要临时表或文件排序，这对大表通常是性能杀手。

真正面试时，你应该现场演示一遍排查过程。比如有一条慢SQL：

sql复制SELECT * FROM orders WHERE user_id = 123 ORDER BY create_time DESC LIMIT 10;

先跑EXPLAIN，如果看到type为ref、key为idx_user_id，这是不错的。但Extra如果出现Using filesort，说明create_time排序没法走联合索引。优化方向很明确：变更索引为(user_id, create_time)。这类“先分析、再建索引、再验证”的完整闭环，是面试官最爱看到的回答方式。

3.4 深分页和count统计，两个隐藏加分点

“LIMIT 1000000, 20为什么慢”是性能优化里的经典陷阱。慢不是慢在最后取20条，而是MySQL必须先扫描前100万条记录，把它们全部丢掉，才能拿到目标行。页码越深，扫描的无效数据越多。

推荐优化方案有三类：一是延迟关联，先通过覆盖索引查出目标主键，再回原表关联取完整行；二是记录上一页最后一条记录的位置，用WHERE id > last_id LIMIT 20这种方式做键集分页；三是业务上限制能翻到的最大页数。如果你在面试里能把这个问题的本质讲清楚，顺带说出三种方案各自的适用场景，这道题基本满分。

COUNT函数也很容易被当成送分题，但里面藏了版本知识。MySQL里COUNT()和COUNT(1)在InnoDB中性能基本一致，都不需要判断字段是否为空；COUNT(字段)会跳过该字段为NULL的行，如果字段允许NULL，它统计出来的结果和其他两个不一样。还有一点，MyISAM存了表行数，所以COUNT()直接读元数据很快，但InnoDB因为有MVCC版本链，不能直接读一个固定行数，所以必须经过统计。这个差异也经常被拿来考存储引擎。

4. 领域三：事务、隔离级别与锁，答到MVCC才算合格

4.1 ACID不要背定义，要说清楚谁负责什么

“事务的ACID分别是什么意思”是入门题，但面试官往往会深入追问“这些特性在MySQL里靠什么实现”。背定义的人会卡在这里，真正理解的人会这样回答。

原子性靠undo log保证。事务执行过程中如果出错要回滚，就把变更前的数据记到undo log，回滚时把数据恢复回去。持久性靠redo log保证。事务提交后，即使数据库重启，redo log也能把未落盘的数据重放回来。隔离性靠锁和MVCC保证，多个事务并发执行时，系统通过加锁和版本链机制让它们互不干扰，或者按隔离级别允许一定程度的干扰。一致性是最终目标，靠开发者的业务约束加数据库的原子性、隔离性、持久性共同实现。

这个答题结构的好处是，你不需要死记ACID的字面定义，而是从“如果MySQL要支持一个事务，它必须在哪些环节做设计”的角度把整个机制贯穿起来。面试官听到你能独立说出redo和undo的职责分工，就知道你不是背题，而是理解了事务设计。

4.2 四种隔离级别与脏读、不可重复读、幻读的关系

隔离级别的考点非常固定，但很多人答不全。简单列一个表：

回答时要特别注意最后一列。MySQL的默认隔离级别是REPEATABLE READ，它在InnoDB引擎下通过MVCC和间隙锁，基本已经解决了幻读问题，所以你不能直接照搬“RR会产生幻读”这个结论，而得说“在InnoDB里RR通过next-key lock机制，对当前读可以防止幻读；对快照读，因为MVCC生成了稳定的ReadView，也不会看到别人新插入的行”。

不可重复读和幻读的区别也经常被追问。不可重复读是指同一行数据，两次读取结果不一样，比如事务A第一次读到余额100，事务B把它改成80，事务A再读就变成80了。幻读是指同一个查询条件，两次读取返回的行数不一样，比如事务A第一次查ID大于100的记录只有3条，事务B插入一条ID=200的记录并提交，事务A再查很可能就多了一行，就像产生了幻觉。把这两个区别用具体数字说清楚，比背三百字定义有用得多。

4.3 MVCC原理，一张图讲清楚快照读和当前读

MVCC全称是多版本并发控制，理解它需要先知道三个隐藏字段。InnoDB每行数据上都有trx_id记录最近一次更新该行的事务ID，roll_pointer指向undo log里旧版本链。当一个事务去读取某行时，它不能直接看到所有版本，而是生成一个ReadView，里面记录当前活跃事务ID列表。

ReadView生成的时机很关键。READ COMMITTED隔离级别下，每次SELECT都会生成一个新的ReadView，所以两次查询可能看到不同版本，产生不可重复读。REPEATABLE READ隔离级别下，只有第一次SELECT会生成ReadView，后续查询复用同一个ReadView，所以某个时间点之前的已提交版本不会变，从而实现了可重复读。你只要把这个区分答出来，面试官就会认定你真正理解MVCC。

还要区分快照读和当前读。普通SELECT是快照读，不加锁，直接读版本链；INSERT、UPDATE、DELETE以及SELECT ... FOR UPDATE这些语句是当前读，必须读最新版本并加锁。这个区分非常重要，因为很多人以为MVCC能解决所有并发问题，其实MVCC只解决快照读的隔离，当前读还是靠锁来保证。

4.4 死锁排查与预防，最好结合线上案例说

死锁属于高频压轴题，面试官想听的不是教科书定义，而是你有没有排过。死锁产生的必要条件不用全背，核心理解是：两个或多个事务各自持有一把锁，同时等待对方持有的锁，导致互相等待永远无法结束。

排查方法我要按操作顺序讲给你。第一步，执行SHOW ENGINE INNODB STATUS查看最近一次死锁信息，里面会直接打印两个事务持有和等待的锁。第二步，查询information_schema里的INNODB_TRX、INNODB_LOCK_WAITS表，看当前有哪些事务在等待。第三步，根据死锁日志里的SQL定位代码位置，分析两条事务加锁顺序是否相反。

给你一个很典型的例子：事务A先UPDATE id=1的记录，再UPDATE id=2的记录；事务B先UPDATE id=2，再UPDATE id=1。如果两个事务并发执行，就可能出现A持有id=1的锁等待id=2，B持有id=2的锁等待id=1，直接死锁。解决方案就是约定所有事务按相同顺序访问同一批资源，比如都按id从小到大操作。如果是批量更新，最好提前对主键排序。

4.5 乐观锁和悲观锁的落地实现

乐观锁和悲观锁这道题，很多人只知道概念，不知道代码怎么写。这里说个实操套路。

悲观锁就是SELECT ... FOR UPDATE，在事务里先锁定目标行，其他事务想改这条行就得等。适合并发冲突严重的场景，比如库存扣减。但要注意锁必须在事务里才有意义，如果不在事务里，执行完SELECT FOR UPDATE马上提交了，锁就释放了，等于没加。这个坑我在代码review里见过无数次。

乐观锁通常靠版本号或时间戳实现。更新时带上条件“version = 期望版本”，UPDATE返回影响行数为0就说明版本被改了，需要重试或报错。

sql复制UPDATE product
SET stock = stock - 1, version = version + 1
WHERE id = 123 AND version = 5;

一些对一致性要求没那么严格的场景可以用“条件更新+影响行数判断”代替版本号，比如扣减库存时WHERE stock > 0。回答的时候把两类锁的适用场景说清楚，再带一句“乐观锁适合读多写少、并发冲突不严重的场景；悲观锁适合写冲突严重、追求强一致的场景”，这道题就稳了。

5. 领域四：存储引擎与InnoDB底层，拒绝背概念

5.1 MyISAM和InnoDB的对比，依然爱考

面试官问MyISAM与InnoDB区别时，实际上是在确认你有没有根据业务正确选择存储引擎的意识。现在是InnoDB一统天下，但MyISAM概念题仍会作为切入点。

区别记忆可以从四个维度展开。事务和外键维度：InnoDB支持事务和外键，MyISAM不支持。锁粒度维度：InnoDB支持行级锁，MyISAM只支持表级锁，所以InnoDB的并发写入能力更强。数据存储维度：InnoDB采用聚簇索引，表数据和主键索引存在一起；MyISAM数据文件和索引文件分开存储。崩溃恢复维度：InnoDB有redo log，崩溃后可以恢复；MyISAM崩溃后更容易损坏。

现在还有一个新变化要记住：MySQL 8.0里MyISAM系统表已被数据字典替代，全文索引在InnoDB中也能使用了，所以不要再拿“InnoDB不支持全文索引”这种过时说法当答案。面试时强调“默认引擎是InnoDB，新表建议都用它”，然后分析业务确实需要高性能全文检索或只读报表场景时才有必要考虑其他引擎。

5.2 一条UPDATE语句从提交到落盘，完整经历了什么

这可能是InnoDB底层最值得背的一道题，因为它串起了redo log、binlog、Buffer Pool三块知识。

先说理想流程。UPDATE语句进来后，先走解析器、优化器生成执行计划，然后从Buffer Pool找到目标数据页。如果数据页不在内存，就从磁盘读入Buffer Pool。接着在内存中修改这行数据，同时生成undo log，用于记录旧值，方便回滚。修改后，这页数据变成脏页，并不会立刻写回磁盘，而是先记redo log，保证崩溃后能恢复。

关键来了。如果当前事务要提交，redo log需要经历prepare阶段，然后写binlog，最后redo log再进入commit状态。这个“redo log prepare -> binlog -> redo log commit”的顺序就叫两阶段提交。它解决的核心问题是：redo log和binlog是两套日志，如果不做两阶段，崩溃时可能出现redo log里记录了某个事务、binlog里却没记录，或者反过来，导致主从数据不一致。两阶段提交能让两份日志在崩溃恢复时达到一致。

最后，真正把脏页写回磁盘是后台线程在合适时机做的，可能是checkpoint触发，也可能是脏页比例过高或系统空闲时刷盘。面试官听到你能把WAL、两阶段提交、后台刷脏串成一条链路，就知道你对InnoDB的持久化机制有完整认知。

5.3 redo log为什么不直接写数据页，而要走WAL

很多候选人知道“先写redo log，再写数据页”，但说不清为什么要这么设计。这个问题的本质是：数据页的写入是随机IO，因为要更新的行分散在不同的16KB页里，每次写回磁盘都要定位到随机位置，很慢；而redo log是追加写的顺序IO，只需要把变更写入日志文件尾部，速度比随机IO快几个量级。

WAL机制可以理解成“先记账，后结账”。你开了一个很大的餐厅，不可能每来一桌客人都立刻去后厨清点一遍库存，而是先把订单写在本子上，等空闲了再批量处理。数据库也是这样，先保证崩溃恢复的日志已经落盘，至于数据页什么时候刷，可以交给后台线程统一调度。这样既保证了持久性，又提升了写入性能。

这里还有个高频追问：事务提交时，redo log是每次都fsync吗。答案是受参数innodb_flush_log_at_trx_commit控制。默认值是1，表示每次事务提交都刷盘，保证不丢数据；如果设为0，日志只留在内存由后台刷，性能最好但可能丢最近1秒数据；设为2表示先写到操作系统的page cache，再由系统决定何时刷入磁盘。回答这类参数时最好带上使用场景，不要只背三个数字。

5.4 Buffer Pool、Change Buffer与自适应哈希索引

Buffer Pool是InnoDB用来缓存数据页和索引页的内存区域，直接影响读写性能。Buffer Pool里采用改进后的LRU算法管理页面，而不是裸的LRU。原因是裸LRU有一个问题：一次全表扫描会把大量热页挤出去，这些热页后续还要用，结果缓存命中率剧烈下降。改进版LRU把链表分成young区和old区，新读入的页先进入old区，如果短时间内再次被访问，才晋升到young区。这样全表扫描的页就不容易把真正的热数据挤掉。

Change Buffer针对的是普通二级索引的写操作。当你要更新的二级索引页不在Buffer Pool时，InnoDB不急着去磁盘读页，而是先把变更记录到Change Buffer里，等后续页面被读到或系统空闲时再合并。它的核心价值是把随机读转化为顺序刷盘，大幅提高非唯一二级索引的写入性能。唯一索引用不了Change Buffer，因为唯一性约束必须立刻检查，你回答时要把这个限制点带上。

自适应哈希索引是InnoDB对热点数据页的优化。它会根据对索引页的访问模式，自动为某些频繁查询的页面建立哈希索引，让等值查询从走B+树变成O(1)级别的哈希查找。它不是DBA手动创建的，所以考察重点不是怎么建，而是“能理解它解决什么问题”和“为什么不能被预测”这两个层面。面试时用一句话介绍即可，不必展开太深。

6. 领域五六：主从复制、高可用与分库分表

6.1 主从复制的完整链路，必须能画出流程

主从复制是最常见的MySQL高可用方案，基本原理听起来不复杂，但面试官问深一点就会发现很多人只会背一句“主库写binlog，从库回放”。

完整链路是这样：主库上事务提交后会把变更写入binlog。从库启动一个IO线程，连接主库并请求指定binlog文件从某个位置开始的数据。主库有专门的binlog dump线程负责把日志推给从库。从库IO线程收到日志后，先写入本地的relay log中继日志。然后从库的SQL线程读取relay log并重放，最终使数据变更生效。主库、从库各自维护自己的binlog位点，用来标记已经同步到了哪个位置。

这个链路里最容易出的问题是位点不一致。旧方案里从库通过master_info记录主库binlog文件名和位置；MySQL 5.6后推荐GTID方案，事务有了全局唯一ID，同步就不需要关心具体位点，更便于主从切换。面试时如果你能主动提到GTID相对位点复制的优势，说明你用的是接近生产环境的经验，不是纸上谈兵。

6.2 binlog三种格式，要怎么选

binlog格式有STATEMENT、ROW和MIXED三种。STATEMENT格式记录SQL语句原文，日志量小，但某些不确定函数在不同库执行会导致数据不一致。ROW格式记录每一行变更前后的值，最安全，能精确同步，但日志量会大很多，尤其做批量更新时，可能产生海量binlog。MIXED是混合模式，MySQL自动判断，默认使用STATEMENT，遇到可能引起不一致的语句时自动切换为ROW。

生产环境我更推荐ROW格式。原因很简单：主从切换、误删恢复、数据订正这些场景下，ROW格式能提供更精确的变更记录，也能配合binlog2sql等工具做闪回。代价是磁盘和网络开销增加，可以通过调整binlog_row_image将日志记录精简为只记必要的列，让日志体积瘦身。

这道题回答得好的标志是你能结合场景说取舍，而不是只会背“ROW最安全”。面试官爱追问“既然ROW格式日志大，那批量UPDATE一万行会产生多少binlog”，你如果能答出“ROW会为每一行变更生成一条记录，日志量很大，所以生产中要关注磁盘空间和网络带宽”，说明你真处理过类似问题。

6.3 主从延迟怎么判断、怎么解决

主从延迟是生产环境的常客，也是面试高频场景题。最经典的判断指标是SHOW SLAVE STATUS里的Seconds_Behind_Master，它表示从库SQL线程回放落后主库的时间。但要注意，这个值在低版本和某些场景下并不完全准确，网络抖动、大事务、并行复制参数都会影响它。实际生产里更可靠的判断方式是对比主库和从库当前执行到的最新事务时间戳。

主从延迟的常见原因有四个。主库上跑了一个大事务，比如一条UPDATE影响了千万行，在从库只能串行回放，会拖很久。主库写入并发很高，从库只有单线程在回放，容易出现瓶颈，不过从库开启并行复制后这个问题会缓解。从库机器性能比主库差，比如磁盘慢、CPU核数少，回放能力跟不上。还有一个很容易忽略的是，从库上同时有业务查询在跑，占用了IO或CPU资源，拖慢了SQL线程。

解决方案要分层答：先优化大事务和慢SQL，减少增量数据量；再开启并行复制，利用从库多核能力；接着做好主从机器配置对齐，不要一边用高配主库一边用低配从库；最后如果延迟无法消除，考虑读写分离降级，把部分读流量切到延迟较低的从库或临时扩容只读实例。面试里能按“主库写入优化、从库消费加速、架构层分流”三个维度展开，就比只说改配置要完整得多。

6.4 分库分表什么时候做，拆分策略怎么定

分库分表这道题能区分有没有真正面对过海量数据。先给个结论：不要一遇到数据量大就分，优先做索引优化、冷热归档、读写分离。分库分表是最后手段，因为它会引入分布式事务、跨库join、主键生成、数据迁移等一系列复杂度。

什么时候才需要分？可以从数据量、QPS和存储压力三个维度看。比如单表数据量超过千万级且还在快速增长，单库写入QPS常年打满，或者单表数据量并没有多大但行锁竞争特别激烈。判断核心不是绝对值，而是“当前架构是否已经无法通过常规优化满足业务增长”。

拆分策略分垂直和水平两类。垂直拆分是把不同业务模块的表拆分到不同库，比如把用户表放到用户库、订单表放到订单库，解决的是“单库表太多导致IO竞争”，但解决不了单表数据量大。水平拆分是把同一张表的数据按某字段分散到多张表，比如按user_id分表或分库，解决的是单表行数过多、查询变慢的问题，但会引入跨节点查询。

面试题里最常考的是实现层面，我给一个简单方案参考。假设订单表要按用户ID水平拆分到4个库，可以先用取模规则做映射，比如user_id % 4决定进哪个库。取模方案实现简单，但后续扩容很痛苦，因为扩大实例数后旧数据的映射关系全变了。扩展性更好的方案是一致性哈希，或者范围分片、基因法分片。范围分片天然支持范围查询但不均衡，一致性哈希扩容更平滑但实现复杂。回答时要根据自己的真实场景选型，不要把所有方案讲一遍就完了。

6.5 分片后那些经典“怎么办”题

分库分表后，面试官马上会追问一系列问题：跨库join怎么办、分布式事务怎么做、全局唯一ID怎么生成、分页排序怎么做。这几个问题准备思路如下。

跨库join没有完美的通用方案，工业界常用四种解法：字段冗余，比如订单表上直接冗余用户名，避免join用户表；数据同步汇总，把需要join的维表同步到同一个库里；接口聚合，应用层拿到多个库的结果后在内存里组装；引入分布式中间件，让中间件帮做部分关联。答完加一句“实际业务中尽量避免跨库join，优先从设计上规避”，这句话能体现你的架构意识。

全局唯一ID为什么不能用自增？因为分库分表后每个库的自增ID从1开始，会造成重复。常用方案有雪花算法、号段模式、UUID，生产上用得最多的是雪花算法和号段模式。雪花算法