MySQL高频面试题全解析：从索引优化到主从复制的实战指南

又到一年跳槽季，后台私信里问得最多的还是那句话：“MySQL 面试题到底怎么准备？”说实话，市面上的题解很多，但大部分都停留在背答案的层面——索引优化八股背得滚瓜烂熟，面试官换一种问法就露怯。我把过去三年里真实面过、帮朋友模拟面试复盘过、以及各大技术社区讨论度最高的 MySQL 高频面试题重新梳理了一遍，剔除了那些问了等于没问的送分题，留下的每一条都能往深处挖两层。这份清单适合正准备 Java 后端、大数据、数据库运维方向面试的读者，也适合入职两三年想系统查漏补缺的开发者。我会尽量讲清楚面试官为什么这么问，以及回答到哪一步能加分。

1. 索引为什么用 B+ 树：从数据结构一路追问到底

索引相关的内容在 MySQL 面试里出现频率实在太高了，几乎每个面试官都会从一个看似基础的问题开始，然后层层加码。你如果只背到“B+ 树查询快”就停下，大概率会被追问“那为什么不直接用红黑树？”或者“Hash 索引不是更快吗？”。

1.1 面试官问索引，真正想考什么

很多人在准备索引题时有误区：喜欢背结论而不理解推导过程。面试官问“为什么 MySQL 用 B+ 树做索引”，其实是想考察两个层面的东西：第一，你知不知道各种数据结构的适用场景，包括树高、磁盘 IO、范围查询、顺序访问；第二，你能不能把“磁盘预读”这个隐藏前提讲出来。

这里给一个直观的类比。数据库的索引好比一本很厚的书的目录，如果目录本身就要翻很多页才能找到目标，那你还不如直接翻正文。磁盘上的数据是按页读取的，一次 IO 大概能读 4KB 到 16KB 不等，InnoDB 默认页大小是 16KB，所以数据结构的设计目标非常明确：尽可能让一次磁盘 IO 读到更多有效信息，同时减少树的高度。

B+ 树相比 B 树的优势在于：所有数据都存在叶子节点，非叶子节点只存键值，这样一棵 3 层的 B+ 树可以放下千万级别的数据，而从头到尾只要 3 次磁盘 IO。范围查询的时候，叶子节点之间有指针相连，可以直接顺序遍历，这是红黑树做不到的。反观红黑树，虽然内存里增删查都很优秀，但树的高度比 B+ 树高很多，而且在磁盘上不连续存储，范围查询需要回溯，根本不适合做磁盘索引。

1.2 聚簇索引与非聚簇索引：回表是怎么发生的

高频题里“聚簇索引”和“非聚簇索引”的区别几乎是必问的。简单说，InnoDB 里聚簇索引的叶子节点直接存放整行数据，所以一张 InnoDB 表只能有一个聚簇索引；你给表加的主键就是聚簇索引，如果没有主键，InnoDB 会用第一个非空的唯一索引替代，再没有就生成一个隐藏的 rowid。

非聚簇索引（也就是二级索引）的叶子节点存的是索引列的值加主键值。这里就引出了“回表”的概念：你通过二级索引找到主键，再用主键去聚簇索引里查一次完整数据，这个过程就叫回表。

我见过不少候选人能说出“回表”的定义，但被问到“怎么避免回表”的时候思路打不开。最优解是覆盖索引：如果你要查询的列全部包含在二级索引里，那就不需要回表了，这就是覆盖索引为什么快的本质原因。

# 假设这张表有 id、name、age 三个字段 # 这句会回表：idx_name 只包含 name 和主键，查 age 需要回表 SELECT id, name, age FROM user WHERE name = 'zhangsan'; # 这句不会回表：idx_name_age 包含 name、age、主键 # 查询列都在索引里 CREATE INDEX idx_name_age ON user(name, age); SELECT id, name, age FROM user WHERE name = 'zhangsan';

1.3 索引失效场景：为什么明明建了索引还是慢

面试里高频的场景题之一：给某列建了索引，但查询还是全表扫描，为什么？其实索引失效的本质是“优化器觉得走索引还不如全表扫描”，或者“你的写法让索引失去了有序性”。按踩坑频率排一下常见的失效场景：

第一，对索引列做了函数运算或隐式类型转换。比如WHERE DATE(create_time) = '2026-01-01'，这破坏了索引列本身的有序性，MySQL 只能放弃索引。正确写法是WHERE create_time >= '2026-01-01' AND create_time < '2026-01-02'。

第二，模糊匹配用了前导通配符，比如LIKE '%abc'，因为 B+ 树是严格按照前缀有序的，前缀不确定就只能全扫。

第三，联合索引不满足最左前缀原则。面试官最爱问的就是“建立了 (a, b, c) 索引，查询条件是b = ? AND c = ?，能不能走索引？”答案是不能，因为联合索引先按 a 排序，a 不确定时 b、c 的有序性无法利用。

第四，OR连接的条件里有一个没索引，整个查询可能都不走索引。第五，数据量本身很小或者优化器估算走索引代价更高，MySQL 会主动放弃索引，这种情况往往被初学者误判为“索引失效”。

我自己的习惯是分析这类问题时先打开EXPLAIN看一眼key、type、rows，而不是凭感觉猜。关于 EXPLAIN 的具体用法，后面会有一整部分展开。

1.4 实操心得：怎么设计一个真正低成本的索引

索引不是越多越好，每个索引都要占用磁盘空间，写入时还要维护 B+ 树的更新，索引一多写入性能就会下降。我在实际项目中给表加索引前会问自己四个问题：

这个查询的过滤性如何？如果某个字段只有两个取值（比如性别），选择性太差，加索引大概率没意义。查询的列能不能组成覆盖索引？写操作多不多？如果这张表每分钟几千次的 INSERT/UPDATE，索引数量必须克制。

最容易被忽略的一个经验：联合索引的顺序非常讲究。一般来说把等值查询的字段放前面，把排序字段放后面，高频查询优先。比如订单表经常按user_id等值过滤再按create_time排序，那建(user_id, create_time)远比(create_time, user_id)合理，前者一个索引就同时解决了过滤和排序。

另外，线上大表加索引不要在业务高峰期直接跑，MySQL 8.0 虽然支持 INPLACE 算法，但大批量 DDL 依然会引起主从延迟。常规做法是先在从库上加好验证，低峰期再切换，更稳妥的团队会走工具来减轻主库压力。

2. 事务隔离级别与 MVCC：快照读背后的可见性规则

事务这块是 MySQL 面试的另一座大山，而且往往和 Spring 事务、分布式事务的题目联动出现。面试官通常会从一个具体场景切入：两个会话同时更新同一行数据，会发生什么？你看到什么、更新什么、提交后对方能不能看到？这些问题的底层都是隔离级别和锁机制。

2.1 ACID 到底靠什么实现

背 ACID 四个特性的定义只是及格线，要知道每个特性背后对应的机制才算有深度。

原子性靠 undo log。事务里万一执行到一半失败了，MySQL 需要把已修改的数据回滚到事务开始前的状态，undo log 记录的就是旧值。持久性靠 redo log。每次数据页的修改不会立即刷盘，而是先写 redo log，即使实例崩溃，重启后也能通过 redo log 重放恢复，这就是 WAL（Write-Ahead Logging）机制。

一致性是应用层的概念，数据库层面通过约束、触发器以及原子性和隔离性共同保证。隔离性靠的是锁和 MVCC，也就是下面要展开的重点。

面试官如果追问“redo log 和 binlog 有什么区别”，记得抓住核心：redo log 是 InnoDB 引擎层的东西，记录的是物理页的修改，用于崩溃恢复；binlog 是 MySQL Server 层的逻辑日志，记录的是语句或行数据的变化，用于主从复制和数据归档。两者配合还引出了“两阶段提交”的概念，这在主从复制部分再展开。

2.2 四种隔离级别会踩到什么坑

MySQL 默认隔离级别是REPEATABLE READ（可重复读），这和 Oracle 默认的READ COMMITTED不一样，也是面试官喜欢埋坑的地方。

四种隔离级别分别解决的问题是：读未提交（READ UNCOMMITTED）会出现脏读；读已提交（READ COMMITTED）解决了脏读，但会出现不可重复读；可重复读（REPEATABLE READ）解决了不可重复读，但理论上还有幻读；串行化（SERIALIZABLE）最安全但并发性能最差。

关键在于：MySQL 的 InnoDB 在可重复读级别下，通过间隙锁和 MVCC 基本把幻读也解决了（对快照读而言），所以实际生产中可重复读就够用了。面试官如果问“那为什么很多互联网公司把隔离级别改成读已提交”，你可以回答：可重复读下间隙锁的锁定范围更大，在高并发写入场景下更容易出现锁冲突和死锁；读已提交只锁行不锁间隙，并发度更高，代价是可能出现不可重复读，但在大部分业务里这种副作用可以接受。

2.3 MVCC 的隐藏字段与 ReadView 规则

MVCC 全称是多版本并发控制，是 InnoDB 实现高并发读的核心机制。每行数据都有两个隐藏字段：trx_id（最近一次修改该行的事务 ID）和roll_pointer（指向 undo log 中该行旧版本的指针）。更新一行数据时，旧版本先写入 undo log，然后行上的trx_id替换成当前事务 ID。

查询的时候，每个事务会生成一个 ReadView，里面记录着“当前活跃事务的 ID 列表”和“创建该 ReadView 的事务 ID”。判断一行可见性的规则是：如果行的trx_id小于 ReadView 里最小的活跃事务 ID，说明这个版本在快照创建前就已提交，可见；如果大于最大的活跃事务 ID，说明这个版本是快照创建后产生的，不可见；如果落在中间，则看trx_id是否在活跃列表里，在则不可见，不在则可见。

这里有个高频追问：既然可重复读和读已提交都有 ReadView，那两者有什么区别？答案是：读已提交每次查询都会生成一个新的 ReadView，所以两次查询可能看到不同版本；可重复读只会在事务第一次查询时生成 ReadView，之后整个事务都复用同一个快照，自然就“可重复”了。

2.4 间隙锁与 next-key lock：幻读是怎么防住的

只聊 MVCC 不讲锁，面试官追问两句就会露馅。可重复读级别下，InnoDB 加锁时不仅锁住命中的行，还会锁住行之间的间隙，这就是间隙锁（Gap Lock）。间隙锁和行锁合起来叫 next-key lock（临键锁），锁定的范围是“左开右闭”的区间。

为什么需要间隙锁？假设订单表里金额在 100 到 200 之间的记录只有三条，事务 A 执行SELECT ... WHERE amount BETWEEN 100 AND 200 FOR UPDATE，事务 B 同时插入一条 amount = 150 的记录。如果只锁已有行，B 的插入就会成功，事务 A 再次查询时多出了一条“幻影”记录，这就是幻读。间隙锁把 100~200 这个范围锁住，B 的插入会被阻塞，从机制上杜绝了这类问题。

需要提醒的是，间隙锁本身只防止“插入”，不防止“更新”，所以它的粒度比行锁大得多，也是死锁的高发源头之一。互联网公司喜欢切读已提交，其中一个原因就是为了减少间隙锁带来的冲突。

2.5 死锁排查：从 show full processlist 到 kill

死锁几乎是业务场景必考，候选人如果能讲出一次真实排查经历会非常加分。实际判卷标准是：命令怎么用、怎么看结果、怎么处理。

死锁的经典场景是两条 SQL 按不同顺序加锁。比如事务 A 先锁 id=1 再锁 id=2，事务 B 先锁 id=2 再锁 id=1，双方互相等待，不出意外其中一个会被 InnoDB 检测到并回滚。

排查的第一步是用SHOW ENGINE INNODB STATUS查看最近一次死锁的详细信息，里面会给出两个事务的 SQL 和它们正在等待的锁对象。如果不想看大段输出，可以先SHOW FULL PROCESSLIST找一找有没有长时间Waiting for lock状态的会话，定位到可疑连接后确认业务来源，然后KILL <thread_id>释放资源。

我自己遇到过最典型的死锁场景是一个批量更新任务：程序用循环逐个更新记录，但列表是按主键升序排的，另一个定时任务却按某个二级索引的顺序批量更新，两条链路拿锁的顺序相反，在数据量大的时候频繁死锁。这类问题的解法不是单纯重试，而是统一加锁顺序，让所有事务都按同一顺序拿锁，可以从根本上消除大部分死锁。

3. 一条慢 SQL 的完整排查链路：EXPLAIN 里的每一列都别放过

索引和事务讲完，面试题开始转向实战：给你一条慢 SQL，你怎么定位、怎么优化？这一块最能区分“背题选手”和“真做过优化的人”。建议先把慢查询日志打开，再学会看执行计划，最后才是调 SQL 或加索引。

3.1 慢查询日志怎么配最省事

先给一个可以直接抄的配置：

-- 开启慢查询日志，超过 1 秒的 SQL 都会被记录 SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; -- 确认当前配置 SHOW VARIABLES LIKE 'slow_query_log%'; SHOW VARIABLES LIKE 'long_query_time';

生产环境更常见的做法是在配置文件my.cnf里配置slow_query_log = 1、long_query_time = 1，并且把log_queries_not_using_indexes打开，这样没有用索引的查询也会被记录下来，方便提前发现隐患。

这里有个实际操作中的坑：long_query_time的单位是秒，默认是 10 秒，很多小项目跑一年都记不到几条日志，根本起不到监控作用。我一般上线后先设成 1 秒跑一两天，低峰期再根据业务调整；同时要小心SET GLOBAL只对后续新建的连接生效，线上排查时最好用SET SESSION long_query_time = 0.1在当前会话里临时设置，免得影响全局配置。

3.2 EXPLAIN 的每一列都要会看

执行计划是定位慢查询的利器，但很多人只会看type和key，这就浪费了。我把最关键的字段列一张表：

面试官常问的两个陷阱：一是type = index看着是走了索引，但它扫的是整个索引树，性能未必比 ALL 好多少，比如对一个非索引列做统计时可能出现。二是Extra里有Using filesort，说明 MySQL 为了排序可能要额外消耗大量内存或临时文件，即使key不为空，这条 SQL 依然可能慢。

我见过一个真实案例：订单列表页按create_time倒序分页，WHERE user_id = ? ORDER BY create_time DESC，索引只建了(user_id)，于是走索引拿到了所有订单，但排序是文件排序。加了(user_id, create_time)联合索引之后，B+ 树本身就有序，排序环节直接消失，查询时间从 800 毫秒降到 20 毫秒。这就是为什么我总说“排序字段要进索引”。

3.3 分页查询为什么越翻越慢

分页深翻页是业务里最常见的一类慢查询。LIMIT 200000, 20看起来只是查 20 条，实际 MySQL 要先扫出前 200020 条再丢掉前 200000 条，扫描量巨大。优化的思路有两个方向：

如果查询条件允许，用“上一页最后一个主键”代替偏移量。比如列表页上一页最后的 id 是 185432，下一页就写成：

SELECT * FROM orders WHERE id > 185432 ORDER BY id ASC LIMIT 20;

这样每次查询都只扫 20 条，稳稳地走主键索引。

如果场景复杂、必须用偏移量分页（比如中间跳页），可以考虑延迟关联：先查LIMIT 200000, 20只取主键，再拿主键关联回原表取全字段，避免回表大量无关行：

SELECT o.* FROM orders o INNER JOIN ( SELECT id FROM orders ORDER BY create_time DESC LIMIT 200000, 20 ) t ON o.id = t.id;

子查询只扫主键索引，数据量小，再把 20 条主键带回原表查询，整体性能远好于直接大偏移量。

3.4 高频 SQL 细节：排序、UPDATE、字符串转日期

热词里出现了mysql排序、mysql update语法、mysql将字符串转为日期，这类细节题看着简单，却经常被笔试和面试官当作“基本功”抽查。

排序方面提醒一个点：ORDER BY 默认按升序，null 值的排序在不同数据库里表现不同，MySQL 里 null 默认排在最前面，想放到最后可以用ORDER BY create_time IS NULL, create_time ASC。

UPDATE 语法有一个容易踩坑的细节：UPDATE更新同一张表时子查询不能直接引用目标表，比如UPDATE t SET a = (SELECT MAX(a) FROM t)会报错You can't specify target table for update in FROM clause，需要先包一层临时子查询。

字符串转日期的高频写法是STR_TO_DATE('2026-03-15 10:30:00', '%Y-%m-%d %H:%i:%s')，反向的日期格式化用DATE_FORMAT。这里有个让我吃过亏的坑：字符串里日期格式如果含中文或空格与格式串不一致，转换结果是 NULL，而且不报错，排查起来非常隐晦。建议所有字符串转日期的操作都先单独验证一下输出，再放进业务 SQL。

4. InnoDB 与 MyISAM 之选：存储引擎背后的设计取舍

“MySQL 支持哪些存储引擎？InnoDB 和 MyISAM 有什么区别？”这是五年前的高频题，现在虽然大多数场景已经默认 InnoDB，但面试官依然喜欢拿出来考基础功底。原因在于通过对比，可以考察你知不知道一个存储引擎该考虑哪些维度：事务、并发、索引结构、崩溃恢复、外键、全文索引等。

4.1 两种引擎的能力对比

直接上一张对比表，方便记忆也方便面试时快速组织语言：

这里有个很经典的追问：为什么 InnoDB 比 MyISAM 适合高并发写入？回答的关键在锁粒度。MyISAM 的锁是表级锁，写入时整张表都锁住，读写互斥严重；InnoDB 支持行锁和 MVCC，读不会阻塞写，写可以通过多版本机制与读并行，并发度完全不在一个量级。

另一个隐藏考点是“InnoDB 表为什么必须有主键”。前面提过，InnoDB 聚簇索引基于主键组织数据，如果你不确定主键，系统也会生成隐藏主键，但隐藏主键对你不可见，回表和后续优化都会很别扭。所以建表的第一件事就是定一个业务主键或自增主键，不要偷懒。

4.2 InnoDB 的 Buffer Pool：为什么热数据查得快

问到存储引擎原理，Buffer Pool 是一个很好的加分项。InnoDB 对数据的读写并不是直接操作磁盘数据文件，而是通过内存缓冲池。读的时候先看数据页是否在 Buffer Pool，在就直接返回页；写的时候先修改内存里的页，再由后台线程异步刷盘，这样大部分操作在内存里完成，磁盘 IO 被极大减少。

Buffer Pool 的大小在 MySQL 8.0 里默认是物理内存的 75% 左右，生产环境通常建议设置在物理内存的 60%~70%，具体要看实际负载。如果设置过小，页被频繁换入换出，会出现大量的磁盘 IO 和 free pages 告警；如果过大，又可能挤压操作系统和其他进程的内存。

面试时可以主动提一下 LRU 回收策略：InnoDB 的 Buffer Pool 用改进版 LRU（大约 5/8 的区域被定义为“热区”，3/8 为“冷区”），新读入的页先进冷区，避免一次全表扫描把真正的热数据全部挤出内存。这个细节一说出来，面试官基本能把你和普通背题选手区分开。

4.3 auto_increment 锁：一个容易忽略的并发考点

auto_increment是建表时最常见的设置，但它的锁机制很多候选人没想过。InnoDB 对自增值的分配有三种锁模式，默认配置是innodb_autoinc_lock_mode = 2（交错模式）。这个模式下，插入语句执行时不会锁表，并发插入的自增值可能不连续，但性能最好。

如果面试官问“批量插入时会不会把表锁住”，得分情况回答：对于无法提前确定插入行数的语句（比如INSERT ... SELECT），即使锁模式是 2，仍然可能使用表级 AUTO-INC 锁保证生成的自增值连续，代价是这个语句执行期间其他插入只能等待。所以大事务里尽量避免混合使用不同类型的插入语句，不然容易出现自增值空洞和偶发的等待。

4.4 实际项目里怎么选型

虽然教材里列了很多引擎，但以我现在的观点，新业务直接无脑 InnoDB 就行，除非你明确需要 MyISAM 的某些特性。比如早期版本的全文索引在 MyISAM 上支持更好，但对于新项目，MySQL 8.0 的 InnoDB 已经原生支持全文索引，MyISAM 的最后一个优势也没了。

还有一个从运维角度容易忽视的点：MyISAM 在崩溃后往往需要REPAIR TABLE才能恢复，而且有可能损坏数据；InnoDB 可以通过 redo log 自动恢复。在数据价值越来越高的今天，选 MyISAM 的隐性成本很难接受。如果面试官问“你线上用过别的引擎吗”，最好能讲出“因为什么场景考虑过、最后为什么放弃”的完整决策过程，这才是真正的加分项。

5. 主从复制的三个坑：延迟、丢数据与同步异常

凡是简历上写了“负责订单/交易系统”的候选人，主从复制几乎是必考，因为单机数据库总有性能瓶颈，生产环境普遍走“一主多从 + 读写分离”。热词里也有“怎么使用 mysql 主从复制、把远程库的这张表同步到本地”这类检索，说明大家在实操中确实遇到不少问题。

5.1 一条数据的复制全链路

主从复制的原理很简单，但很多人答不全链路。可以按一条 INSERT 语句的旅程来拆解：

主库写入时，事务提交前会写 binlog（二进制日志）；从库的 IO 线程去主库拉取 binlog，写到从库本地的 relay log（中继日志）；从库的 SQL 线程读 relay log，在从库上按顺序回放。只要两个线程工作正常，主从数据就能保持一致。

有几个关键词值得展开：binlog 有STATEMENT、ROW、MIXED三种格式。MySQL 5.7.7 之后默认是ROW格式，记录的是每一行的变化，虽然日志量更大，但复制更安全，尤其是遇到 UUID、NOW() 这类非确定性函数时，ROW 格式不会出现两边结果不一致的问题。面试官问到“为什么推荐 ROW 格式”，建议从这个角度切入。

5.2 异步、半同步与组复制：丢数据的分寸

主从复制最怕的不是延迟，而是丢数据。默认的主从复制是异步的：主库提交事务后立刻返回成功，binlog 还在内存里，从库还没来得及拉走，主库如果宕机，这部分数据就丢了。

半同步复制解决了部分问题：主库在提交事务后必须等待至少一个从库确认收到 binlog 才能返回成功，这样主库宕机时，至少有一个从库还有数据，丢失的概率大幅降低。代价是主库的写入延迟会增加，因为多了“等待从库确认”这一步。组复制（Group Replication）更进一步，通过 Paxos 共识协议在多个节点间达成一致，适合对数据一致性要求极高的场景，但配置和运维复杂度也要高不少。

面试时被问到“能不能接受丢失数据”，不要直接答“不能”或“能”，而要区分场景：核心交易数据必须开半同步或组复制，日志、报表这类可容忍少量丢失的数据可以用异步复制换取性能。这种有取舍的回答比单纯背书要立体得多。

5.3 主从延迟的排查与处理

延迟是主从复制最常见的实际故障。排查之前先看从库状态：

SHOW SLAVE STATUS\G -- 重点看两个字段 -- Seconds_Behind_Master：主从延迟的秒数 -- Slave_IO_Running / Slave_SQL_Running：必须都显示 Yes

Seconds_Behind_Master越大说明从库回放越慢。常见原因有这几种：从库硬件性能不如主库；从库上还有一堆分析型大查询在抢资源；主库的写入并发太高，从库单线程 SQL 线程回放不过来。针对最后一个原因，MySQL 5.7 之后可以从库开启并行复制（slave_parallel_workers），让多个线程并行回放不同库/不同事务的 binlog。

实际项目里还有一类“伪延迟”：从库长时间没有收到任何新事务，Seconds_Behind_Master的值反而会很大，但这不代表复制出问题了，只是算出来的时间差。所以排查延迟不能只看一个指标，要结合 binlog 位点、从库当前正在执行的 SQL 以及主库的写入情况综合判断。

5.4 实操：远程到本地的表同步怎么做

回到热词里“把远程库的这张表同步到本地”这个具体诉求。如果说的是一次性同步，最简单的思路是用 mysqldump：

# 在本地执行：把远程主库的 order_db 库的 orders 表导出到本地文件 mysqldump -h 远程主机IP -u用户名 -p密码 order_db orders > orders.sql # 再将 SQL 导入本地库 mysql -h 127.0.0.1 -u用户名 -p密码 local_db < orders.sql

注意几个细节：mysqldump导出时最好指定--single-transaction，这样在 InnoDB 下可以获得一致性快照，不会锁住线上表；如果只是想要表结构不要数据，加-d参数；表比较大时可以加--where="id > 100000"分批导出。

如果说是持续同步，那就得进入主从复制或者用工具做增量同步。最简单的是从库订阅主库 binlog，但需要先在主库开启log_bin和设置server_id，然后通过CHANGE MASTER TO配置主从关系。更轻量的方案是用 Canal、Debezium 这类工具解析 binlog，把数据写进本地消息队列再落到目标库，适合业务侧需要过滤转换的场景。

5.5 数据一致性校验：主从对账怎么做

主从复制跑久了，难免出现个别不一致。有一些团队信奉“从库不可恢复就重建”，但大多数业务还是需要先做一次对账。常用的工具有pt-table-checksum，它可以对主从库的表做差量校验，找出不一致的行，然后用pt-table-sync修复。如果公司不允许引入额外工具，可以自己写脚本对核心表做哈希对比，但注意不要在业务高峰期跑，因为校验本身也会占用从库资源。

6. 存储过程、触发器与查询细节：容易被问懵的边角考点

最后一章聚焦一些看似冷门、但面试官经常用来“补刀”的知识点。这类题的特点是：答得出来不能说明你多强，答不出来却很容易暴露短板。热词里专门有mysql存储过程、mysql声明存储过程、mysql中触发器中分隔符等检索，说明关注的人并不少。

6.1 存储过程的声明与 delimiter 之谜

存储过程其实就是在数据库端保存的一段预编译 SQL。声明一个最简单的存储过程：

DELIMITER // CREATE PROCEDURE get_user_orders(IN user_id INT) BEGIN SELECT * FROM orders WHERE user_id = user_id; END // DELIMITER ;

新手最容易卡在DELIMITER上。MySQL 客户端默认用分号作为一条语句的结束符，而存储过程体里又有大量分号，如果客户端还在用默认分隔符解析，CREATE PROCEDURE就会被截断。所以用DELIMITER //把结束符临时改成//，等存储过程完整创建完再改回DELIMITER ;。

面试时如果被问到“存储过程有什么优缺点”，建议用结构化方式回答：优点是减少网络往返、封装复杂逻辑、批量处理方便；缺点是难以调试、版本管理麻烦、存储过程内逻辑过于复杂时会成为性能隐患，而且分布式架构下数据库层承担太多业务逻辑并不合适。这里要展现的是“知道什么时候不该用”，而不是一味推荐。

6.2 触发器与事件调度器：用之前先想清楚

触发器（Trigger）是在 INSERT、UPDATE、DELETE 前后自动执行的一段逻辑。比如每次更新订单状态时自动写一条历史记录，听起来很方便。但触发器最大的问题是隐式执行：排查问题时，执行一条 UPDATE 却发现别的表也被改了，复盘成本很高。我用过几次后，除非是很小很简单的项目，否则更倾向把这类逻辑放到业务代码里，或者用事件调度器定时扫表处理。

事件调度器（Event Scheduler）有点像数据库内置的定时任务：

-- 开启调度器 SET GLOBAL event_scheduler = ON; -- 每天凌晨 2 点清空临时表 CREATE EVENT clean_temp_table ON SCHEDULE EVERY 1 DAY STARTS '2026-01-01 02:00:00' DO DELETE FROM temp_table WHERE create_time < NOW() - INTERVAL 7 DAY;

这里的坑是：事件调度器依赖 MySQL 实例持续运行，实例重启后如果没有把event_scheduler写进配置文件，事件不会自动启用。另外，跨时区的项目要特别留意事件里用的时间函数，避免任务在三更半夜执行。

6.3 UNION 与 UNION ALL：一字之差性能悬殊

这是 SQL 细节题里出镜率非常高的一题。UNION ALL只是把两个查询的结果简单合并，不做去重；UNION在合并之后还会做一次去重排序，代价是额外消耗内存和临时表。如果业务上确定不会有重复行，一定用UNION ALL。

类似容易被忽略的还有GROUP BY+HAVING的顺序：WHERE先过滤行，GROUP BY再分组，HAVING在分组之后过滤组。能用WHERE过滤的尽量在WHERE阶段解决，否则HAVING阶段要处理的数据量会大很多。

还有一个细节题是COUNT(*)和COUNT(1)哪个快，这个题在 MySQL 8.0 里答案已经统一：做过优化后两者基本没有差别，不要在这个点上浪费太多时间。更值得聊的是COUNT(字段)会跳过 NULL，如果字段上有 NULL 值，统计结果会不一样，这在做报表时是个隐蔽的坑。

6.4 数据库连接池：翻车的往往是参数

热词里出现了“mysql的数据库连接池”，这题主要考察生产经验。连接池的作用是复用连接，减少频繁创建/销毁连接的开销，常见实现有 HikariCP、Druid、C3P0。HikariCP 是目前 Spring Boot 默认的，性能好，但参数需要按业务调。

最容易翻车的是maximumPoolSize设得过大或过小。很多团队照抄默认值，或者凭感觉设成 200、500，结果数据库连接数被打满，反而出现连接等待。我的建议是：连接池大小不是越大越好，每个连接背后都是一个数据库会话，占用内存和锁资源。一般中低并发项目从 20 开始，配合压测去调整，而不是一上来拉满。另外一个常见问题是连接泄漏——代码里没close()，连接池被借空，应用就卡死。排查这类问题可以从连接池监控里看Active连接数和活跃线程时间，也可以开 SQL 审计定位是哪段代码长时间占用连接。

这一类“边角考点”在面试评分上权重不算高，但一旦连着答错两三道，面试官对基础功底的判断就会明显下滑。所以还是建议花半小时把这块过一遍。

最后分享一点我自己的体会。面试题整理得再多，如果不去动手开一个 MySQL 实例实际验证，很多结论你心里是虚的。我从开始带团队以后，一直要求候选人回答数据库问题时给出“你亲眼验证过的实验结果”，而不是“网上都这么说”。比如隔离级别这块，自己开两个会话跑一遍，比背十篇博客都有用。准备面试的核心不是把答案塞满脑子，而是建立一套“遇到问题能自己查、能自己推演”的思维习惯，这也是这份清单存在的意义——把路标给你，但路还得自己走。