MySQL的逻辑架构--逻辑架构剖析、SQL执行流程、数据库缓冲池(buffer pool)

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
全局流量管理 GTM,标准版 1个月
简介: MySQL的逻辑架构--逻辑架构剖析、SQL执行流程、数据库缓冲池(buffer pool)

逻辑架构剖析


8caea47376484e0f9481a737403588d2.png

Connectors

Connectors指的是不同语言与SQL的交互,本质上还是TCP连接


第一层:连接层

客户端访问MySQL服务器前,做的第一件事就是建立TCP连接

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

为了避免连接无线创建与TCP频繁创建销毁带来的资源耗尽、性能下降问题。MySQL服务器有专门的TCP连接池限制连接数,采用长连接模式复用TCP连接de388da6cfa34cb0995636fe279c7441.png

TCP连接收到请求后,必须分配给一个线程专门与这个客户端的交互,所以还有个线程池,每一个连接从线程池中获取线程,省去了创建和销毁线程的开销

所以连接管理的职责就是负责认证、管理连接、获取权限信息


第二层:服务层


SQL Interface:SQL接口

接收用户的SQL语句,并且返回用户需要的查询结果。

MySQL支持DML、DDL、存储过程等多种SQL语言的接口


Parser:解析器

在解析器中对SQL语句进行语法分析、语义分析。将SQL语句分解成数据结构,并将这个结构传递到后续步骤,以后SQL语句的传递和处理就是基于这个结构

在SQL命令传到解析器的时候会被解析器验证和解析,并为其创建语法树,并根据数据字典丰富查询语法树,会验证该客户端是否具有执行该查询的权限。创建好语法树后,MySQL还会对SQL查询进行语法上的优化,进行查询重写。


Optimizer:优化器

SQL语句在语法解析之后、查询之前会使用查询优化器确定SQL语句的执行路径,生成一个执行计划。

这个计划表明应该使用那些索引进行查询(全表检索还剩使用索引检索),表之间的连接顺序,最后会按照计划中的步骤调用存储引擎提供的方法来真正执行查询,并将结果返回给用户

使用选取-投影-连接策略进行查询


de388da6cfa34cb0995636fe279c7441.pngde388da6cfa34cb0995636fe279c7441.png

Caches&Buffers:查询缓存组件

MySQL内部维持着一些Cache和Buffer,比如Query Cache用来缓存一条SELECT语句的执行结果,如果能够在其中找到对应的查询结果,那么就不必再进行查询解析、优化和执行的整个过程,直接将结果反馈给客户端

这个缓存机制是由一系列小缓存组成的。比如表缓存,记录缓存,key缓存,权限缓存等

这个查询缓存可以在不同客户端共享

从MySQL5.7.20开始,不推荐使用查询缓存,并在MySQL8中删除


第三层:引擎层

和其他数据库相比,MySQL的架构可以在多种场景中应用并发挥良好的功能,主要体现在存储引擎的架构上,插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。插件式存储引擎层,真正的负责了MySQL中数据的存储和提取,对物理服务器级别维护的底层数据进行操作,服务器通过API与存储引擎进行通信。


存储层

所有的数据,数据库、表的定义,表的每一行内容,索引,都是存在文件上,以文件的形式存在的,并完成与存储引擎的交互。

SQL执行流程


MySQL的SQL执行流程

ac68ea122ce04bc28d265012e3decc45.png


MySQL的查询过程

1、查询缓存如果在查询缓存中发现了这条SQL语句,就会直接将结果返回给客户端;如果没有,就进入到解析器阶段。(可通过query_cache_type参数开关查询缓存 0 代表关闭OFF 1 代表开启 ON 3 代表DEMAND,sql语句有SQL_CACHE时)

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

分析器先做词法分析,MySQL需要识别出里面的字符串分别是什么,代表什么,从‘select’关键字识别出这是一个查询语句,它要把字符串T识别为表名T把ID识别为列名

接着是语法分析,根据词法分析结果,语法解析器会根据语法规则,判断输入的SQL语句是否满足MySQL语法

3、优化器在优化器中会确定SQL语句的执行路径,比如根据全表检索还是根据索引检索。经过了解析器,MySQL就知道你要做什么了,在开始执行前还要先经过优化器的处理。一条查询可以有很多种执行方式,最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。

在查询优化器中,可以分为逻辑查询优化阶段和物理查询优化阶段

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

物理查询优化基于关系代数进行的查询重写,而关系代数的每一步都对应着物理计算。在这个阶段里,对于单表和多表的连接操作,需要高效地使用索引,提升查询效率。

4、执行器在执行之前需要判断该用户是否具备权限,如果没有就会返回权限错误。如果有权限,就打开表继续执行,执行器会根据表的引擎定义,调用存储引擎API对表进行读写。存储引擎API只是抽象接口,下面还有个存储引擎层


MySQL中的执行原理

了解查询语句底层执行的过程:select @@profiling;或者show variables like '%profiling%'查看是否开启了计划。开启它可以让mysql手机在SQL执行时所使用的资源情况

a39ab3447f2148128c2d567f0a50a3ea.pngc1cd15c653a14de092c5e7165406c59f.png

查看最近一条

63f39778953e447b94ca614f22dfc453.png

查看指定一条

f22b7462aba74482bf7050897f614f7f.png


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 --显示交换次数相关开销信息


数据库缓冲池(buffer pool)


InnoDB存储引擎是以页为单位来管理存储空间的,我们进行的增删改查操作其实本质上都是在访问页面。而磁盘I/O需要消耗的时间很多,而在内存中进行操作,效率则会高很多,为了能让数据表或者索引数据被我们所用,DBMS会申请占用内存来作为数据缓冲池,在真正访问页面之前,需要把磁盘上的页缓存到内存中的buffer pool之后才能访问,从而让磁盘活动最小化,减少与磁盘直接进行I/O的时间。

缓冲池vs查询缓存

4c687c63df5e4fe7896795a155248804.png


缓存原则

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

首先位置决定效率,提供缓冲池就是为了在内存中可以直接访问数据

其次,频次决定优先级顺序。因为缓冲池的大小是有限的,会优先对使用频次高的热数据进行加载


缓冲池的预读特性

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


查询缓存

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

缓冲池服务于数据库整体的I/O操作,它们的共同点都是通过缓存的机制来提升效率


缓存池如何读取数据

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

01e2dda03df44b52b7d1a17076f97606.png

如果我们执行SQL语句的时候更新了缓冲池中的数据,那么这些数据会马上同步到磁盘吗?

实际上,当我们对数据库中的记录进行修改的时候,首先会修改缓冲池中页里面的记录信息,然后数据库会以一定的频率刷新到磁盘。缓冲池会采用一种叫做checkpoint的机制将数据回写到磁盘上。

当缓冲池不够用时,需要释放掉一些不常用的页,此时就可以强行采用checkpoint的方式,将不常用的脏页回写到磁盘上,然后再从缓冲池中将这些页释放掉。


查看/设置缓冲池的大小

可以使用innodb_buffer_pool_size变量来查看缓冲池的大小

show variables like ‘innodb_buffer_pool_size’

修改缓冲池大小

set global innodb_buffer_pool_size =

多个Buffer Pool实例

Buffer Pool的本质是InnoDB向操作系统申请的一块连续的内存空间,在多线程环境下,访问Buffer pool中的数据都需要加锁处理。在Buffer pool特别大而且多线程并发访问特别高的情况下,单一的Buffer Pool可能影响处理的请求速度。所以在Buffer Pool特别大的时候,我们可以把它们差分成若干个小的Buffer Poll,它们独立出去,独立申请内存空间,独立的管理各种链表,从而提高并发处理能力


innodb_buffer_pool_instance = 2

查看缓冲池个数

show variables like ‘innodb_buffer_pool_instances’

873cc92936174433802fe398ecee3d28.png


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
2月前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
2月前
|
设计模式 缓存 关系型数据库
探索微服务架构中的数据库设计挑战
微服务架构因其模块化和高扩展性被广泛应用于现代软件开发。然而,这种架构模式也带来了数据库设计上的独特挑战。本文探讨了在微服务架构中实现数据库设计时面临的问题,如数据一致性、服务间的数据共享和分布式事务处理。通过分析实际案例和提出解决方案,旨在为开发人员提供有效的数据库设计策略,以应对微服务架构下的复杂性。
|
2月前
|
消息中间件 缓存 监控
优化微服务架构中的数据库访问:策略与最佳实践
在微服务架构中,数据库访问的效率直接影响到系统的性能和可扩展性。本文探讨了优化微服务架构中数据库访问的策略与最佳实践,包括数据分片、缓存策略、异步处理和服务间通信优化。通过具体的技术方案和实例分析,提供了一系列实用的建议,以帮助开发团队提升微服务系统的响应速度和稳定性。
|
13天前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
14天前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
6天前
|
存储 NoSQL 分布式数据库
微服务架构下的数据库设计与优化策略####
本文深入探讨了在微服务架构下,如何进行高效的数据库设计与优化,以确保系统的可扩展性、低延迟与高并发处理能力。不同于传统单一数据库模式,微服务架构要求更细粒度的服务划分,这对数据库设计提出了新的挑战。本文将从数据库分片、复制、事务管理及性能调优等方面阐述最佳实践,旨在为开发者提供一套系统性的解决方案框架。 ####
|
9天前
|
消息中间件 数据库 云计算
微服务架构下的数据库事务管理策略####
在微服务架构中,传统的单体应用被拆分为多个独立的服务单元,每个服务维护自己的数据库实例。这种设计提高了系统的可扩展性和灵活性,但同时也带来了分布式环境下事务管理的复杂性。本文探讨了微服务架构下数据库事务的挑战,并深入分析了几种主流的事务管理策略,包括Saga模式、两阶段提交(2PC)以及基于消息的最终一致性方案,旨在为开发者提供一套适应不同业务场景的事务处理框架。 ####
|
9天前
|
设计模式 存储 缓存
微服务架构下的数据库设计策略
本文探讨了在微服务架构中进行数据库设计时,如何平衡数据的一致性、独立性与系统整体性能之间的关系。文章首先介绍了微服务架构的基本概念及其对数据库设计的影响,随后深入分析了三种主流的数据库设计模式——集中式、去中心化和混合模式,并结合实际案例讨论了它们的适用场景与优缺点。此外,还提出了一系列最佳实践建议,旨在帮助开发者更好地应对微服务环境下的数据管理挑战。
|
2月前
|
SQL 缓存 关系型数据库
揭秘MySQL一条SQL语句的执行流程
以上步骤共同构成了MySQL处理SQL语句的完整流程,理解这一流程有助于更有效地使用MySQL数据库,优化查询性能,及时解决可能出现的性能瓶颈问题。
90 7
|
2月前
|
消息中间件 缓存 监控
优化微服务架构中的数据库访问:策略与实践
随着微服务架构的普及,如何高效管理和优化数据库访问成为了关键挑战。本文探讨了在微服务环境中优化数据库访问的策略,包括数据库分片、缓存机制、异步处理等技术手段。通过深入分析实际案例和最佳实践,本文旨在为开发者提供实际可行的解决方案,以提升系统性能和可扩展性。