Mysql系列(一): 一条sql语句是如何执行的

聪明的墨菲特12138
494 阅读11分钟

前言

平时我们使用mysql，经常是将其当做一个黑盒去使用，很少关注其内部的机制和流程。这篇文章中会把 MySQL 拆解一下，看看里面都有哪些“零件”，希望借由这个拆解过程，让你对 MySQL 有更深入的理解。这样当我们碰到 MySQL 的一些异常或者问题时，就能够直戳本质，更为快速地定位并解决问题。

Mysql基础架构&一条查询语句是如何执行的

总体来看，mysql分为两个部分: server层和存储引擎层

Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

而存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。

下面具体看下每个组件的功能与作用

连接器

连接器顾名思义，就是负责与客户端建立、维护、管理连接与获取权限等功能

当我们使用mysql客户端执行以下语句

mysql -h$ip -P$port -u$user -p
  • 如果输入的用户名或密码不对，会返回一一个"Access denied for user"的错误，然后客户端结束执行。
  • 如果用户名密码认证通过，连接器会根据权限表查出该账号拥有的权限。后续的权限判断都将以此时拿到的权限作为判断依据。(这也就意味着如果对一个账号的权限进行修改，且该账号已登入数据库，则不会立即生效)

此外，如果与mysql建立连接后一定时间没有操作后，连接会被主动断开，这个时间由wait_timeout字段控制

mysql> show variables like 'wait_timeout';

查询缓存

mysql 8.0版本后已经彻底删除了查询缓存功能

查询缓存简单来说就是将每次的查询结果记录下来，当有相同的查询请求再进来的时候，直接返回之前保存的查询结果，进而跳过后续流程，这对于这条重复的请求当然很高效，但是查询缓存往往是弊大于利的，因为查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。

当然对于那些高频读低频写的数据表，如配置等，这种方式还是有一定的优势的。

最佳实践是关闭默认的查询缓存，对于确定需要的，显示指定要使用查询缓存

mysql> select SQL_CACHE * from T where ID=10；

分析器

分析器主要功能是进行sql的语法词法解析，也就是判断你输入的sql语句的含义(也就是你要做什么)以及是否符合语法，如果语句不合法将会抛出'You have an error in your SQL syntax'报错信息；

优化器

优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。

例如下面这个联表语句

mysql> select * from t1 join t2 using(ID)  where t1.c=10 and t2.d=20;
  • 既可以先从表 t1 里面取出 c=10 的记录的 ID 值，再根据 ID 值关联到表 t2，再判断 t2 里面 d 的值是否等于 20。
  • 也可以先从表 t2 里面取出 d=20 的记录的 ID 值，再根据 ID 值关联到 t1，再判断 t1 里面 c 的值是否等于 10。 优化器负责判断这两种方式哪种更优

执行器

以这个查询语句为例，执行器在执行前首先会进行权限校验，也就是所使用的账号是否拥有要操作的表权限，如果有权限就打开表继续执行；

mysql> select * from T where ID=10;

打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。比如我们这个例子中的表 T 中，ID 字段没有索引，那么执行器的执行流程是这样的：

  1. 调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是则跳过，如果是则将这行存在结果集中；
  2. 调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
  3. 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

至此，这个语句就执行完成了。

对于有索引的表，执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口，之后循环取“满足条件的下一行”这个接口，这些接口都是引擎中已经定义好的。

Mysql的日志系统&一条更新语句是如何执行的

上一章节整体描述了一条查询语句的执行过程，顺便也介绍了mysql的系统架构，这一章我们来看一看一条更新语句是如何执行的,这里以一条最基础的更新语句为例

mysql> update T set c=c+1 where ID=2;

首先可以肯定的是，查询语句的那一套流程，更新语句也是同样会走一遍。

  • 你执行语句前要先通过连接器连接数据库；
  • 在一个表上有更新的时候，跟这个表有关的查询缓存会失效，所以这条语句就会把表 T 上所有缓存结果都清空。这也就是我们一般不建议使用查询缓存的原因。
  • 接下来，分析器会通过词法和语法解析知道这是一条更新语句。
  • 优化器决定要使用 ID 这个索引。
  • 然后，执行器负责具体执行，找到这一行，然后更新。

下面重点说一下更新语句与查询语句不一样的地方: 日志系统,更新语句执行时涉及到了日志系统中两个重要的日志模块，redo log（重做日志）和 binlog（归档日志）。

redo log

redo log仅在InnoDB引擎中支持，这也是其成为mysql默认引擎的主要原因之一

具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面；试想一下，如果不使用这种方式，每一次更新操作都要去写进磁盘，那么IO成本会比较高，使用这种方式可以有效的提高执行效率。

这其实就是 MySQL 里经常说到的 WAL 技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。

另外需要注意的是，redo-log可以看做是一块环形缓冲区，其大小是固定的，假如配置为一组四个文件，每个文件1GB，那么缓冲区的大小也就是4GB，当最后一个文件写满后会从第一个文件的开头继续写入

有两个指针用于标记位置，write_pos用于标记当前写入位置，没写入一条数据向后移动一次；check_point用于标记当前要擦除的位置，数据更新到磁盘后，则会向后移动；

write pos 和 checkpoint 之间的是还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示redolog满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。

bin log

上面我们聊到的redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为 binlog（归档日志）。

为什么会有两份日志呢？

因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力，binlog 日志只能用于归档。而 InnoDB 是另一个公司以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力。

这两种日志有以下三点不同。

  1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
  2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
  3. redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

两阶段执行

在了解了redo-log和binlog之后，我们来整体的看一下这两个日志或者说执行器与InnoDB引擎是如果处理一条update语句的

  1. 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
  2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
  3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
  4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
  5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

图中浅色的部分是在InnoDb中执行的，深色部分是在执行器执行的

最后三步看上去有点“绕”，将 redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶段提交"。

那么问题来了，为什么需要两阶段提交呢? 因为运维在恢复数据时会使用bin-log进行数据回放，所以必须要保证bin-log的记录与实际落入磁盘的数据是一致的，那么就必须要考虑异常情况下的数据一致性，具体情况如下：

首先我们看下这三步的简化流程：

  1. prepare阶段
  2. 写binlog
  3. commit
  • 当在2之前崩溃时
    • 重启恢复：发现没有commit也没有binlog记录，回滚,数据实际没有写入磁盘。
    • 备份恢复：没有binlog，因此使用binlob恢复数据与期望一致
  • 当在3之前崩溃
    • 重启恢复：虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。
    • 备份恢复：有binlog记录，因此使用binlob恢复数据与期望一致

如果不使用两阶段执行，就会发生redolog写入完成后crash，binlog写入失败，此时再重启恢复后，数据依旧会写入磁盘，但是在使用bin-log进行回滚时，就会丢失此数据

关于mysql日志系统一些常见Q&A

Q: 既然redo-log也会进行磁盘写入，那么与直接将数据写入磁盘有什么区别呢?

因为写数据到磁盘中是随机写，IO消耗很大；写redo log是顺序写，不用去“找位置”，而更新数据需要找位置，因此开销更低；而且使用redo-log可以实现组提交的方式将多个事务的变更统一写磁盘，可以提升吞吐量；

Q: 假如一个事务执行完成，redo-log也记录完成但是还未将数据刷入磁盘，此时select该数据会不会获取不到更新?

不会出现这种情况，因为mvcc的模式，select时并不是直接去磁盘中获取数据，而是优先从内存中获取；根据文中的内容可以看出，更新操作后对应的数据一定是会在内存中或者已经刷入磁盘的，因此读取到的数据会是更新后的数据，不会出现更新成功但是读取不到的问题

Q: redo-log prepare状态，binlog完整，此时mysql崩溃，在恢复时如何处理这条数据?

正常情况下要redo-log为commit才会认为这条数据是正常的，不过在故障恢复流程中会将这种状态的数据进行自动commit，因此binlog中的记录依旧是靠谱的

avatar
文章
阅读
粉丝