【2025】最新出炉的MySQL面试题（持续更新中）

get_metoo

已于 2025-03-19 10:53:32 修改

阅读量425

点赞数 5

文章标签： mysql 数据库

于 2025-03-08 23:28:57 首次发布

本文链接：https://blog.youkuaiyun.com/get_metoo/article/details/146124917

版权

1. MySQL的逻辑架构分为哪几层？各层的作用是什么？

考察点：MySQL架构理解
MySQL的逻辑架构分为三层：

连接层（Connector Layer）
- 负责客户端连接管理、身份认证、权限验证
- 维护线程池，处理并发连接请求
- 协议：支持JDBC/ODBC等通信协议
服务层（Server Layer）
- SQL接口：接收SQL命令，返回结果
- 解析器：语法解析，生成抽象语法树（AST）
- 优化器：生成执行计划，选择索引，优化JOIN顺序
- 查询缓存（8.x已移除）：缓存SELECT语句结果
存储引擎层（Storage Engine Layer）
- 插件式架构：InnoDB（默认）、MyISAM、Memory等
- 负责数据存储、索引管理、事务实现
- 与文件系统交互，管理数据文件（.ibd/.frm）

2. 什么是回表查询？如何避免回表?

考察点：索引原理与优化

回表查询：
当使用普通二级索引查询时，若所需字段未完全包含在索引中（非覆盖索引），需根据索引中的主键ID回到聚簇索引（主键索引）中查找完整数据行的过程。
避免方法：
1. 覆盖索引：确保查询字段都包含在索引中
```
-- 示例：创建(name, age)联合索引  
SELECT id, name, age FROM users WHERE name = 'Alice';  
```
2. 索引下推（ICP）：在存储引擎层过滤数据，减少回表次数
3. 聚簇索引设计：合理选择主键减少回表概率

3. CHAR和VARCHAR的区别是什么？使用场景有何不同?

考察点：数据类型选择

特性	CHAR	VARCHAR
存储方式	定长，未满用空格填充	变长，前缀记录长度
存储空间	固定分配（0-255字节）	实际长度+1/2字节长度前缀
存取效率	读写更快（无长度计算）	节省空间但稍慢
尾部空格	插入时自动补足，查询时去除	保留原始空格

使用场景：

CHAR：长度固定的短字符串（如MD5哈希值、状态码、邮编）
VARCHAR：长度变化较大的数据（如地址、描述文本）

4. MySQL的binlog、redo log、undo log分别有什么作用?

考察点：日志系统与事务机制

日志类型	作用	关键特性
Binlog	1. 主从复制数据同步 2. 数据恢复（逻辑日志）	- 服务层日志 - 三种格式：STATEMENT/ROW/MIXED
Redo Log	1. 崩溃恢复（物理日志） 2. 保证事务持久性	- InnoDB特有 - 循环写入 - WAL机制核心
Undo Log	1. 事务回滚 2. MVCC多版本控制	- 逻辑日志 - 存储旧版本数据 - 支持Read View

协同工作流程：
事务提交时：

写undo log保证回滚能力
写redo log（prepare状态）
写binlog
提交事务（redo log标记commit）

5. MySQL的查询执行流程是怎样的？

考察点：SQL执行流程理解

连接器：建立连接，验证权限，维持连接状态
查询缓存（8.0已移除）：检查是否命中缓存
解析器：
- 词法分析：识别SQL关键字
- 语法分析：生成语法树
优化器：
- 选择最优索引
- 决定JOIN顺序（如小表驱动大表）
- 生成执行计划（可通过EXPLAIN查看）
执行器：
- 调用存储引擎接口
- 根据执行计划逐步获取数据
存储引擎：
- InnoDB：通过B+树索引检索数据
- 返回数据到服务层
结果返回：格式化结果集，返回客户端

核心要点：

索引选择影响执行效率
优化器可能选择非预期执行计划（需强制索引）
Buffer Pool减少磁盘IO次数

6. InnoDB和MyISAM的区别是什么？如何选择？

考察：存储引擎特性

特性	InnoDB	MyISAM
事务支持	支持ACID事务	不支持事务
锁机制	行级锁	表级锁
崩溃恢复	通过双写缓冲、Redo Log保证数据一致性	依赖MyISAM表的检查修复
外键约束	支持	不支持
全文索引	支持（MySQL 5.6+）	支持
性能	适合高并发、写密集场景	读性能稍高，但写锁严重

选InnoDB：需要事务、行级锁、高并发、外键约束的场景。
选MyISAM：读多写少、不需要事务的场景（如日志统计），但需注意其表锁和崩溃恢复的局限性。

其它存储引擎：Memory，Archive，CSV

7. 为什么InnoDB选择B+树作为索引结构？

考察：索引数据结构
B+树在磁盘存储，查询，事务支持等方面都有比较显著的优势。

B+树适合磁盘存储：非叶子节点仅存键，单节点可以存储更对键，减少树的高度，降低IO次数。叶子节点通过指针形成有序链表，支持高效范围查询。
数据存储和索引统一，结合聚簇索引特性，主键索引的叶子节点直接存储行数据，减少回表查询。
合适的事务和锁机制，基于索引的行锁实现(select … for update)。B+树的有序性便于锁定范围。
节点分裂/合并机制保证增删效率，避免树退化为链表结构。

8. 什么是覆盖索引？如何利用覆盖索引优化查询？

考察：索引优化技巧
**覆盖索引：**当SQL查询的字段（SELECT、WHERE、ORDER BY）全部包含在一个索引中时，无需回表查询主键索引。

利用联合索引覆盖高频查询字段，查询结果避免回表
查询是仅查询需要的字段，避免全字段查询
利用主键索引天然覆盖特性
可以利用explain查看执行计划，优化索引
避免过度索引，联合索引注意最左前缀原则

9. 联合索引的最左前缀原则是什么？请举例说明

考察：索引设计原则
最左前缀原则指联合索引(a,b,c)的查询条件必须按顺序使用前导列，否则索引可能失效。设计联合索引时可以按照查询频率和区分度从左到右排列
where a=1 => 使用索引
where a=1 and b=2 => 使用索引
where a=1 and c=3 => 使用索引
where c=1 and a=3 => 依赖优化器重排可以使用索引
where b=2 => 索引失效