SQL底层执行过程

MySQL 的查询流程

客户端请求
连接器

负责与客户端的通信,是半双工模式（半双工(Half Duplex)数据传输指数据可以在一个信号载体的两个方向上传输,但是不能同时传输。），验证请求用户的账户和密码是否正确，③如果用户的账户和密码验证通过,会在MySQL自带的权限表中查询当前用户的权限:

验证用户身份，给予权限

查询缓存

MySQL的缓存主要的作用是为了提升查询的效率，缓存以key和value的哈希表形式存储，key是具体的sql语句，value是结果的集合。如果无法命中缓存,就继续走到分析器的的一步,如果命中缓存就直接返回给客户端。（存在缓存则直接返回，不存在则执行后续操作）

分析器

分析器的主要作用是将客户端发过来的sql语句进行分析，这将包括预处理与解析过程，在这个阶段会解析sql语句的语义，并进行关键词和非关键词进行提取、解析，并组成一个解析树。具体的关键词包括不限定于以下：select/update/delete/or/in/where/group by/having/count/limit等.如果分析到语法错误，会直接给客户端抛出异常:ERROR:You have an error in your SQL syntax.（对SQL进行词法分析和语法分析操作）

优化器

主要对执行的sql优化选择，最优的执行方案方法（判断走哪个索引）

执行器

执行时会先看用户是否有执行权限，有才去使用这个引擎提供的接口

去引擎层获取数据返回

如果开启查询缓存则会缓存查询结果

在mysql8.0后，放弃缓存机制。原因在于：如果对表数据进行表更新操作某一条数据，无法查找那条已缓存的数据进行并进行更改，而是对更新操作对那张表所有缓存数据进行清空

SQL在引擎层执行过程（INNODB引擎）

在掌握SQL在引擎层的执行过程，首先需要掌握以下几个知识点

缓存池（Buffer Pool）

数据库的CURD操作都是直接操作Buffer Pool，默认大小128M，一般设置为机器内存的60%～70%。

缓存池数据结构= 描述信息（数据页的元数据信息，包括数据页所属表空间、数据页编号）+缓存页

InnoDB的缓冲池设计的思路

磁盘访问按页读取能够提高性能，所以缓冲池一般也是按页缓存数据；
预读机制启示了我们，能把一些“可能要访问”的页提前加入缓冲池，避免未来的磁盘IO操作；

Buffer Pool中哪些是空闲的缓存页

MYSQL引入了一个链表来帮助我们找到空闲的缓存页，叫free链表，是一个双向链表，链表节点是空闲的缓存页对应的描述信息块（空的缓存页）。

free加载的时机：数据库启动时，如果缓存页不够用了

如何数据是否在Buffer Pool中（查询）

MYSQL中还有一个哈希表数据结构，用表空间号+数据页号作为key，缓存页的地址作为value。当需要操作数据页时，首先从哈希表中根据"表空间号+数据页号"作为key进行查询，如果查询不为空的话证明数据页已经被缓存了；如果查询为空，则从磁盘进行加载，并将数据写入该哈希表，下次再使用这个数据页，就可直接从哈希表中读取。

更新Buffer Pool中的数据

当我们对数据进行更新操作时，由于是直接操作Buffer Pool缓存中的数据，势必会导致和磁盘文件中的数据页不一致，这些不一致的数据页就叫脏页。

脏页是需要刷盘的，那刷盘的时候怎么知道哪些数据页需要刷，哪些不需要刷呢？因为不可能每个数据页都刷一遍，这样效率太低了。

解决脏页的方案：MYSQL引入了另一个链表来记录更新过的脏页数据，叫flush链表。通过这个flush链表，就能记录目前哪些缓存页是脏页，刷盘的时候后台线程只需要处理这个链表上面记录的数据页即可，刷盘结束后，将节点从链表上抹去。

Buffer Pool内存空间不足

基于LRU算法淘汰Buffer Pool内部缓存页，缓存命中率低的缓存页会被淘汰。引入一个新的LRU链表来记录，缓存页的命中情况（最新访问的缓存页一定在LRU头部，链表尾巴的肯定是命中率比较低的，需要被淘汰）

普通LRU有什么问题

容易出现预读失效 预读：由于预读(Read-Ahead)，提前把页放入了缓冲池，但最终MySQL并没有从页中读取数据，称为预读失效。

容易出现缓冲池污染 缓冲池污染：当某一个SQL语句，要批量扫描大量数据时，可能导致把缓冲池的所有页都替换出去，导致大量热数据被换出，MySQL性能急剧下降，这种情况叫缓冲池污染。 eg： select * from user where name like "%shenjian%"; 虽然结果集可能只有少量数据，但这类like不能命中索引，必须全表扫描，就需要访问大量的页。

MYSQL对LRU算法进行的优化

冷热数据分离，可以将LRU链表分为两个，一个存放冷数据，一个存放热数据

回滚日志（undo日志）

回滚日志，保存了事务发生之前的数据的一个版本，用于事务的回滚操作。

事务发生错误时回滚rollback，数据更新之前，会把原始数据保存在回滚日志中，保证事务出错回滚或者我们手动回滚的时候，能够在回滚日志中找到最初的数据。
提供了MVCC的非锁定读（快照读），依赖undo log实现。

重做日志（redo 日志）

redo 日志是为了在系统因奔溃而重启时恢复奔溃前的状态而提出的。lnnoDB 存储引擎是以页为单位来管理存储空间的，我们进行的增删改查操作从本质上来说都是在访问页面（包括读页面、写页面、创建），其实都在缓存池中操作。如果系统崩溃，可以通过该日志将数据加载到磁盘中，确保缓存池的数据和磁盘数据保持一致（redo 日志是用来保证 MySQL 持久化功能的）。

二进制日志（binlog日志）

Bin Log是一个二进制格式的文件，是MySQL最重要的日志，它记录了所有的DDL及DML语句（除了数据查询select、show等），以事件形式记录，还包含语句所执行的消耗时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是复制和恢复（mysqlbinlog来恢复）。

错误日志（error日志）

记录中MySQL启动和关闭服务的时候详细的日志信息，包括在MySQL实例在运行过程中遇到的错误、警告等信息也会记录在error log中。

SQL在引擎层执行步骤

以update 语句为例：update table set name="123" where id = 666

第一步

首先先判断数据是否在Buffer Pool的页中，如果不在，加载id为666的数据所在的缓存页加载到Buffer pool中。

第二步

写入更新数据前的旧数据到undo日志中

第三步

在Buffer Pool中对数据进行更新操作

第四步

写redo日志（在哪页做了修改），redo日志顺序写入磁盘，准备提交事务（prepare阶段）

第五步

准备提交事务，binlog日志写入磁盘中

第六步

写commit标记事务到redo日志中，保证redo日志和binlog日志保持一致

第七步

在系统空闲，将数据写入磁盘中，以页的形式

Redolog和binlog区别

redolog是循环写的，空间固定会用完；binlog是可以追加写的

redolog是InnoDB存储引擎特有的日志，用于记录事务的操作，包括对数据的修改、插入和删除等。redolog是在内存中缓存的，当事务提交时，会将redolog写入磁盘中的redo log文件中，以保证数据的持久性。

binlog是MySQL服务器的日志，用于记录所有的数据库操作，包括对数据的修改、插入和删除等。binlog是在磁盘上的文件，可以用于数据备份、恢复和复制等操作。
、

mysql redo log为什么有两阶段提交/为什么有prepare和commit两个状态

为了解决redo log和binlog不一致的问题。

我们直接提交事务，直接写入redo不可以吗，为什么要设置两阶段提交的机制呢？
这里我们逆向推导，现有这样一个更新操作，要将某表中的一个字段state从1改为0

1、如果是先写入redo，再写入binlog：
如果刚写完redo，服务崩溃了，再次重启时需要做数据恢复
因为这里redo已经写入完成了，事务已经生效，所以我们数据恢复就要恢复成事务完成后的状态，即将state恢复为0；重启服务后，因为有redo记录，数据会更新成0，但是如果这时执行了binlog的数据恢复，因为binlog是没有这条操作记录的，针对state的上一次记录是1，则会恢复为1，与我们想要恢复的值不符，也就产生了问题

2、如果是先写入binlog，再写入redo:
如果刚写完binlog，服务崩溃了，同样重启后需要做数据恢复
因为redo中没有这条操作的记录，事务没有生效，所以数据恢复是要恢复成事务开始之前的状态，即将state恢复成1；重启服务后，因为没有redo记录，系统不做事务操作，但是有binlog中‘1变成0’的记录，这时进行数据恢复，会将数据更新为0（产生了一个新的事务），与我们想要恢复的值也不同

可以使用binlog替代redolog进行数据恢复吗？

不可以

innodb利用wal技术进行数据恢复，write ahead logging技术依赖于物理日志进行数据恢复，binlog不是物理日志是逻辑日志，因此无法使用；
那么，为什么write ahead logging技术不可以使用逻辑日志进行数据恢复呢？这个问题可以考虑一下自增锁的场景，当自增锁的模式设置为innodb_autoinc_lock_mode = 2时，mysql会锁住分配自增值的代码逻辑，不去进行自增值的预分配，由此带来的问题就是，高并发场景下多个事务中的insert（单条insert语句包含多个待插入值）逻辑会造成自增ID不固定的问题，由此带来的结果就是，利用binlog中的逻辑日志进行主从复制时，从库中的ID和主库中的ID不一致。因此，在特定场景下，逻辑日志相对于物理日志，显得不是那么可靠。

可以只使用redolog而不使用binlog吗？

不可以

redolog是循环写，写到末尾要回到开头继续写，这样的日志无法保留历史记录，无法进行数据复制。
个人理解redolog其实是物理数据的一个缓存，理论上可以不需要redolog，插入的数据落盘后再返回插入成功，但是数据落盘的过程比较耗时，需要更新各种索引（B+树），因此现在数据落入redolog即返回成功，加快了返回速度。

为什么执行顺序是: redolog(prepare 准备状态)--->binlog--->redo log(commit 提交状态)？

假设执行顺序是 redolog（提交）- binlog

发生异常重启的状况，导致数据日志丢失

binlog日志丢失：对于一个数据库来说，当数据写入了（redolog记录到），但是没有写入记录（binlog没记录到）。相当于一个数据库只有数据，没有该数据的记录，一致性出错！
redolog日志丢失：对于一个数据库来说，当数据没有写入（redolog没记录到），但是却有记录（binlog记录到）。相当于对一个数据库来说，该数据有记录，但是查不到。
因此这也是为什么增删改语句的时候，执行顺序是: