【MySQL面试题】—— MySQL面试高频问题汇总：从原理到实战，覆盖90%考点

MySQL面试高频问题汇总：从原理到实战，覆盖90%考点

前言

MySQL 是后端 / 中间件面试的「必考题」，尤其是索引、事务、MVCC、锁、性能优化这些核心知识点，面试官往往会追问细节（比如我之前被反复问 MVCC 的 ReadView 创建场景）。这篇博客整理了面试中最常被问到的 MySQL 问题，结合实战场景拆解，帮你快速吃透考点。

---

一、索引相关（面试高频 TOP1）

1. 索引是什么？为什么需要索引？

• 通俗解释：索引就像书的目录，通过目录能快速找到对应章节，避免逐页翻阅（全表扫描）。

• 核心作用：减少磁盘 IO，提升查询效率；辅助排序 / 分组，避免文件排序。

• 面试官追问：索引的底层数据结构是什么？（答案：InnoDB 用 B+ 树，原因：平衡树结构、叶子节点链表有序、支持范围查询）

2. MySQL 索引失效的常见情况？

这是我之前面试被追问很久的题，整理了最全面的 8 种情况：

1. 索引字段使用函数 / 计算（如 WHERE YEAR(create_time) = 2024）；

2. 隐式类型转换（如字符串字段用数字查询：WHERE phone = 13800138000）；

3. % 开头的模糊查询（WHERE name LIKE '%张三'，xxx% 不会失效）；

4. 使用 NOT IN/!=/<>/OR（无索引时可能全表扫描）；

5. 联合索引不遵循「最左匹配原则」（如联合索引 (a,b,c)，查询 WHERE b=1 AND c=2 失效）；

6. 索引字段为 NULL（IS NULL 可能失效，建议用默认值替代 NULL）；

7. 用 SELECT * 查询多余字段（可能触发覆盖索引失效）；

8. 数据量过小（MySQL 优化器认为全表扫描比索引查询更快）。

3. like 查询会不会导致索引失效？

• 分情况讨论：

  • 会失效：WHERE col LIKE '%xxx'（前缀模糊匹配）；

  • 不会失效：WHERE col LIKE 'xxx%'（后缀模糊匹配）、WHERE col LIKE 'xxx%yyy'（中间模糊匹配，仅前缀有效）；

  • 特殊情况：覆盖索引场景下，%xxx 可能不失效（如索引包含查询字段，无需回表）。

---

二、事务与 MVCC（面试官最爱追问细节）

1. MySQL 的事务隔离级别有哪些？

• 按隔离级别从低到高排序（默认：Repeatable Read）：

1. 读未提交（Read Uncommitted）：能读取未提交的数据，存在脏读、不可重复读、幻读；

2. 读已提交（Read Committed）：只能读取已提交的数据，解决脏读，存在不可重复读、幻读；

3. 可重复读（Repeatable Read）：同一事务内多次查询结果一致，解决脏读、不可重复读，InnoDB 通过 MVCC 解决幻读；

4. 串行化（Serializable）：最高隔离级别，事务串行执行，无并发问题，但性能极差。

2. 什么是 MVCC？原理是什么？

• 通俗解释：MVCC（多版本并发控制）是 InnoDB 实现隔离级别的核心机制，通过「数据版本链 + ReadView」让不同事务看到不同版本的数据，实现并发读写不冲突。

• 核心原理：

1. 每行数据包含隐藏字段：DB_TRX_ID（事务 ID）、DB_ROLL_PTR（回滚指针，指向 undo log）；

2. 事务修改数据时，会生成新的数据版本，旧版本存入 undo log，通过回滚指针串联成版本链；

3. 事务读取数据时，生成 ReadView（一致性视图），判断数据版本是否可见：

• 若数据版本的 DB_TRX_ID 活跃事务 ID → 可见；

• 若 DB_TRX_ID 在 ReadView 活跃事务 ID 范围内 → 不可见，通过回滚指针找旧版本；

• 若 DB_TRX_ID > ReadView 中最大活跃事务 ID → 不可见（未提交事务修改）。

3. 具体场景：同一事务内多次查询，会创建几个 ReadView？

• 关键结论 ：Repeatable Read 隔离级别下，一个事务只创建一次 ReadView （事务启动时）；Read Committed 隔离级别下，每次查询都会创建新的 ReadView。

• 面试官举的场景示例：

  • 事务 A 启动（RR 隔离级别），查询数据得到版本 1；

  • 事务 B 修改数据并提交，生成版本 2；

  • 事务 A 再次查询，仍看到版本 1（因为 ReadView 未更新）；

  • 若为 RC 隔离级别，事务 A 第二次查询会创建新 ReadView，能看到版本 2。

---

三、锁相关（行锁、表锁、死锁）

1. InnoDB 的行锁和表锁有什么区别？

特性	行锁（InnoDB）	表锁（MyISAM/InnoDB）
锁定粒度	行级（细粒度）	表级（粗粒度）
并发性能	高（支持多事务同时操作不同行）	低（同一表只能一个事务写操作）
触发条件	索引查询时自动行锁，无索引时表锁	写操作（INSERT/UPDATE/DELETE）默认表锁
死锁风险	有（多事务交叉锁）	无
适用场景	读多写少、高并发	读多写少、低并发（如静态数据）

2. 什么是死锁？如何避免？

• 死锁定义：两个或多个事务互相持有对方需要的锁，导致都无法继续执行（如事务 A 锁行 1，要锁行 2；事务 B 锁行 2，要锁行 1）。

• 避免方案：

1. 统一事务锁申请顺序（如都按主键升序锁）；

2. 缩短事务执行时间（避免长事务持有锁）；

3. 避免批量操作同时锁定大量行；

4. 开启死锁检测（innodb_deadlock_detect = ON），超时自动回滚（innodb_lock_wait_timeout）。

---

四、性能优化（面试必问，结合项目实战）

1. MySQL 为什么会慢？核心原因有哪些？

• 按高频程度排序：

1. 索引问题：未建索引、索引失效、索引冗余（最常见）；

2. SQL 低效 ：SELECT *、JOIN 表过多、子查询嵌套过深、排序 / 分组无索引；

3. 事务与锁：长事务、锁竞争、死锁；

4. 配置不合理 ：innodb_buffer_pool_size 过小（缓存不足）、磁盘 IO 差（机械硬盘）；

5. 数据量过大：单表千万级以上未分库分表；

6. 并发问题：连接数耗尽、无连接池。

2. 如何优化 MySQL 性能？（从易到难）

（1）SQL 语句优化

• 杜绝 SELECT *，只查需要的字段；

• 优化 JOIN ：减少关联表数量，关联字段必须建索引，优先用 INNER JOIN；

• 避免 ORDER BY/GROUP BY 无索引（尽量让索引覆盖排序字段）；

• 批量操作替代单条操作（如 INSERT INTO ... VALUES (...),(...)）。

（2）索引优化

• 为查询条件、JOIN 字段、排序 / 分组字段建索引；

• 联合索引遵循「最左匹配」，高选择性字段放前面（如性别字段不适合单独建索引）；

• 定期删除冗余索引，重建碎片化索引（OPTIMIZE TABLE）。

（3）配置优化

• 增大 innodb_buffer_pool_size（建议物理内存的 50%-70%），缓存索引和数据；

• 使用 SSD 替代机械硬盘，分离数据文件和日志文件（redo log、binlog）；

• 开启连接池（如 Druid、HikariCP），合理设置 max_connections。

（4）架构层优化

• 读写分离：主库写、从库读，通过主从复制同步数据；

• 分库分表：单表数据量超千万时，按范围（时间）或哈希分表；

• 缓存热点数据：用 Redis 缓存高频查询数据（如商品详情、用户信息），减少数据库访问。

（5）诊断工具

• 开启慢查询日志（slow_query_log = ON），记录执行时间超过 long_query_time（默认 1 秒）的 SQL；

• 用 EXPLAIN/EXPLAIN ANALYZE 分析 SQL 执行计划，查看是否全表扫描、索引是否生效。

---

五、其他高频问题

1. 布隆过滤器的原理和应用场景？

• 原理：基于位图和哈希函数，快速判断元素是否存在于集合中（存在误判，不存在绝对准确）；

• 应用场景：MySQL 缓存穿透防护（先查布隆过滤器，不存在则直接返回，避免查数据库）、海量数据去重。

2. LRU 的原理和实现？

• 原理：最近最少使用算法，淘汰最久未使用的数据（如 InnoDB 缓冲池的页面置换）；

• 简单实现：用双向链表 + 哈希表，访问数据时移到表头，淘汰时删除表尾元素（时间复杂度 O (1)）。

---

总结

MySQL 面试核心围绕「索引、事务、MVCC、锁、性能优化」五大模块，面试官喜欢追问「原理 + 场景 + 实战优化」，建议结合自己的项目经历（比如我之前在 RAG 项目中用 MySQL 存储知识库元数据，做过索引优化）来回答，会更有说服力。