零星知识点MySql原理

Mysql-基础篇(1)-一条更新SQL执行流程（Buffer

2020-05-24  本文已影响0人  tianlang136520
高达 00 人物集合

目录：

1、一个查询语句SQL是如何执行的？

SQL执行过程

1.1、 通信协议

MySQL 是支持多种通信协议的，可以使用同步/异步的通讯类型，支持长连接/短连接。

## 查看交互超时时间
show global variables like 'wait_timeout'; -- 非交互式超时时间，如 JDBC 程序
show global variables like 'interactive_timeout'; -- 交互式超时时间，如数据库工具
## 查看 MySQL 当前有多少个连接?
show global status like 'Thread%';
##Threads_cached:缓存中的线程连接数。
##Threads_connected:当前打开的连接数。
##Threads_created:为处理连接创建的线程数。 
##Threads_running:非睡眠状态的连接数，通常指并发连接数。
【思考🤔：MySQL 服务允许的最大连接数是多少呢?】

【答案】： 在 5.7 版本中默认是 151 个，最大可以设置成 16384(2^14)。

【思考🤔：MySQL 使用了半双工的通信方式?】

【答案】：要么是客户端向服务端发送数据，要么是服务端向客户端发送数据，这两个动作不能同时发生。所以客户端发送 SQL 语句给服务端的时候，(在一次连接里面)数据是不能分成小块发送的，不管你的 SQL 语句有多大，都是一次性发送。
比如用 MyBatis 动态 SQL 生成了一个批量插入的语句，插入 10 万条数据，values 后面跟了一长串的内容，或者 where 条件 in 里面的值太多，会出现问题。这个时候必须要调整 MySQL 服务器配置 max_allowed_packet 参数的值(默认 是 4M)，把它调大，否则就会报错。
另一方面，对于MySql服务端来说，也是一次性发送所有的数据，不能因为你已经取到了想要的数据就中断操作，这个时候会对网络和内存产生大量消耗。
所以，一定要在程序里面避免不带 limit 的这种操作，比如一次把所有满足条件 的数据全部查出来，一定要先 count 一下。如果数据量的话，可以分批查询。

1.2.、查询缓存（Query Cache）：

MySQL 内部自带了一个缓存模块。
缓存的作用：把数据以 KV 的形式放到内存里面，可以加快数据的读取速度，也可以减少服务器处理的时间。但是 MySQL 的缓存比较陌生，从来没有去配置过，也不知道它什么时候生效?
MySQL 的缓存默认是关闭的。
【思考🤔问题：默认关闭的意思就是不推荐使用，为什么 MySQL 不推荐使用它自带的缓存呢?】
【答案】：**主要是因为 MySQL 自带的缓存的应用场景有限：

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

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

【思考🤔】：如果写了一个词法和语法都正确的 SQL，但是表名或者字段不存在，会在哪里报错? 是在数据库的执行层还是解析器?

select * from balabala;

【答案】：解析器可以分析语法，但是它怎么知道数据库里面有什么表，表里面有什么字段呢? 实际上还是在解析的时候报错，解析 SQL 的环节里面有个预处理器。 它会检查生成的解析树，解决解析器无法解析的语义。比如，它会检查表和列名是
否存在，检查名字和别名，保证没有歧义。 预处理之后得到一个新的解析树。

1.4、查询优化(Query Optimizer)与查询执行计划：

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

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

select * from information_schema.optimizer_trace\G

分析完记得关掉它：

set optimizer_trace="enabled=off";
SHOW VARIABLES LIKE 'optimizer_trace';

【思考🤔问题】：优化完之后，得到一个什么东西呢?

【答案】：优化器最终会把解析树变成一个查询执行计划，查询执行计划是一个数据结构。 这个执行计划是不是一定是最优的执行计划呢? 不一定，因为 MySQL 也有可能覆盖不到所有的执行计划。
怎么查看 MySQL 的执行计划呢?
比如多张表关联查询，先查询哪张表?在执行查询的时候可能用到哪些索引，实际上用到了什么索引?
MySQL 提供了一个执行计划的工具。在 SQL 语句前面加上 EXPLAIN，就可以看到执行计划的信息。

EXPLAIN select name from user where id=1;

Explain 的结果也不一定最终执行的方式。

1.5、存储引擎：

【思考🤔】得到执行计划以后，SQL 语句是不是终于可以执行了?问题又来了:1、从逻辑的角度来说，数据是放在哪里的，或者说放在一个什么结构里面? 2、执行计划在哪里执行? 是谁去执行?

接下来时点给与解答：

show table status from `student`;

在 MySQL 里面，创建的每一张表都可以指定它的存储引擎，而不是一个数据库 只能使用一个存储引擎。存储引擎的使用是以表为单位的。而且，创建表之后还可以修改存储引擎。
一张表使用的存储引擎决定存储数据的结构，那在服务器上它们是怎么存储的呢?
首先要找到数据库存放数据的路径:

show variables like 'datadir';

1.6、执行引擎(Query Execution Engine)

【思考🤔】：是谁使用执行计划去操作存储引擎呢?

【答案】：这就是执行引擎，它利用存储引擎提供的相应的 API 来完成操作。
为什么修改了表的存储引擎，操作方式不需要做任何改变?
因为不同功能的存储引擎实现的 API 是相同的。
最后把数据返回给客户端，即使没有结果也要返回。

2、MySQL体系结构总结

2.1. 模块详解

mysql体系结构

2.2. 架构分层

总体上，把 MySQL 分成三层，跟客户端对接的连接层，真正执行操作的服务层，和跟硬件打交道的存储引擎层(参考 MyBatis:接口、核心、基础)。


架构分层

3、一条更新SQL是如何执行的?

3.1. 缓冲池 Buffer Pool

首先，InnnoDB 的数据都是放在磁盘上的，InnoDB 操作数据有一个最小的逻辑单位，叫做页(索引页和数据页)。对于数据的操作，不是每次都直接操作磁盘，因为磁盘的速度太慢了。InnoDB 使用了一种缓冲池的技术，也就是把磁盘读到的页放到一块内存区域里面。这个内存区域就叫 Buffer Pool。

buffer pool交互图

下一次读取相同的页，先判断是不是在缓冲池里面，如果是，就直接读取，不用再 次访问磁盘。
修改数据的时候，先修改缓冲池里面的页。内存的数据页和磁盘数据不一致的时候， 把它叫做脏页。InnoDB 里面有专门的后台线程把 Buffer Pool 的数据写入到磁盘， 每隔一段时间就一次性地把多个修改写入磁盘，这个动作就叫做刷脏。
Buffer Pool 是 InnoDB 里面非常重要的一个结构，它的内部又分成几块区域。这里趁机到官网来认识一下 InnoDB 的内存结构和磁盘结构。

3.2. InnoDB 内存结构和磁盘结构

InnoDB的内存结构&磁盘结构 
SHOW STATUS LIKE '%innodb_buffer_pool%';

这些状态都可以在官网查到详细的含义，用搜索功能。
Buffer Pool 默认大小是 128M(134217728 字节)，可以调整。 查看参数(系统变量):

SHOW VARIABLES like '%innodb_buffer_pool%';

【思考🤔问题】：内存的缓冲池写满了怎么办?(Redis 设置的内存满了怎么办?)

InnoDB 用 LRU 算法来管理缓冲池(链表实现，不是传统的 LRU，分成了 young 和 old)，经过淘汰的数据，剩下的就是热点数据。
内存缓冲区对于提升读写性能有很大的作用。

【思考🤔问题】：思考一个问题: 当需要更新一个数据页时，如果数据页在 Buffer Pool 中存在，那么就直接更新好了。 否则的话就需要从磁盘加载到内存，再对内存的数据页进行操作。也就是说，如果没有命中缓冲池，至少要产生一次磁盘 IO，有没有优化的方式呢?

SHOW VARIABLES LIKE 'innodb_change_buffer_max_size';

代表 Change Buffer 占 Buffer Pool 的比例，默认 25%。

【思考🤔一个问题】：如果 Buffer Pool 里面的脏页还没有刷入磁盘时，数据库宕机或者重启，这些数据丢失。如果写操作写到一半，甚至可能会破坏数据文件导致数据库不可用？

【答案】：为了避免这个问题，InnoDB 把所有对页面的修改操作专门写入一个日志文件，并且在数据库启动时从这个文件进行恢复操作(实现 crash-safe)——用它来实现事务的持久性。

crash-safe(崩溃恢复)

这个文件就是磁盘的 Redo Log(重做日志)，对应于/var/lib/mysql/目录下的 ib_logfile0 和 ib_logfile1，每个 48M。
这种日志和磁盘配合的整个过程，其实就是 MySQL 里 WAL 技术 (Write-Ahead Logging)，它的关键点就是先写日志，再写磁盘。

show variables like 'innodb_log%';
值 含义
innodb_log_file_size 指定每个文件的大小，默认 48M
innodb_log_files_in_group 指定文件的数量，默认为 2
innodb_log_group_home_dir 指定文件所在路径，相对或绝对。如果不指定，则为 datadir 路径。

【思考🤔问题】：同样是写磁盘，为什么不直接写到 db file 里面去?为什么先写日志再写磁盘?

我们先来了解一下随机 I/O 和顺序 I/O的概念。 磁盘的最小组成单元是扇区，通常是 512 个字节。 操作系统和内存打交道，最小的单位是页 Page。 操作系统和磁盘打交道，读写磁盘，最小的单位是块 Block。

机器读取数据过程
如果所需要的数据是随机分散在不同页的不同扇区中，那么找到相应的数据需要等到磁臂旋转到指定的页，然后盘片寻找到对应的扇区，才能找到我们所需要的一块数据，一次进行此过程直到找完所有数据，这个就是随机 IO，读取数据速度较慢。
假设已经找到了第一块数据，并且其他所需的数据就在这一块数据后边，那么就不需要重新寻址，可以依次拿到所需的数据，这个就叫顺序 IO。
【答案】：刷盘是随机 I/O，而记录日志是顺序 I/O，顺序 I/O 效率更高。因此先把修改写入日志，可以延迟刷盘时机，进而提升系统吞吐。
【优化】当然 Redo Log 也不是每一次都直接写入磁盘，在 Buffer Pool 里面有一块内存区域 (Log Buffer)专门用来保存即将要写入日志文件的数据，默认 16M，它一样可以节省磁盘 IO。 buffer pool 对Redo Log优化 
SHOW VARIABLES LIKE 'innodb_log_buffer_size';

需要注意：Redo Log 的内容主要是用于崩溃恢复。磁盘的数据文件，数据来自 buffer pool。Redo Log 写入磁盘，不是写入数据文件。
那么，Log Buffer 什么时候写入 log file?
在写入数据到磁盘的时候，操作系统本身是有缓存的。flush 就是把操作系统缓 冲区写入到磁盘。
log buffer 写入磁盘的时机，由一个参数控制，默认是 1。

SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
值 含义
0(延迟写) log buffer 将每秒一次地写入 log file 中，并且 log file 的 flush 操作同时进行。 该模式下，在事务提交的时候，不会主动触发写入磁盘的操作。
1(默认，实时 写，实时刷) 每次事务提交时 MySQL 都会把 log buffer 的数据写入 log file，并且刷到磁盘 中去。
2(实时写，延 迟刷) 每次事务提交时 MySQL 都会把 log buffer 的数据写入 log file。但是 flush 操 作并不会同时进行。该模式下，MySQL 会每秒执行一次 flush 操作。
事务写logBuffer & osCache & 磁盘的控制

这是内存结构的第 4 块内容，redo log，它又分成内存和磁盘两部分。redo log 有什么特点?

MySQL 的内存结构，总结一下，分为：Buffer pool、change buffer、Adaptive Hash Index、 log buffer。

【思考🤔】有了这些日志之后，总结一下一个更新操作的流程？

update student set name = 'biudefu' where id=1;

1、事务开始，从内存或磁盘取到这条数据，返回给 Server 的执行器;
2、执行器修改这一行数据的值为 biudefu;
3、记录 name=biudefu 到 undo log;
4、记录 name=biudefu 到 redo log;
5、调用存储引擎接口，在内存(Buffer Pool)中修改 name=biudefu;
6、 事务提交。

除了 InnoDB 架构中的日志文件，MySQL 的 Server 层也有一个日志文件，叫做
binlog，它可以被所有的存储引擎使用。

3.3. Binlog

binlog 以事件的形式记录了所有的 DDL 和 DML 语句(因为它记录的是操作而不是数据值，属于逻辑日志)，可以用来做主从复制和数据恢复。
跟 redo log 不一样，它的文件内容是可以追加的，没有固定大小限制。
在开启了 binlog 功能的情况下，可以把 binlog 导出成 SQL 语句，把所有的过程操作重放一遍，来实现数据的恢复。
binlog 的另一个功能就是用来实现主从复制，它的原理就是从服务器读取主服务器的 binlog，然后执行一遍。
有了这两个日志之后，我们来看一下一条更新语句是怎么执行的：

sql执行整体流程

例如一条语句:update student set name='biudefu' where id=1;

1、先查询到这条数据，如果有缓存，也会用到缓存。
2、把 name 改成biudefu，然后调用引擎的 API 接口，写入这一行数据到内存，同时记录 redo log。这时 redo log 进入 prepare 状态，然后告诉执行器，执行完成了，可以随时提交。
3、执行器收到通知后记录 binlog，然后调用存储引擎接口，设置 redo log 为 commit 状态。
4、更新完成。

这张图片的重点：

参考资料：

《数据库查询优化器的艺术-原理解析与SQL性能优化》
《MySQL高性能书籍第3版（中文）》
《MySQL技术内幕-InnoDB存储引擎第2版》

上一篇下一篇

猜你喜欢

热点阅读