← 全部文章

MySQL 面试笔记

MySQL13 min read

目录

数据库三范式

第一范式（1NF）：字段必须是原子值，不可再分。 第二范式（2NF）：在满足1NF基础上，非主键字段必须完全依赖主键，消除部分依赖。 第三范式（3NF）：在满足2NF基础上，非主键字段不能依赖其他非主键字段，消除传递依赖。

Bin log是什么，有什么用？（数据库被人干掉了怎么办？）

Binlog 的核心作用

  1. ‌主从复制‌
    • 主库（Master）将Binlog发送给从库（Slave），从库通过重放日志实现数据同步，支持高可用架构和读写分离‌
    • 例如：主库的INSERT操作会记录到Binlog，从库通过解析并执行该日志保持数据一致‌。
  2. ‌数据恢复‌
    • 通过回放特定时间点的Binlog事件，可恢复误删除或损坏的数据‌。
    • 例如：误删表后，可通过Binlog恢复到删除前的状态‌。
  3. ‌审计与追踪‌
    • 记录所有数据变更操作，便于追踪历史修改记录，满足合规性要求‌。
  4. ‌数据迁移‌
    • 通过解析Binlog实现跨数据库或跨版本的数据同步‌
bin log 以事件的形式记录了所有的 DDL 和 DML 语句（因为它记录的是操作而不是数据值，属于逻辑日志），可以用来做主从复制和数据恢复。

数据备份 + bin Log       报警     1点钟 恢复出来  1点钟  1-9点钟所有的能够对表发生变更的SQL语句

drop table 9点钟最后一条删除表的SQL语句   剩下的 执行一遍       9-10点这个中间的数据   怎么办  怎么处理的  

微盟     批处理的任务    结算的操作     9-10点钟的数据  你只能 找到他所有的SQL    人工调度   复原现场

一条条的人工比对    bin log 是需要手动开启的   bin log也删除了怎么办      云备份   备份在云厂商那边的 

凌晨1点钟全量备份   程序员  1点---9点钟      10点钟    数据文件全部删掉了   恢复1点钟   恢复到9点钟

image.png

image.png

数据恢复：区别于Redo Log的崩溃恢复，数据恢复是基于业务数据的，比如删库跑路，而崩溃恢复是断电重启的

什么是预读？

解析：磁盘读写，并不是按需读取，而是按页读取，一次至少读一页数据（一般是4K）但是Mysql的数据页是16K，如果未来要读取的数据就在页中，就能够省去后续的磁盘IO，提高效率。

默认回复：

mysql对于数据读取并不是按需去读取记录的，在底层使用的是 页 的数据结构去加载数据的，页的默认大小是16kb，操作系统也存在预读，默认大小是4kb。

其实这个页的底层也是个b+树，通过预读的方式可以减少对磁盘进行io的操作，从而加快查询的速度。

当然，这个默认大小16kb是可以修改的，在mysql当中提供了一个innodb_page_size来进行设置，有4kb，8kb，16kb，32kb，64kb就行选择，这个配置不是动态生效的，需要我们下载源码，编译源码后在源码的配置文件进行修改，然后再重新打包运行才能生效，因为很麻烦，所以默认不要去改它。

什么是Buffer Pool？

缓存表数据与索引数据，把磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的作用。

核心作用：

1.减少磁盘访问，将频繁访问的数据页缓存到内存中，避免每次操作都去触发磁盘的随机I/O，这个内存与内存的交互比磁盘与内存的交互快几十倍

2.支持事务的处理：所有的CRUD操作，均可以在Buffer pool中进行，通过脏页机制结合异步的刷盘机制，结合Redo Log日志，保证数据的持久性

3.我们还可以通过预读取机制，提前的加载相邻的数据页，减少IO的时间

Buffer Pool的内存淘汰策略

冷热分区的LRU策略

LRU链表会被拆分成为两部分，一部分为热数据，一部分为冷数据。冷数据占比 3/8，热数据5/8。

image.png

他的LRU逻辑是怎么设计的

MySQL的Buffer Pool通过改进的LRU算法管理内存淘汰，主要解决传统LRU在数据库场景下的预读失效和缓冲池污染问题。其核心策略如下：

分代LRU机制

将LRU链表划分为新生代（Young Sublist）和老生代（Old Sublist）两个区域，默认比例为5:3。新加载的数据页首次插入到老生代头部而非直接进入新生代，通过 innodb_old_blocks_pct参数可调整老生代占比（默认37%）。这种设计避免全表扫描等操作瞬间污染热点数据。

冷热数据隔离

  • ‌老生代保护期‌：通过 innodb_old_blocks_time参数（默认1000毫秒）设置时间窗口，只有存活超过该阈值且被再次访问的页才会晋升到新生代。这有效过滤短期批量访问的临时数据。
  • ‌晋升机制‌：老生代中的页被二次访问时，才会移动到新生代头部，确保长期热点数据保留在内存。

淘汰触发逻辑

当Buffer Pool空间不足时，优先淘汰老生代尾部的冷数据页。若页为脏页（被修改过），则先通过后台线程刷盘再释放。新生代尾部的页也可能被淘汰，但概率低于老生代

数据页第一次加载进来，放在LRU链表的什么地方？

放在冷数据区域的头部

冷数据区域的缓存页什么时候放入热数据区域？

MySQL设定了一个规则，在 innodb_old_blocks_time 参数中，默认值为1000，也就是1000毫秒。

意味着，只有把数据页加载进缓存里，在经过1s之后再次对此缓存页进行访问才会将缓存页放到LRU链表热数据区域的头部。

为什么是1秒？

因为通过预读机制和全表扫描加载进来的数据页通常是1秒内就加载了很多，然后对他们访问一下，这些都是1秒内完成，他们会存放在冷数据区域等待刷盘清空，基本上不太会有机会放入到热数据区域，除非在1秒后还有人访问，说明后续可能还会有人访问，才会放入热数据区域的头部。

Redo Log跟Buffer Pool的关系

崩溃恢复 基本保障 系统自动做的

InnoDB 引入了一个日志文件，叫做 redo log（重做日志），我们把所有对内存数据的修改操作写入日志文件，如果服务器出问题了，我们就从这个日志文件里面读取数据，恢复数据——用它来实现事务的持久性。

redo log 有什么特点？

1.记录修改后的值，属于物理日志

2.redo log 的大小是固定的，前面的内容会被覆盖，所以不能用于数据回滚/数据恢复。

3.redo log 是 InnoDB 存储引擎实现的，并不是所有存储引擎都有。

image.png

更新语句的流程是怎样的

image.png

例如一条语句：update teacher set name=‘老严’ where name =‘666’

1、先查询到这条数据，如果有缓存，也会用到缓存。

2、把 name 改成老严，然后调用引擎的 API 接口，写入这一行数据到内存，同时记录 redo log。这时 redo log 进入 prepare 状态，然后告诉执行器，执行完成了，可以随时提交。

3、执行器收到通知后记录 binlog，然后调用存储引擎接口，设置 redo log 为 commit 状态。

4、更新完成。

问题：为什么要用两阶段提交（XA）呢？

举例：

如果我们执行的是把 name 改成老严，如果写完 redo log，还没有写 bin log 的时候，MySQL 重启了。

因为 redo log 可以恢复数据，所以写入磁盘的是老严。但是 bin log 里面没有记录这个逻辑日志，所以这时候用 binlog 去恢复数据或者同步到从库，就会出现数据不一致的情况。

所以在写两个日志的情况下，binlog 就充当了一个事务的协调者。通知 InnoDB 来执行 prepare 或commit 或者 rollback。

简单地来说，这里有两个写日志的操作，类似于分布式事务，不用两阶段提交，就不能保证都成功或者都失败。

什么是小表驱动大表？

小表驱动大表的定义与原理

‌小表驱动大表‌是指在多表关联查询时，优先选择数据量小或过滤后结果集小的表作为驱动表（外层循环表），通过其逐行匹配大表（被驱动表）的数据。这种策略的核心目标是减少外层循环次数，从而降低I/O和计算资源消耗‌。

‌底层逻辑‌：

  • ‌循环次数优化‌：驱动表行数决定外层循环次数。例如，小表（100行）驱动大表（10万行）时，外层循环仅100次；反之则需10万次循环，效率显著降低‌。
  • ‌索引利用‌：被驱动表需在连接字段上建立索引，否则大表全表扫描会导致性能灾难‌。

大表驱动小表的弊端

若大表作为驱动表，即使内层循环次数少（如小表仅100行），但外层循环次数高（如大表10万行），会导致：

  1. ‌I/O压力剧增‌：大表全表扫描或索引扫描次数过多。
  2. ‌内存占用高‌：大表数据可能无法完全缓存，频繁触发磁盘读取‌。

如何实现小表驱动大表

  1. ‌调整JOIN顺序‌：

    • INNER JOIN：MySQL优化器通常自动选择小表驱动‌。
    • LEFT/RIGHT JOIN：需手动将小表放在驱动表位置（如 RIGHT JOIN中右表为驱动表）‌。
      • 案例：SELECT * FROM order RIGHT JOIN user ON order.user_id = user.id;

  2. ‌使用IN或EXISTS‌：

    • ‌IN‌：适合大表在右侧（小表驱动大表）‌。
      • 案例：select * from user where id in（select user_id from order）
    • ‌EXISTS‌：适合大表在左侧（大表驱动小表，但需结合索引优化）
      • 案例：select * from user where‌ **EXISTS(select * from order where order.user_id = user.id)**‌

特点：被驱动表一定要加上索引

Mysql的体系结构是什么样子的（一条查询语句它到底是怎么执行的？）

image.png

查询缓存(Query Cache)

MySQL 内部自带了一个缓存模块。默认是关闭的。主要是因为 MySQL 自带的缓存的应用场景有限，第一个是它要求 SQL 语句必须一模一样。第二个是表里面任何一条数据发生变化的时候，这张表所有缓存都会失效。

在 MySQL 5.8 中，查询缓存已经被移除了。

语法解析和预处理(Parser & Preprocessor)

下一步我们要做什么呢？

假如随便执行一个字符串 fkdljasklf ，服务器报了一个 1064 的错：

[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'fkdljasklf' at line 1

服务器是怎么知道我输入的内容是错误的？

或者，当我输入了一个语法完全正确的 SQL，但是表名不存在，它是怎么发现的？

这个就是 MySQL 的 Parser 解析器和 Preprocessor 预处理模块。

这一步主要做的事情是对 SQL 语句进行词法和语法分析和语义的解析。

词法解析

词法分析就是把一个完整的 SQL 语句打碎成一个个的单词。

比如一个简单的 SQL 语句：

select name from user where id = 1;

它会打碎成 8 个符号，记录每个符号是什么类型，从哪里开始到哪里结束。

语法解析

第二步就是语法分析，语法分析会对 SQL 做一些语法检查，比如单引号有没有闭合，然后根据 MySQL

定义的语法规则，根据 SQL 语句生成一个数据结构。这个数据结构我们把它叫做解析树。

image.png

预处理器（Preprocessor）

如果表名错误，会在预处理器处理时报错。

它会检查生成的解析树，解决解析器无法解析的语义。比如，它会检查表和列名是否存在，检查名字和别名，保证没有歧义。

查询优化（Query Optimizer）与查询执行计划

什么优化器？

问题：一条 SQL 语句是不是只有一种执行方式？或者说数据库最终执行的 SQL 是不是就是我们发送 的 SQL？

这个答案是否定的。一条 SQL 语句是可以有很多种执行方式的。但是如果有这么多种执行方式，这些执行方式怎么得到的？最终选择哪一种去执行？根据什么判断标准去选择？

这个就是 MySQL 的查询优化器的模块（Optimizer）。

查询优化器的目的就是根据解析树生成不同的执行计划，然后选择一种最优的执行计划，MySQL 里面使用的是基于开销（cost）的优化器，那种执行计划开销最小，就用哪种。

使用如下命令查看查询的开销：
    show status like 'Last_query_cost'; 
    --代表需要随机读取几个 4K 的数据页才能完成查找。

如果我们想知道优化器是怎么工作的，它生成了几种执行计划，每种执行计划的 cost 是多少，应该怎么做？

优化器是怎么得到执行计划的？

https://dev.mysql.com/doc/internals/en/optimizer-tracing.html

首先我们要启用优化器的追踪（默认是关闭的）：

SHOW VARIABLES LIKE 'optimizer_trace'; 

set optimizer_trace="enabled=on";

注意开启这开关是会消耗性能的，因为它要把优化分析的结果写到表里面，所以不要轻易开启，或者查看完之后关闭它（改成 off）。

接着我们执行一个 SQL 语句，优化器会生成执行计划：

select t.tcid from teacher t,teacher_contact tc where t.tcid = tc.tcid;

这个时候优化器分析的过程已经记录到系统表里面了，我们可以查询：

select * from information_schema.optimizer_trace\G

expanded_query 是优化后的 SQL 语句。

considered_execution_plans 里面列出了所有的执行计划。

记得关掉它：

        set optimizer_trace="enabled=off"; 

•       SHOW VARIABLES LIKE 'optimizer_trace';

优化器可以做什么？

MySQL 的优化器能处理哪些优化类型呢？

比如：

1、当我们对多张表进行关联查询的时候，以哪个表的数据作为基准表。 

2、select * from user where a=1 and b=2 and c=3，如果 c=3 的结果有 100 条，b=2 的结果有 200 条，		a=1 的结果有 300 条，你觉得会先执行哪个过滤？ 

3、如果条件里面存在一些恒等或者恒不等的等式，是不是可以移除。 

4、查询数据，是不是能直接从索引里面取到值。 

5、count()、min()、max()，比如是不是能从索引里面直接取到值。 

6、其他。

优化器得到的结果

优化器最终会把解析树变成一个查询执行计划，查询执行计划是一个数据结构。

当然，这个执行计划是不是一定是最优的执行计划呢？不一定，因为 MySQL 也有可能覆盖不到所有的执行计划。

MySQL 提供了一个执行计划的工具。我们在 SQL 语句前面加上 EXPLAIN，就可以看到执行计划的信息。

EXPLAIN select name from user where id=1;

← 全部文章