【面试题】MySQL常见面试题合集，java中高级面试题总结

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

FROM

<left_table> <join_type>

JOIN

<right_table> ON <join_condition>

WHERE

<where_condition>

GROUP BY

<group_by_list>

HAVING

<having_condition>

ORDER BY

<order_by_condition>

LIMIT

<limit_params>

执行顺序：

4.说说MySQL中的数据类型有哪些？

---

大致可以分为四类：

1. 整数

TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT分别占用8、16、24、32、64位存储空间。

2. 浮点数

FLOAT、DOUBLE及DECIMAL为浮点数类。

• DECIMAL是利用字符串进行处理的，能存储精确的小数。相比于FLOAT和DOUBLE，DECIMAL的效率更低些。

• FLOAT、DOUBLE及DECIMAL都可以指定列宽，例如FLOAT(5,2)表示一共5位，两位存储小数部分，三位存储整数部分。

3. 字符串

字符串常用的主要有CHAR和VARCHAR

4. 日期

比较常用的有year、time、date、datetime、timestamp等

👩‍💻面试官追问：详细说一下MySQL中char 和 varchar 的区别？

• char∶固定长度类型，比如︰订阅char(10)，当你输入"abc"三个字符的时候,它们占的空间还是10个字节，其他7个是空字节。

• 优点∶效率高

• 缺点∶占用空间

• 适用场景︰存储密码的md5值，固定长度的，使用char非常合适

• varchar︰可变长度，存储的值是=每个值占用的字节+一个用来记录其长度的字节的长度

从空间上考虑varchar比较合适。从效率上考虑char比较合适，二者使用需要权衡。

表格对比：

| 对比项 | char | varchar |

| — | — | — |

| 长度特点 | 长度固定，存储字符 | 长度可变，存储字符 |

| 长度不足情况 | 插入的长度小于定义长度时，则用空格填充 | 小于定义长度时，按实际插入长度存储 |

| 性能 | 存取速度比varchar快得多 | 存取速度比char慢得多 |

| 使用场景 | 适合存储很短的，固定长度的字符串，如手机号，MD5值等 | 适合用在长度不固定场景，如收货地址，邮箱地址等 |

👩‍💻面试官继续问：详细说一下MySQL中字段类型DATETIME 和 TIMESTA的区别？

| 类型 | 占据字节 | 范围 | 时区问题 |

| — | — | — | — |

| datetime | 8 字节 | 1000-01-01 00:00:00到 9999-12-31 23:59:59 | 存储与时区无关，不会发生改变 |

| timestamp | 4 字节 | 1970-01-01 00:00:01 到 2038-01-19 11:14:07 | 存储的是与时区有关，随数据库的时区而发生改变 |

应该尽量使用timestamp，相比于datetime它有着更高的空间效率

5.说下InnoDB 和 MyISAM 的区别？

---

| 对比 | InnoDB | MyISAM |

| — | — | — |

| 事务 | 支持 | 不支持 |

| 锁类型 | 行锁、表锁 | 表锁 |

| MVCC | 支持 | 不支持 |

| 外键 | 支持 | 不支持 |

| 索引 | 聚簇索引、5.7以后支持全文索引 | 非聚簇索引、支持全文索引 |

| 安全性 | 支持数据库异常崩溃后的安全恢复 | 不支持 |

| 缓存 | 仅缓存索引，还缓存真实数据，对内存要求较高 | 只缓存索引，不缓存真实数据 |

| 备份 | InnoDB 支持在线热备份 | 不支持 |

👩‍💻面试官追问：平时选择存储引擎的时候这两个怎么取舍？

• InnoDB

是Mysql的默认存储引擎，用于事务处理应用程序，支持外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询意外，还包含很多的更新、删除操作，那么InnoDB存储引擎是比较合适的选择。对于类似于计费系统或者财务系统等对数据准确性要求比较高的系统，InnoDB是最合适的选择。

• MyISAM

如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择MyISAM存储引擎是非常合适的

6.什么是Buffer Pool？

---

• Buffer Pool 是 InnoDB 维护的一个缓存区域，用来缓存数据和索引在内存中，主要用来加速数据的读写，如果 Buffer Pool 越大，那么 MySQL 就越像一个内存数据库，默认大小为 128M。

• InnoDB 会将那些热点数据和一些 InnoDB 认为即将访问到的数据存在 Buffer Pool 中，以提升数据的读取性能。

• InnoDB 在修改数据时，如果数据的页在 Buffer Pool 中，则会直接修改 Buffer Pool，此时我们称这个页为脏页，InnoDB 会以一定的频率将脏页刷新到磁盘，这样可以尽量减少磁盘I/O，提升性能。

索引篇

============================================================

1.谈谈你对索引的理解？

---

索引是一种用于快速查询和检索数据的数据结构。常见的索引结构有: B 树， B+树和 Hash。

索引的作用就相当于目录的作用。打个比方：我们在查字典的时候，如果没有目录，那我们就只能一页一页的去找我们需要查的那个字，速度很慢。如果有目录了，我们只需要先去目录里查找字的位置，然后直接翻到那一页就行了。

👩‍💻面试官追问：说说索引的优缺点？

优点 ：

• 使用索引可以大大加快数据的检索速度（大大减少检索的数据量）, 这也是创建索引的最主要的原因

• 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性

缺点 ：

• 从时间角度考虑。创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低 SQL 执行效率

• 从空间角度考虑。索引需要使用物理文件存储，也会耗费一定磁盘空间

👩‍💻面试官继续问：说说哪些情况适合建立索引哪些不适合？

适合建立索引：

• 在最频繁使用的、用以缩小查询范围的字段上建立索引

• 在频繁使用的、需要排序的字段上建立索引

不适合建立索引的情况：

• 对于查询中很少涉及的列或者重复值比较多的列，不宜建立索引

• 对于一些特殊的数据类型，不宜建立索引，比如︰**文本字段(text)**等

2.说一下索引有哪些类型？

---

• 主键索引

数据表的主键列使用的就是主键索引。一张数据表有只能有一个主键，并且主键不能为 null，不能重复。

• 唯一索引(Unique Key)

唯一索引也是一种约束。唯一索引的属性列不能出现重复的数据，但是允许数据为 NULL，一张表允许创建多个唯一索引。 建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性，而不是为了查询效率。

• 普通索引(Index)

普通索引的唯一作用就是为了快速查询数据，一张表允许创建多个普通索引，并允许数据重复和 NULL。

• 前缀索引(Prefix)

前缀索引只适用于字符串类型的数据。前缀索引是对文本的前几个字符创建索引，相比普通索引建立的数据更小， 因为只取前几个字符。

• 全文索引(Full Text)

全文索引主要是为了检索大文本数据中的关键字的信息，是目前搜索引擎数据库使用的一种技术。（Mysql5.6 之前只有 MYISAM 引擎支持全文索引，5.6 之后 InnoDB 也支持了全文索引）

其中唯一索引、普通索引、前缀索引、全文索引又称为二级索引（辅助索引）

3.说下MySQL的索引有哪些？

---

• B+Tree 索引

• 是大多数 MySQL 存储引擎的默认索引类型。

• 哈希索引

• 哈希索引能以 O(1) 时间进行查找，但是失去了有序性。

• InnoDB 存储引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就让 B+Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。

• 全文索引

• MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较是否相等。查找条件使用 MATCH AGAINST，而不是普通的 WHERE。

• 全文索引一般使用倒排索引实现，它记录着关键词到其所在文档的映射。

• InnoDB 存储引擎在 MySQL 5.6.4 版本中也开始支持全文索引。

• 空间数据索引

• MyISAM 存储引擎支持空间数据索引(R-Tree)，可以用于地理数据存储。空间数据索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。

InnoDB、MyISAM、Memory三种存储引擎对各种索引类型的支持：

| 索引 | InnoDB引擎 | MyISAM引擎 | Memory引擎 |

| — | — | — | — |

| B+Tree 索引 | 支持 | 支持 | 支持 |

| 哈希索引 | 不支持 | 不支持 | 支持 |

| 空间数据索引 | 不支持 | 支持 | 不支持 |

| 全文索引 | 5.6版本之后支持 | 支持 | 不支持 |

4.说说什么是B+树？

---

1. B+树是基于B树和叶子节点顺序访问指针进行实现，它具有B树的平衡性，并且通过顺序访问指针来提高区间查询的性能

2. 进行查找操作时，首先在根节点进行二分查找，找到一个key所在的指针，然后递归地在指针所指向的节点进行查找。直到查找到叶子节点，然后在叶子节点上进行二分查找，找出key所对应的data

3. 插入、删除操作会破坏平衡树的平衡性，因此在插入删除操作之后，需要对树进行一个分裂、合并、旋转等操作来维护平衡性

👩‍💻面试官追问：那你说说B 树和B+树两者有何异同呢？

B树结构图：

可以看出：

• B 树的所有节点既存放键(key) 也存放数据(data)，而 B+树只有叶子节点存放 key 和 data，其他内节点只存放 key。

• B 树的叶子节点都是独立的，B+树的叶子节点有一条引用链指向与它相邻的叶子节点。

• B 树的检索的过程相当于对范围内的每个节点的关键字做二分查找，可能还没有到达叶子节点，检索就结束了。而 B+树的检索效率就很稳定了，任何查找都是从根节点到叶子节点的过程，叶子节点的顺序检索很明显。

👩‍💻面试官追问：为什么MySQL数据库要用B+树存储索引？而不用红黑树、Hash、B树？

• 红黑树

如果在内存中，红黑树的查找效率比B树更高，但是涉及到磁盘操作，B树就更优了。因为红黑树是二叉树，数据量大时树的层数很高，从树的根结点向下寻找的过程，每读1个节点，都相当于一次IO操作，因此红黑树的I/O操作会比B树多的多。

• hash 索引

如果只查询单个值的话，hash 索引的效率非常高。但是 hash 索引有几个问题：①不支持范围查询 ②不支持索引值的排序操作 ③不支持联合索引的最左匹配规则。

• B树索引

• B树索相比于B+树，在进行范围查询时，需要做局部的中序遍历，可能要跨层访问，跨层访问代表着要进行额外的磁盘I/O操作

• B树的每个节点都存储数据，而B+树只有叶子节点才存储数据，所以查找相同数据量的情况下，B树的高度更高，IO更频繁。

• 以页为单位读取使得一次 I/O 就能完全载入一个节点，且相邻的节点也能够被预先载入；所以数据放在叶子节点，本质上是一个Page页

👩‍💻面试官继续追问：B+树中一个节点到底多大合适？

1页或页的倍数最为合适。因为如果一个节点的大小小于1页，那么读取这个节点的时候其实也会读出1页，造成资源的浪费。所以为了不造成浪费，所以最后把一个节点的大小控制在1页、2页、3页等倍数页大小最为合适。

这里说的“页”是 MySQL 自定义的单位（和操作系统类似），MySQL 的 Innodb 引擎中1页的默认大小是16k，可以使用命令SHOW GLOBAL STATUS LIKE 'Innodb_page_size' 查看。

5.谈谈聚集索引与非聚集索引？

---

• 聚集索引：即索引结构和数据一起存放的索引。主键索引属于聚集索引

在 Mysql 中，InnoDB 引擎的表的 .ibd文件就包含了该表的索引和数据，对于 InnoDB 引擎表来说，该表的索引(B+树)的每个非叶子节点存储索引，叶子节点存储索引和索引对应的数据

• 非聚集索引：即索引结构和数据分开存放的索引。二级索引属于非聚集索引

MYISAM 引擎的表的.MYI 文件包含了表的索引， 该表的索引(B+树)的每个非叶子节点存储索引， 叶子节点存储索引和索引对应数据的指针，指向.MYD 文件的数据。

如图：

如上图，主键索引的叶子节点保存的是真正的数据。而辅助索引叶子节点的数据区保存的是主键索引关键字的值

假如要查询name = C 的数据，其搜索过程如下：

1. 先在辅助索引中通过C查询最后找到主键id = 9

2. 在主键索引中搜索id为9的数据，最终在主键索引的叶子节点中获取到真正的数据。所以通过辅助索引进行检索，需要检索两次索引

之所以这样设计，一个原因就是：如果和MyISAM一样在主键索引和辅助索引的叶子节点中都存放数据行指针，一旦数据发生迁移，则需要去重新组织维护所有的索引

👩‍💻面试官追问：聚集索引的优缺点有哪些？

• 聚集索引的优点

聚集索引的查询速度非常的快，因为整个B+树本身就是一颗多叉平衡树，叶子节点也都是有序的，定位到索引的节点，就相当于定位到了数据。

• 聚集索引的缺点

1. 依赖于有序的数据

因为 B+树是多路平衡树，如果索引的数据不是有序的，那么就需要在插入时排序，如果数据是整型还好，否则类似于字符串或 UUID 这种又长又难比较的数据，插入或查找的速度肯定比较慢

2. 更新代价大

如果对索引列的数据被修改时，那么对应的索引也将会被修改， 而且聚集索引的叶子节点还存放着数据，修改代价肯定是较大的， 所以对于主键索引来说，主键一般都是不可被修改的

👩‍💻面试继续问：非聚集索引的优缺点有哪些？

• 非聚集索引的优点

更新代价比聚集索引要小 。非聚集索引的更新代价就没有聚集索引那么大了，非聚集索引的叶子节点是不存放数据的

• 非聚集索引的缺点

1. 跟聚集索引一样，非聚集索引也依赖于有序的数据

2. 可能会二次查询(回表)。这应该是非聚集索引最大的缺点了。 当查到索引对应的指针或主键后，可能还需要根据指针或主键再到数据文件或表中查询

👩‍💻面试继续追问：非聚集索引一定回表查询吗？

不一定，原因详细看下面第6问

6.说一下什么是覆盖索引？

---

覆盖索引：指的是在一次查询中，如果一个索引包含或者说覆盖所有需要查询的字段的值，我们就称之为覆盖索引，而不再需要回表查询

覆盖索引即需要查询的字段正好是索引的字段，那么直接根据该索引，就可以查到数据了， 而无需回表查询。

举个栗子：

• 如主键索引，如果一条 SQL 需要查询主键，那么正好根据主键索引就可以查到主键。

• 再如普通索引，如果一条 SQL 需要查询 name，name 字段正好有索引， 那么直接根据这个索引就可以查到数据，也无需回表。

事务篇

============================================================

1.聊聊什么是事务？

---

事务是用户定义的一个数据库操作序列，这些操作要么全不做，要么全做，是一个不可分割的工作单位。

举个栗子：就拿最经典的转账例子来说，假如小明要给小红转账1000元，这个转账会涉及到两个关键操作就是：将小明的余额减少1000元，将小红的余额增加1000元。万一在这两个操作之间突然出现错误比如银行系统崩溃，导致小明余额减少而小红的余额没有增加，这样就不对了。事务就是保证这两个关键操作要么都成功，要么都要失败。

2.说说事务的ACID特性？

---

1. 原子性（Atomicity）

事务是最小的执行单位，不允许分割。事务的原子性确保事务所有的操作要么全部提交成功，要么全部失败回滚。

2. 一致性（Consistency）

执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的。

3. 隔离性（Isolation）

并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的。

4. 持久性（Durability）

一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

3.聊聊并发事务带来的问题？

---

1. 脏读（Dirty read）

当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据可能就是“脏数据”，这就是脏读。

2. 丢失修改（Lost to modify）

两个事务T1和T2读入同一数据并修改。T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。

3. 不可重复读（Unrepeatableread）

事务T1读取某一数据后，事务T2对其进行了修改，当事务T1再次读该数据时，得到与前一次不同的值。因此称为不可重复读。

4. 幻读（Phantom read）

和不可重复读很类似：

事务T1按一定条件从数据库中读取某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神秘消失了。

事务T1按一定条件从数据库中读取某些数据记录后，事务T2插入一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。

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

---

SQL 标准定义了四个隔离级别：

1. 读未提交（Read Uncommitted）

最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。

2. 读已提交（Read Committed）

允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。

3. 可重复读（Repeatable Read）

对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。

4. 可串行化（Serializable）

最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

总结一张表：

| 隔离级别 | 脏读 | 不可重复读 | 幻读 |

| — | — | — | — |

| 读未提交（Read Uncommitted） | √ | √ | √ |

| 读已提交（Read Committed） | × | √ | √ |

| 可重复读（Repeatable Read） | × | × | √ |

| 可串行化（Serializable） | × | × | × |

👩‍💻面试官追问：MySQL的默认隔离级别是什么？

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。我们可以通过SELECT @@tx_isolation;命令来查看，MySQL 8.0 该命令改为SELECT @@transaction_isolation;

优化篇

============================================================

1.说说日常在项目中你是怎么优化SQL的？

---

可以从几个方面考虑：

优化表结构

• 尽量使用数字型字段。若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

• 尽可能的使用 varchar 代替 char。可变长字段存储空间小，可以节省存储空间。

• 当索引列大量重复数据时，可以把索引删除掉。比如有一列是性别，只有男、女，这样的索引是无效的。

优化查询

• 应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。

• 应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描。建议使用 union 替换 or

• 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描

• in 和 not in 也要慎用，否则会导致全表扫描

• 优化嵌套查询时可以将子查询尽量替换为多表连接查询（JOIN）

• 任何查询也不要出现select *！

索引优化

• 尽量使用复合索引，而少使用单列索引

• 最左前缀法则：如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列

• 对作为查询条件和 order by的字段建立索引

• 对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引

其他优化

总结

虽然我个人也经常自嘲，十年之后要去成为外卖专员，但实际上依靠自身的努力，是能够减少三十五岁之后的焦虑的，毕竟好的架构师并不多。

架构师，是我们大部分技术人的职业目标，一名好的架构师来源于机遇(公司)、个人努力(吃得苦、肯钻研)、天分(真的热爱)的三者协作的结果，实践+机遇+努力才能助你成为优秀的架构师。

如果你也想成为一名好的架构师，那或许这份Java成长笔记你需要阅读阅读，希望能够对你的职业发展有所帮助。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描

• in 和 not in 也要慎用，否则会导致全表扫描

• 优化嵌套查询时可以将子查询尽量替换为多表连接查询（JOIN）

• 任何查询也不要出现select *！

索引优化

• 尽量使用复合索引，而少使用单列索引

• 最左前缀法则：如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列

• 对作为查询条件和 order by的字段建立索引

• 对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引

其他优化

总结

虽然我个人也经常自嘲，十年之后要去成为外卖专员，但实际上依靠自身的努力，是能够减少三十五岁之后的焦虑的，毕竟好的架构师并不多。

架构师，是我们大部分技术人的职业目标，一名好的架构师来源于机遇(公司)、个人努力(吃得苦、肯钻研)、天分(真的热爱)的三者协作的结果，实践+机遇+努力才能助你成为优秀的架构师。

如果你也想成为一名好的架构师，那或许这份Java成长笔记你需要阅读阅读，希望能够对你的职业发展有所帮助。

[外链图片转存中…(img-Av1HdsIQ-1713289829358)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-cQu1l1Te-1713289829359)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！