MySQL 八股文知识大全(面试+复习必备)

本文整理了 MySQL 最核心的八股文内容,涵盖范式、SQL 执行流程、存储引擎、索引、事务等各大模块,适合用于面试前复习与系统性学习。


1. 数据库三大范式

  • 第一范式(1NF):每一列必须是不可再分的原子项。
  • 第二范式(2NF):在 1NF 基础上,所有非主属性完全依赖于主键,而不是主键的一部分。
  • 第三范式(3NF):在 2NF 基础上,非主属性不依赖于其他非主属性。

2. 一条 SQL 的执行过程

  1. 连接器:建立连接、身份验证
  2. 查询缓存(MySQL 8.0 后废除)
  3. 解析器:生成语法树
  4. 优化器:选择最优执行计划
  5. 执行器:与存储引擎交互获取数据

3. 存储引擎对比

引擎特性描述
MyISAM不支持事务、外键,读性能好
Memory数据存储在内存中,性能高
InnoDB默认引擎,支持事务、行锁、崩溃恢复

4. 索引分类方式

  • 按数据结构:B+ Tree、Hash、Full-Text
  • 按物理存储:聚簇索引、非聚簇索引
  • 按字段特性:主键、唯一、普通、前缀索引
  • 按字段数量:单列、联合索引

5. 聚簇索引 vs 非聚簇索引

维度聚簇索引非聚簇索引
存储结构叶子节点存储完整数据叶子节点存储主键值指针
查询性能查询快,避免回表覆盖索引快,非覆盖需回表
唯一性每表仅一个可有多个
适用场景范围/排序查询精确查找

6. 如何选择主键

  • 字段唯一,不能为空
  • 建议使用递增 ID,避免页分裂
  • 避免使用业务字段
  • 分布式系统建议用雪花 ID

7. 索引实现原理

  • InnoDB 使用 B+Tree 结构
  • 非叶子节点存索引,叶子节点存数据
  • 叶子节点通过双向链表连接
  • 查询效率高,I/O 次数少(3~4次)

8. B+Tree 的特点

  • 所有数据在叶子节点
  • 非叶子节点只存键值
  • 叶子节点双向链表连接,适合范围查询
  • 高度小,查询快

9. B+Tree、BTree、Hash 对比

项目B+ TreeB TreeHash
范围查询支持不便不支持
查询稳定性稳定不稳定高效(仅等值)
适用场景大量数据中等复杂度查询精确查找(非范围)

10. 索引失效的常见场景

  • 使用 %xx%xx% 模糊查询
  • 索引字段上使用函数或表达式
  • 字符串字段与数字比较(类型转换)
  • 联合索引不满足最左前缀法则
  • WHERE 子句含 OR 且部分字段无索引

11. 索引优缺点

优点: 提高查询速度

缺点:

  • 占用空间
  • 增删改性能降低
  • 索引维护成本高

12. 索引优化建议

  • 使用前缀索引减小索引项
  • 利用覆盖索引避免回表
  • 自增主键插入效率高
  • 联合索引遵循最左匹配原则
  • 避免函数、类型转换、模糊查询等导致索引失效

13. 事务四大特性 ACID

特性含义实现方式
原子性要么全做,要么全不做undo log
一致性满足数据完整性约束ACID 整体保障
隔离性并发事务互不干扰MVCC / 锁机制
持久性提交的数据永久保存redo log

14. 并发问题与事务隔离级别

问题类型解释出现级别
脏读读到未提交事务的数据读未提交
不可重复读同一事务两次查询结果不同读未提交、读已提交
幻读查询结果数量不一致可重复读以下级别

事务隔离级别:

  • Read Uncommitted
  • Read Committed
  • Repeatable Read(MySQL 默认)
  • Serializable

15. MVCC 实现原理

  • 多版本控制,读取旧版本数据
  • 使用版本链结构控制可见性
  • 非阻塞读,适合高并发

16. 锁的分类

  • 全局锁:如 flush tables with read lock
  • 表级锁:表锁、元数据锁、意向锁
  • 行级锁:记录锁、间隙锁、临键锁(Next-Key Lock)

17. 表锁 vs 行锁

特性表锁行锁
粒度粗,锁住整个表精确,锁住具体记录
并发性
应用场景批量操作、表结构修改单行读写操作

18. MySQL 日志类型

  • redo log:物理日志,持久性保障
  • undo log:回滚用,原子性保障
  • binlog:逻辑日志,备份与主从复制
  • relay log:从库同步日志
  • 慢查询日志:记录慢 SQL

19. Redo Log 的作用

  • 采用 WAL 机制:先记录日志,再写磁盘
  • 顺序写入优化性能
  • 宕机后可用于恢复已提交数据

20. 提升查询性能的方法

  1. 优化 SQL 语句写法
  2. 合理使用索引
  3. 避免索引失效
  4. 使用 EXPLAIN 分析执行计划
  5. 数据分页优化(如延迟加载)
  6. 表结构合理设计
  7. 利用缓存(如 Redis)降低数据库压力

欢迎点赞 + 收藏 + 评论交流!

如果你觉得这篇总结有帮助,别忘了关注我获取更多干货内容~

### 关于 MySQL 常见面试问题及答案 #### 获取 MySQL 版本 为了确认正在使用的数据库管理系统版本,可以执行如下 SQL 查询语句来获取当前 MySQL 的版本信息: ```sql SELECT VERSION(); ``` 这条命令返回的结果会显示具体的 MySQL 版本号以及其他可能的信息,比如编译选项或者操作系统平台等[^3]。 #### 数据类型的选择与特性 在设计表结构时,合理选择数据类型对于性能优化至关重要。以下是几种主要的数据类型的概述: - **数值类型**:适用于存储整数和浮点数。常见的数值类型包括 `TINYINT`、`SMALLINT`、`MEDIUMINT`、`INT` 或者 `BIGINT` 以及用于表示实数的 `FLOAT` 和 `DOUBLE` 类型。 - **字符类型**:用来保存字符串数据。其中 `CHAR(n)` 是固定长度的字符集,而 `VARCHAR(n)` 则允许变长字符串;这里的 n 表示最大字符数量而非字节数量。当字段的实际内容小于定义的最大长度时,`CHAR` 总是占用固定的存储空间,相反地,`VARCHAR` 只会在实际需要的时候分配相应的内存大小[^4]。 - **日期时间类型**:处理时间和日期相关的值。例如 `DATE` 存储年月日,`TIME` 记录具体时刻,还有组合形式如 `DATETIME` 和 `TIMESTAMP` 能够同时记录完整的日期加小时分钟秒毫秒级别的时间戳。 #### CHAR 和 VARCHAR 的差异 两者都是用来储存文本串,但是它们之间存在显著的区别在于存储方式上有所不同。`CHAR` 定义了一个定长的空间给每一个条目,即使该条目的真实内容不足指定宽度也会被填充至满额;相比之下,`VARCHAR` 提供了一种更灵活的方式——它只保留真正所需的空间加上额外的一个或两个字节去标记实际长度,因此更加节省资源,在大多数情况下推荐优先考虑使用 `VARCHAR` 来代替 `CHAR`。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值