【MySQL】一条SQL语句的具体执行流程

目录

前言

过程

一、连接

二、查询缓存（MySQL8删除了该模块）

三、SQL解析器

四、优化器

五、执行器

六、InnoDB

结语 

---

前言

日常我们执行SQL语句只要创建连接，然后执行对应的SQL语句即可。但是对于其具体在数据库中的流程我们一般不去了解，这篇文章将会详细介绍一条SQL在数据库中具体的执行流程，对于过程中的其它可能情况会稍微提及，不会去拓展。

过程

直接先上一张完整的流程图吧

一、连接

我们一般使用MySQL驱动去实现连接，但是当多个用户同时使用都需要建立对应的连接，这个时候频繁地创建和销毁，使用数据库连接池（比如Druid，C3P0，Tomcat JDBC Pool）可以有效地减少我们的资源浪费和性能损失，在MySQL中也有对应的连接池。

二、查询缓存（MySQL8删除了该模块）

查询缓存在过去能够提供一定的性能提升，但是在现代高并发、大数据量的应用中，会带来一些问题和限制。比如任何更新操作（比如增删改）都会导致缓存失效，可能会有锁竞争问题，还有在大型数据库中维护大量的查询内存可能导致内存压力。

三、SQL解析器

SQL语句到达MySQL后需要转化为数据库所认识的语言，SQL解析器就是负责将用户提交的SQL查询语句解析为数据库系统可以理解和执行的内部数据结构。

词法分析：将SQL语句分解为词法单元，如SELECT、FROM、WHERE、表名等

语法分析：校验语句是否合法，如关键字的位置，括号的使用等。

构建解析树：构建解析(语法)树，反映SQL语句的结构和关系。

语义分析：检查SQL语句是否存在逻辑错误，如列名表名是否存在，条件是否合法。

四、优化器

优化器会评估不同的查询计划所需要的成本，选择出它认为最优的一条查询计划。这个过程包括了成本估算、索引选择、连接顺序优化等等。

I/O成本：执行 SQL 查询所需的磁盘 I/O 操作的成本。包括从磁盘读取表数据和索引数据，以及将结果写回磁盘的成本。通常，磁盘 I/O 是数据库查询中最昂贵的操作之一。（MySQL是以页读取的，所以读取到的不仅仅是指定的数据，该方式应该也是快速实现范围查询的关键之一）

CPU成本：不同的执行计划可能需要不同数量的CPU操作。

内存成本：在执行某些查询时需要对数据进行排序和连接操作，这些操作通常需要分配内存来存储中间结果。

五、执行器

确定完真正的执行计划之后，执行器会去调用存储引擎接口实现接下来的操作。这里讲的是InnDB存储引擎。

六、InnoDB

结合下图更容易理解

Buffer Pool：缓冲池，用于管理内存中数据页的缓存，存储数据库表的数据和索引，提高数据库的性能和响应速度。更新操作也是在这里做的。

Undo Log：（逻辑日志）记录数据操作前的样子，用于回滚操作。

Redo Log：（存储引擎层日志）InnoDB专属的日志，记录数据操作后的样子，保证数据的一致性和持久性，物理日志。

Bin Log：（MySQL层日志）二进制日志文件，记录所有的数据库更新和修改操作记录。

---

一条更新操作执行流程：

①首先InnoDB会去Buffer Pool里查询，如果没有，就会去磁盘文件里加载数据到Buffer Pool。

②同时InnoDB会将该数据的原始记录保存到Undo Log中。

③在Buffer Pool中更新数据，该数据其实为“脏数据”（即被修改但是未写入磁盘的数据页），该脏数据会使用一定的策略刷入磁盘。

④在Redo Log Buffer中记录修改后的数据。

接下来就是事务提交了，下面的三个步骤都属于事务提交，也就是MySQL的二阶段提交。

⑤prepare阶段：将Redo Log Buffer中的数据刷到Redo Log中，并设置为prepare状态。

⑥commit阶段：将本次记录写入到Bin Log中，将Bin Log的文件名和更新内容的位置记录到Redo Log中，并将状态设置为commit。

• 如果在写入Redo Log之前崩溃，Redo Log和Bin Log都没有数据记录，满足一致性。
• 如果在prepare之后立马崩溃，那么拿着Redo Log中的事务id去Bin Log里面是找不到的（因为Bin Log还没有记录），这个时候就执行回滚。
• 如果在写入Bin Log后立马崩溃（还未commit），那么恢复的时候哪些Redo Log的事务id去Bin Log里面查找是可以找到的，所以可以直接提交数据。

结语 

关于一条SQL语句的执行过程大概就这样了，中间可能还涉及到各种参数的设置，以及InnoDB对于某个时候出现宕机等情况采取的策略，没有拓展去讲。