MySql

MySQL 02_MySQL逻辑架构详解

一、MySQL逻辑架构剖析

1.1 MySQL系统CS架构简介

MySQL是典型的C/S架构，服务器端程序使用的是 mysqld，客户端使用的是 mysql程序 或 各类程序语言的MySQL API库； MySQL系统逻辑架构图：

不论采用哪种类型的客户端 与 服务器进程进行通信（交互），最后实现的效果都是：客户端进程与服务器断建立连接后向服务器进程发送一段文本（SQL语句），服务器进程处理后再向客户端进程发送一段文本(处理结果)。

下图是 MySQL 的一个简要架构图，从下图你可以很清晰的看到客户端的一条 SQL 语句在 MySQL 内部是如何执行的：

  • 连接器： 身份认证和权限相关(登录 MySQL 的时候)。
  • 查询缓存： 执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。
  • 分析器： 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。
  • 优化器： 按照 MySQL 认为最优的方案去执行。
  • 执行器： 执行语句，然后从存储引擎返回数据。执行语句之前会先判断是否有权限，如果没有权限的话，就会报错。
  • 插件式存储引擎：主要负责数据的存储和读取，采用的是插件式架构，支持 InnoDB、MyISAM、Memory 等多种存储引擎。

从业务处理逻辑上， MySQL分为：连接层、服务层、引擎层 和 存储层。

1.2 连接层

一般系统（客户端）访问 MySQL服务器前，做的第一件事就是建立TCP连接，MySQL服务端维护着一个 连接池 来管理客户端连接。

经过三次握手建立连接成功后，MySQL服务器对经TCP传输过来的账号密码做身份认证、权限获取：

  • 用户名或密码不对，会收到一个 Access denied for user 的错误，客户端程序结束执行；
  • 用户名密码认证通过，会从权限表查出账号拥有的权限与连接关联，之后的权限判断逻辑，都将依赖于此时读到的权限；

收到TCP连接请求后，MySQL必须要分配一个线程来专门与这个客户端进行交互，所以在连接层还维护有一个 线程池，每一个连接从线程池中获取线程，去进行后面的流程，这省去了创建和销毁线程的开销；

1.3 服务层

1、SQL Interface: SQL接口

  • 接收用户的SQL命令，并且返回用户需要查询的结果。比如SELECT … FROM就是调用SQL Interface;
  • MySQL支持DML（数据操作语言）、DDL（数据定义语言）、存储过程、视图、触发器、自定义函数等多种SQL语言接口;

2、Parser: 解析器

  • 在解析器中对 SQL 语句进行语法分析、语义分析。将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的。如果在分解构成中遇到错误，那么就说明这个SQL语句是不合理的;
  • 在SQL命令传递到解析器的时候会被解析器验证和解析，并为其创建语法树，并根据数据字典丰富查询语法树，会验证该客户端是否具有执行该查询的权限。创建好语法树后，MySQL还会对SQL查询进行语法上的优化，进行查询重写;

3、Optimizer：查询优化器

  • SQL语句在语法解析之后、查询之前会使用查询优化器确定 SQL 语句的执行路径，生成一个执行计划;
  • 这个执行计划表明应该使用哪些索引进行查询（全表检索还是使用索引检索），表之间的连接顺序如何，最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并将查询结果返回给用户; 它使用“选取-投影-连接”策略进行查询，例如：
1

SELECT id,name FROM student WHERE gender = '女';

这个SELECT查询先根据WHERE语句进行选取，而不是将表全部查询出来以后再进行gender过滤，这个SELECT查询先根据id和name进行属性投影，而不是将属性全部取出以后再进行过滤，将这两个查询条件连接起来生成最终查询结果；

4、Caches & Buffers： 查询缓存组件

  • MySQL内部维持着一些Cache和Buffer，比如Query Cache用来缓存一条SELECT语句的执行结果，如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化和执行的整个过程了，直接将结果反馈给客户端；
  • 这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等；
  • 这个查询缓存可以在不同客户端之间共享；
  • 从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除；

1.4 引擎层

插件式存储引擎层（ Storage Engines）， 真正的负责了MySQL中数据的存储和提取，对物理服务器级别维护的底层数据执行操作 ，服务层通过API与存储引擎进行通信。

1.5 存储层

所有的数据，数据库、表的定义，表的每一行的内容，索引，都是存在 文件系统 上，以 文件 的方式存在的，并完成与存储引擎的交互。当然有些存储引擎比如InnoDB，也支持不使用文件系统直接管理裸设备，但现代文件系统的实现使得这样做没有必要了。在文件系统之下，可以使用本地磁盘，可以使用DAS、NAS、SAN等各种存储系统。

二、SQL执行流程

2.1 MySQL 中的 SQL执行流程

SQL 语句在 MySQL 中的流程是： SQL语句→查询缓存→解析器→优化器→执行器：

2.2 MySQL的查询流程

1、查询缓存

MySQL Server 如果在查询缓存中发现了这条 SQL 语句，就会直接将结果返回给客户端；如果没有，就进入到解析器阶段。需要说明的是，因为查询缓存往往效率不高，所以在 MySQL8.0 之后就抛弃了这个功能。

查询缓存是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。

在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。这就意味着，只有相同的查询操作才会命中查询缓存。两个查询请求在任何字符上的不同（例如：空格、注释、大小写），都会导致缓存不会命中。因此 MySQL 的 查询缓存命中率不高 。

同时，如果查询请求中包含某些系统函数、用户自定义变量和函数、一些系统表，如 mysql 、information_schema、performance_schema 数据库中的表，那这个请求就不会被缓存。以某些系统函数举例，可能同样的函数的两次调用会产生不一样的结果，比如函数 NOW ，每次调用都会产生最新的当前时间，如果在一个查询请求中调用了这个函数，那即使查询请求的文本信息都一样，那不同时间的两次查询也应该得到不同的结果，如果在第一次查询时就缓存了，那第二次查询的时候直接使用第一次查询的结果就是错误的！

此外，既然是缓存，那就有它缓存失效的时候。MySQL的缓存系统会监测涉及到的每张表，只要该表的结构或者数据被修改，如对该表使用了INSERT、UPDATE、DELETE、TRUNCATE TABLE、ALTER TABLE、DROP TABLE或DROP DATABASE语句，那使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除！对于更新压力大的数据库来说，查询缓存的命中率会非常低。

总之，因为查询缓存往往弊大于利，查询缓存的失效非常频繁。

一般建议在 静态表 里使用查询缓存，所谓 静态表 就是一般我们极少更新的表。比如，一个系统配置表、字典表，这中表上的查询才适合使用查询缓存。好在 MysQL也提供了这种”按需使用”的方式，可以将 my.cnf 配置参数query_cache_type 设置成 DEMAND，代表当sql语句中有SQL_CACHE关键词时才缓存。

Tips: query_cache_type有3个值，0 —— 代表关闭查询缓存OFF；1 —— 代表开启ON；2 ——（DEMAND） 例如：

1
2

# my.cnf 中配置如下
query_cache_type=2

这样对于默认的SQL语句都不使用查询缓存，而对于你确定要是使用查询缓存的语句，可以用SQL_CACHE显示指定，像下面这个语句一样：

1

select SQL_CACHE * from test where ID=5;

这样该SQL程序语句将被进行缓存，下次再查询时即可使用缓存快速查询返回。

查看当前mysql实例是否开启缓存机制:

1
2
3
4
5
6

# mysql5.7中:
mysql> show global variables like "%query_cache_type%";

# mysql8.0中
mysql> show global variables like "%query_cache_type%";
Empty set (0.02 sec)

监控查询缓存的命中率：

1

show status like '%Qcache%';

运行结果解析:

  • Qcache_free_blocks: 表示查询缓存中还有多少剩余的blocks，如果该值显示较大，则说明查询缓存中的内存碎片过多了，可能在一定的时间进行整理;
  • Qcache_free_memory: 查询缓存的内存大小，通过这个参数可以很清晰的知道当前系统的查询内存是否够用,是多了，还是不够用，DBA可以根据实际情况做出调整;
  • Qcache_hits: 表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大，缓存效果越理想;
  • Qcache_inserts: 表示多少次未命中然后插入，意思是新来的SQL请求在缓存中未找到，不得不执行查询处理执行查询处理后把结果insert到查询缓存中。这样的情况的次数越多，表示查询缓存应用到的比较少，效果也就理想。当然系统刚启动后，查询缓存是空的，这很正常;
  • Qcache_lowmem_prunes: 该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值，用户可以适当的调整缓存大小;
  • Qcache_not_cached: 表示因为query_cache_type的设置而没有被缓存的查询数量;
  • Qcache_queries.in.cache: 当前缓存中缓存的查诎数量;
  • Qcache_total_blocks: 当前缓存的block数量;

2、解析器

如果没有命中查询缓存，就要开始真正执行语句了。 首先，MySQL需要知道要做什么，因此需要对SQL语句做解析，SQL语句的分析分为 词法分析 与 语法分析。

解析器 是对 SQL 语句进行语法分析、语义分析的服务层模块。

分析器先对 SQL语句 做 词法分析，分析 SQL语句是由多个字符串和空格组成的，MySQL 需要识别出里面的字符串分别是什么，代表什么，从 SQL语句的 “select” 这个关键字识别出来这是一个查询语句， 接着继续识别出查询内容（字段）、表名、查询条件 及 其它如排序、条数限制等信息；

接着，要做 语法分析 根据词法分析的结果，语法分析器（比如：Bison）会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。

如果你的语句不对，就会收到“You have an error in your SQL syntax”的错误提醒，比如下面这个语句 from 写成了rom:

1
2
3
4
5

# 语句：
select * rom test where id=1;

# 错误：
ERROR 1064 (42800 ) : You have an error in your SQL syntax; check the manual that corresponds toyour MySQL server version for the right syntax to use near 'fro test where id=1' at line 1

如果SQL语句正确，则会生成如下样式的一个语法树:

SQL语法分析的过程步骤：

3、优化器

在优化器中会确定 SQL 语句的执行路径，比如是根据全表检索，还是根据索引检索等，在查询优化器中，可以分为 逻辑查询优化阶段 和 物理查询优化阶段 。

  • 逻辑查询优化：就是通过改变SQL语句的内容来使得SQL查询更高效，同时为物理查询优化提供更多的候选执行计划。通常采用的方式是对SQL语句进行等价交换，对查询进行 重写，而查询重写的数学基础就是关系代数，是对条件表达式进行等价谓词重写、条件简化，对视图进行重写，对子查询进行优化，对连接语义进行了外连接消除、嵌套连接消除等。

  • 物理查询优化：是基于关系代数进行的查询重写，而关系代数的每一步都对应着物理计算，这些物理计算往往存在多种算法，因此需要计算各种物理路径的代价，从中选择代价最小的作为执行计划，在这个阶段里，对于单表和多表连接的操作，需要高效地使用索引，提升查询效率。

示例：

1
2
3
4
5
6

select * from test1 join test2 using(ID) where test1.name='zhangwei' and test2.name='mysql高级课程';
# 方案1：可以先从表 test1 里面取出 name='zhangwei'的记录的 ID 值，再根据 ID 值关联到表 test2，再判断 test2 里面 name的值是否等于 'mysql高级课程'。

# 方案2：可以先从表 test2 里面取出 name='mysql高级课程' 的记录的 ID 值，再根据 ID 值关联到 test1，再判断 test1 里面 name的值是否等于 zhangwei。

# 这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。

4、执行器

在执行之前需要判断该用户 是否具备权限，如果没有，就会返回权限错误；如果具备权限，就执行 SQL查询并返回结果（在 MySQL8.0 之前的版本，如果设置了查询缓存，这时会将查询结果进行缓存）。

如果有权限，就打开表继续执行，打开表的时候，执行器就会根据表的引擎定义，调用存储引擎API对表进行的读写，存储引擎API只是抽象接口，下面还有个存储引擎层，具体实现还是要看表选择的存储引擎。

比如在 InnoDB模式下的 select * from test where id=1; 查询中， 如果表 test 中的 id 字段没有索引，那么执行器的执行流程是这样的：

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

查询的完整流程架构如下图：

5、MySQL8中SQL执行原理

1）确认profiling 是否开启

1
2

mysql> select @@profiling;
mysql> show variables like 'profiling';

profiling=0 代表关闭，我们需要把 profiling 打开，即设置为 1：

1

mysql> set profiling=1;

2）多次执行相同SQL查询

1

mysql> select * from employees;

3）查看profiles

查看当前会话所产生的所有 profiles：

1

mysql> show profiles; # 显示最近的几次查询

4）查看profile

显示执行计划，查看程序的执行步骤：

1

mysql> show profile;

此外，还可以查询更丰富的内容：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Syntax:
SHOW PROFILE [type [ , type ] ... ]
	[ FOR QUERY n ]
	[LIMIT row_count [ OFFSET offset ] ]

type : {
	ALL -- 显示所有参数的开销信息
	BLOCK IO -- 显示IO的相关开销
	CONTEXT SWITCHES -- 上下文切换相关开销
	CPU -- 显示CPU相关开销信息
	IPC -- 显示发送和接收相关开销信息
	MEMORY -- 显示内存相关开销信息
	PAGE FAULTS -- 显示页面错误相关开销信息
	SOURCE -- 显示和Source_function, Source_file,Source_line相关的开销信息
	SWAPS -- 显示交换次数相关的开销信息
}

1

mysql> show profile cpu,block io for query 6;

6、MySQL5.7中SQL执行原理

1）查询缓存模式 默认是关闭的，要启用查询缓存需要 显式开启；

在 /etc/my.cnf 中新增一行：

1

query_cache_type=1

Tips: 修改配置后需要重启mysql服务

2）开启查询执行计划

1

mysql> set profiling=1;

3）执行语句两次：

1
2

mysql> select * from locations;
mysql> select * from locations;

4）查看profiles

5）查看profile 显示执行计划，查看程序的执行步骤：

1

mysql> show profile for query 1;


1

mysql> show profile for query 2;

执行编号2时，比执行编号1时少了很多信息，从截图中可以看出查询语句直接从缓存中获取数据。

2.3 SQL语法顺序

随着MySQL版本的更新换代，其优化器也在不断的升级，优化器会分析不同执行顺序产生的性能消耗不同而动态调整执行顺序。

需求：查询每个部门年龄高于20岁的人数且高于20岁人数不能少于2人，显示人数最多的第一名部门信息

下面是经常出现的查询顺序：

三、MySQL数据库缓冲池(buffer pool)

3.1 MySQL数据库缓冲池简介

InnoDB存储引擎是以页为单位来管理存储空间的，我们进行的 增删改查操作其实本质上都是在访问页面（包括读页面、写页面、创建新页面等操作）。而磁盘 I/O 需要消耗的时间很多，如果能在内存中进行操作，效率则会高很多，为了能让数据表或者索引中的数据随时被我们所用，DBMS 会申请占用内存来作为数据缓冲池，在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访问。

这样做的好处是可以让磁盘活动最小化，从而减少与磁盘直接进行 I/O 的时间。要知道，这种策略对提升 SQL 语句的查询性能来说至关重要。如果索引的数据在缓冲池里，那么访问的成本就会降低很多。

缓冲池（Buffer Pool）： 在InnoDB存储引擎中有一部分会放到内存中，缓冲池则占了这部分内存的大部分，它用来存储各种数据的缓存，包括：数据页、索引页、插入缓冲、锁信息、自适应 Hash 和 数据字典信息等。

Tips: MyISAM存储引擎 只缓存索引，不缓存数据，对应的键缓存参数为key_buffer_size

对于使用InnoDB 作为存储引擎的表来说，不管是用于存储用户数据的索引（包括聚簇索引和二级索引），还是各种系统数据，都是以 页 的形式存放在 表空间 中的，而所谓的表空间只不过是InnoDB对文件系统上一个或几个实际文件的抽象，也就是说存入数据库的数据说到底还是存储在磁盘上的。

但是，与CPU相比磁盘的读写速度很慢，因此使用缓冲池（页在内存中的副本）来提高CPU的读写速度，所以InnoDB存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中，也就是说即使只需要访问一个页的一条记录，那也需要先把整个页的数据加载到内存中。将整个页加载到内存中后进行读写访问，在进行完读写访问之后并不会立即把该页对应的内存空间释放掉，而是将其缓存起来，这样将来有请求再次访问该页面时，就可以省去磁盘IO的开销了。

缓存原则：位置 * 频次 这个原则，可以帮我们对 I/O 访问效率进行优化。

  • 首先，位置决定效率，提供缓冲池就是为了在内存中可以直接访问数据。
  • 其次，频次决定优先级顺序。因为缓冲池的大小是有限的，比如磁盘有 200G，但是内存只有 16G，缓冲池大小只有 1G，就无法将所有数据都加载到缓冲池里，这时就涉及到优先级顺序，会 优先对使用频次高的热数据进行加载。

缓冲池的作用就是为了提升I/O效率，在进行读取数据的时候存在一个 局部性原理，也就是说如果使用了某一些数据，大概率还会使用它周围的一些数据，因此采用 预读 的机制提前加载，可以减少未来可能的磁盘I/O操作， 这称为 缓冲池的预读特性。

Tips: 缓存池 不是查询缓存，查询缓存 是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。因为命中条件苛刻，而且只要数据表发生变化，查询缓存就会失效，因此命中率低。

3.2 缓冲池如何读取数据

缓冲池管理器会尽量将经常使用的数据保存起来，在数据库进行页面读操作的时候，首先会判断该页面是否在缓冲池中，如果存在就直接读取，如果不存在，就会通过内存或磁盘将页面存放到缓冲池中再进行读取。

Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。

黑盒下的更新数据流程：

  • 当查询数据的时候，会先去Buffer Pool中查询，如果Buffer Pool中不存在，存储引擎会先将数据（页）从磁盘加载到Buffer Pool中，然后将数据返回给客户端；同理，当更新某个数据的时候，如果这个数据不存在于Buffer Pool中，同样会先将数据（页）加载进来，然后修改内存中的副本数据，被修改过的数据会在之后统一刷入磁盘：

这个过程看似没啥问题，实则是有问题的。

  • 假设修改Buffer Pool中的数据成功，但是还没来得及将数据刷入磁盘MySQL就挂了怎么办?按照上图的逻辑，此时更新之后的数据只存在于Buffer Pool中，如果此时MySQL宕机了，这部分数据将会永久地丢失;
  • 更新到一半突然发生错误了，想要回滚到更新之前的版本，该怎么办？连数据持久化的保证、事务回滚都做不到还谈什么崩溃恢复？

答案：Redo Log & Undo Log

3.3 MySQL缓冲池相关配置

MySQL的 MyISAM存储引擎 只缓存索引，不缓存数据，对应的键缓存参数为key_buffer_size:

1
2
3
4
5

# 查看 MyISAM存储引擎 的键缓存参数
show variables like 'key_buffer_size';

# 设置 MyISAM存储引擎 的键缓存参数
set global key_buffer_size=268435456;

在系统配置文件 my.cnf 中设置MyISAM存储引擎 的键缓存参数

1
2

[server] 
innodb_buffer_pool_size = 268435456

MySQL的 InnoDB存储引擎，可以通过查看innodb_buffer_poll_size变量来查看/设置缓冲池的大小

1
2
3
4
5

# 查看 InnoDB存储引擎 的缓存池参数
show variables like 'innodb_buffer_pool_size';

#设置InnoDB存储引擎 的缓存池参数 
set global innodb_buffer_pool_size = 268435456;

在系统配置文件 my.cnf 中设置InnoDB存储引擎 的缓存池参数

1
2

[server] 
innodb_buffer_pool_size = 268435456

多个Buffer Pool实例：

Buffer Pool 的本质是InnoDB向操作系统申请的一块连续的内存空间，在多线程环境下，访问Buffer Pool中的数据都需要 加锁 处理。在Buffer Pool 特别大而且多线程并发访问特别高的情况下，单一的Buffer Pool 可能会影响请求的处理速度。所以多线程并发访问 在Buffer Pool特别大的时候，可以把它才分成若干个小的Buffer Pool，每个Buffer Pool都称为一个 实例，它们都是 独立的，独立的去申请内存空间，独立的管理各种链表，在多线程并发访问时并不会相互影响，从而提高并发处理能力。 MySQL 服务器通过设置innodb_buffer_pool_instances的值来修改 Buffer Pool实例的个数：

1
2
3
4
5

# 查看缓冲池的个数
show variables like 'innodb_buffer_pool_instances';

# 设置缓冲池的个数
set global innodb_buffer_pool_size = 268435456;

在系统配置文件 my.cnf 中设置InnoDB存储引擎 的缓存池参数

1
2

[server] 
innodb_buffer_pool_instances = 2

每个Buffer Pool实例实际占内存空间: innodb_buffer_pool_size/innodb_buffer_pool_instances 也就是总共的大小除以实例的个数，结果就是每个Buffer Pool实例占用的大小。

不过也不是说Buffer Pool实例创建的越多越好，分别管理各个Buffer Pool也是需要性能开销的，InnoDB规定: innodb_buffer_pool_size的值小于1G的时候设置多个实例是无效的, InnoDB会默认把innodb_buffer_pool_instances的值修改为1。只有在Buffer Pool大于或等于1G的时候设置多个Buffer Pool实例才有效。