我所了解的MySQL之一：根基架构

今天MySQL教程栏目为大家介绍我所了解的根基架构。

今天MySQL教程栏目为大家介绍我所了解的根基架构。

从上图可以看到，与客户端的交互中，MySQL 的办事端离别经过了连贯器、查询缓存、剖析器、优化器、施行器和存储引擎这几局部。

下面就以一条简略的查询语句来描述 MySQL 办事端的各组成局部及它们所起的作用。

2.1 连贯器

在客户端提交查询语句以前，需要与办事端创立连贯。所以最先来到的是连贯器，连贯器的作用就是负责与客户端创立、治理连贯，同时查询会员的权限。

需要注意的是：

• 连贯器只猎取会员的权限，并不做校验，校验是在查询缓存或施行器才进行。
• 一旦创立连贯同时猎取会员的权限之后，只要创立新的连贯才会刷新会员权限。
• 关于长工夫没有发送要求的客户端，连贯器会主动断开连贯。这里的「长工夫」是由 wait_timeout 参数来决议的，它的默许值为8小时。

2.2 查询缓存

在经过连贯器的创立连贯、猎取会员权限之后，接下来会员可以提交查询语句了。

最先经过的是查询缓存局部，由它的名字也能够猜到，查询缓存的作用就是查询 MySQL 可否施行过客户端提交的查询语句，要是这条 SQL 以前施行过，而且会员对该表有施行该语句的权限，就会直接返回以前施行的效果。

所以在某些时候，屡次施行一句 SQL 并不克不及得到它的均匀施行工夫，由于查询缓存的关系，背面的施行工夫往往比首先次施行要短。

要是你不想运用缓存，可以在每次查询后都用 update 语句更新表，固然这是非常费事而且憨的办法。MySQL也供给了响应的配置项—— query_cache_type，你可以在 my.cnf 文件中将 query_cache_type 设定为0以关闭查询缓存。

需要注意的是：

• 查询缓存局部是以 key-value 情势进行存储的，key 为查询语句，value 是查询效果。
• 当对数据表进行更新时，对于这张表的所有查询缓存都会失效，所以个别来说查询缓存的命中率是很低的。
• 在 MySQL 8.0 的版本中，查询缓存的功能已经被删除。

2.3 剖析器

我运用的 MySQL 版本是5.7.21，所以客户端提交的查询语句会走查询缓存，要是没有命中，那么将继续往下走，来到剖析器。

剖析器会对提交的语句进行词法剖析（解析语句）和语法剖析（推断语句可否相符 MySQL 的语律例则），所以剖析器的作用就是解析 SQL 语句并检查其合法性。

需要注意的是：

• MySQL 在检查 SQL 语句合法性时，仅会在最先不相符 MySQL 语律例则的地方提醒差错，并不会将 SQL 语句中所有语法差错的地方全部展现。

举个例子：

select * form user_info limit 1; 

上面这句 SQL 有两个差错，首先是 from 拼写差错，第二是不存在 user_info 这张表，在施行之后，MySQL只会提示一个差错，下面展现了三次施行 SQL 的效果信息。

首先次的施行信息：
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 'form user_info limit 1' at line 1, Time: 0.000000s

修改为from后第二次的施行信息：1146 - Table 'windfall.user_info' doesn't exist, Time: 0.000000s

修改为 user 表后第三次的施行信息：
OK, Time: 0.000000s 

2.4 优化器

在校验了 SQL 语句的合法性之后，MySQL 已经晓得会员提交的语句是干什么的了，但是在真正施行以前，还需要经过非常“形而上学”的优化器。

最开端这两个指针都指向统一个节点，且节点日志元素都为空，表示此时 redo log 为空。当会员开端提交更新语句，write 节点开端往前挪移，假如挪移到3的位置。而此时的状况就是 redo log 中有1-3这三个日志元素需要被耐久化到磁盘中，当 InnoDB 余暇时，read 指针往前挪移，就代表着将 redo log 耐久化到磁盘。

但这里有一种特别状况，就是 InnoDB 不断没有余暇，write 指针不断在写入日志，直到它写到5的位置，再往前写又回到了最开端1的位置（也就是上图的位置，但不一样的是链表节点中都存在日志数据）。

此时发明1的位置已经有日志数据了，同时 read 指针也在。那么这时候 write 指针就会暂停写入，InnoDB 引擎开端催动 read 指针挪移，把 redo log 清空掉一局部之后再让 write 指针写入日志文件。

3.1.4 redo log 的作用

我们已经晓得，redo log 中记载的是数据页的物理修改，所以 redo log 能够保障在数据库产生异样重新启动时，记载尚未写入磁盘，但是在重新启动后可以通过 redo log 来“redo”，从而不会产生记载遗失的状况，保障了事务的耐久性。

这一能力也被称作 crash-safe。

3.2 归档日志 bin log

前面说到 redo log 是 InnoDB 特有的日志，而 bin log 则是属于 MySQL Server 层的日志，在默许的 Statement Level 下它记载的是更新语句的原始逻辑，即 SQL 自身。

别的需要注意的是：

• bin log 的日志文件大小并不牢固，它是“追加写入”的模式，写完一个文件后会切换到下一个文件写入。
• bin log 没有 crash-safe 的能力。
• bin log 是在事务终究提交前写入的，而 redo log 是在事务施行中一直写入的。

3.2.1 bin log 的作用

与 redo log 不一样的是，bin log 常用于恢复数据，比方说主从复制，从节点依据父节点的 bin log 来进行数据同步，实现主从同步。

3.3 两阶段提交

为了让 redo log 和 bin log 的状态维持一致，MySQL 运用两阶段提交的方式来写入 redo log 日志。

在施行器调取 InnoDB 引擎的接口将写入更新数据时，InnoDB 引擎会将本次更新记载到 redo log 中，同时将 redo log 的状态标志为 prepare，表示可以提交事务。

随后施行器生老本次操纵的 bin log 数据，并写入 bin log 的日志文件中。

最后施行器调取 InnoDB 的提交事务接口，存储引擎把刚写入的 redo log 记载状态修改为 commit，本次更新完毕。

在这个历程中有三个步骤 add redo log and mark as prepare -> add bin log -> commit，即：

1. 写入 redo log 日志并标志为 prepare
2. 写入 bin log
3. 提交事务

要是在第二个步骤，也就是写入 bin log 以前系统解体或重新启动，启动后因为 bin log 中没有记载，会将 redo log 中的记载回滚至施行本次更新语句前。

要是在第三个步骤前，也就是提交以前系统解体或重新启动，即使没有 commit 但是知足 redo log 中记载为 prepare 状态而且 bin log 中也有完备记载，在重新启动后会主动 commit，并不会回滚。

4. 小结

本文主要介绍 MySQL 的根基架构以及各个组成局部的功能，最后介绍了 MySQL Server 层的 bin log 和 InnoDB 特有的 redo log 这两种日志模块。

5. 数往知来

下列的几个题目是对本文所描述内容的发问，稳固见识，正所谓“温故而知新，可认为师矣”。

1. 要是查询语句中字段不存在、字段有歧义、关键字拼写差错，是由哪个局部报错？
2. 要是会员对表没有查询权限，是哪个局部报错？
3. 为何 MySQL 的查询缓存会无效？
4. 一条 select 查询语句是怎样施行的？
5. MySQL 常用的存储引擎是什么？
6. MySQL 的日志模块是什么？离别起到什么作用？
7. redo log 写满了怎么办？
8. 怎样了解 redo log 的两阶段提交？

9. redo log 和 bin log 的区别？

更多相干免费学习举荐：mysql教程(视频)

以上就是我所了解的MySQL之一：根基架构的细致内容，更多请关注 百分百源码网 其它相干文章！