幕后藏着什么莫测高深的绝密

时间:2020-03-13 17:18来源:亚洲城ca88唯一官方网站
时间: 2019-12-31阅读: 53标签: java 1.MySQL整体逻辑架构 作为一名 Java开发人员,写 SQL 语句是常有的事,但是你知道 SQL语句背后的处理逻辑吗?比如下面这条 SQL 语句: 我们先下图看看MyS

时间: 2019-12-31阅读: 53标签: java

1.MySQL整体逻辑架构

作为一名 Java开发人员,写 SQL 语句是常有的事,但是你知道 SQL 语句背后的处理逻辑吗?比如下面这条 SQL 语句:

我们先下图看看MySQL整体逻辑架构(MySQL’s Logical Architecture)

select * from user where id=1

图片 1

执行完这条语句后,我们就会得到 id 为 1 的用户信息。那么对于这一条 SQL 语句,MySQL服务器做了哪些处理呢?这篇文章我们就一起打卡 MySQL 数据库中对 SQL 语句的处理逻辑。

                      图1 

了解 MySQL 数据库的 SQL 语句内部处理逻辑有什么好处?当我们碰到 MySQL 的一些异常或者问题时,就能够直戳本质,更为快速地定位并解决问题。

第一层,即最上一层,所包含的服务并不是MySQL所独有的技术。它们都是服务于C/S程序或者是这些程序所需要的 :连接处理,身份验证,安全性等等。

想要更好的了解 SQL 语句的内部处理逻辑,我们可以先看 MySQL 的基本架构图,这样我们可以站在更高的角度去俯瞰 MySQL 数据库,MySQL 的基本架构示意图如下:

第二层值得关注。这是MySQL的核心部分。通常叫做 SQL Layer。在 MySQL据库系统处理底层数据之前的所有工作都是在这一层完成的,包括权限判断, sql解析,行计划优化, query cache 的处理以及所有内置的函数(如日期,时间,数学运算,加密)等等。各个存储引擎提供的功能都集中在这一层,如存储过程,触发器,视 图等。

从图中,我们可以清晰的看出 MySQL 的架构和各个模块以及 SQL 语句的执行过程,MySQL 数据库整体可以分为 Server 层和存储引擎层两部分,其中 Server 层是共有的,而存储引擎层则是可以以插件的形式进行扩展。一条 SQL 语句大概会经历链接管理、解析与优化、最后到存储引擎,这三个模块。接下来我们就来聊一聊这三个模块。

第三层包括了存储引擎。通常叫做StorEngine Layer ,也就是底层数据存取操作实现部分,由多种存储引擎共同组成。它们负责存储和获取所有存储在MySQL中的数据。就像Linux众多的文件系统 一样。每个存储引擎都有自己的优点和缺陷。服务器是通过存储引擎API来与它们交互的。这个接口隐藏 了各个存储引擎不同的地方。对于查询层尽可能的透明。这个API包含了很多底层的操作。如开始一个事 物,或者取出有特定主键的行。存储引擎不能解析SQL,互相之间也不能通信。仅仅是简单的响应服务器 的请求。

连接管理

连接管理和安全

连接管理是 SQL 语句执行过程中碰到的第一关,链接管理就像一扇大门一样,控制着客户端与 Server 服务端的交互,连接管理主要工作是客户端的身份认证和连接线程的管理。

在服务器内部,每个client连接都有自己的线程。这个连接的查询都在一个单独的线程中执行。这些线程轮流运行在某一个CPU内核(多核CPU)或者CPU中。服务器缓存了线程,因此不需要为每个client连接单独创建和销毁线程 。

每个客户端与 Server 建立连接时,服务端都会创建一个线程来与客户端进行交互,交互的第一项内容就是验证客户端的身份,认证凭据是基于客户端发起连接请求时携带的主机信息、用户名、密码。如果认证失败,则结束连接任务,并且返回的Access denied for user错误。

当clients(也就是应用程序)连接到了MySQL服务器。服务器需要对它进行认证(Authenticate)。认证是基于用户名,主机,以及密码。对于使用了SSL(安全套接字层)的连接,还使用了X.509证书。clients一连接上,服务器就验证它的权限 (如是否允许客户端可以查询world数据库下的Country表的数据)。

如果认证成功,连接管理还会做一件事情,到权限表中查询出该用户的权限,在这次连接下,后续的权限判断都是基于此时读取的权限为依据,也就是说连接成功后,即使管理员对这个用户做了权限修改,也不会影响这次连接的权限验证。

优化和执行

连接管理需要做的事情就比较简单,主要是负责客户端与服务端进行连接,当然在连接线程上,连接管理也做了优化,并不是每个客户端执行完任务之后,就把该线程销毁,连接管理会把这些线程缓存起来,等待新的连接,这也就不会频繁的创建和销毁线程,从而节约了开销。

MySQL会解析查询,并创建了一个内部数据结构(解析树)。然后对其进行各种优化。这些优化包括了,查询语句的重写,读表的顺序,索引的选择等等。用户可以通过查询语句的关键词传递给优化器以便提示使用哪种优化方式,这样即影响了优化器的优化方式。另外,用户也可以请求服务器给出优化过程的各种说明,以获知服务器的优化策略,为用户提供了参数基准,以便用户可以重写查询,架构和修改相关服务器配置,便于mysql更高效的运行。

解析与优化

优化器并是不关心表使用了哪种存储引擎,但是存储引擎对服务器优化查询的方式是有影响的。优化器需要知道存储引擎的一些特性:具体操作的性能和开销方面的信息,以及表内数据的统计信息。例如,存储引擎支持哪些索引类型,这对于查询是非常有用的。

完成连接管理之后,SQL 语句执行的第二步就是解析和优化,这一步就非常的复杂,SQL 语句查询的所有操作都在这里了。我们可以将这一步细分为 4 小步。

在解析查询之前,要查询缓存,这个缓存只能保存查询信息以及结果数据。如果请求一个查询在缓存 中存在,就不需要解析,优化和执行查询了。直接返回缓存中所存放的这个查询的结果。

查询缓存

2.MySQL逻辑模块组成

在 MySQL 服务端也有缓存,这是一个非常鸡肋的功能,为什么呢?看完了你就知道了。

虽然从上图1看起来 MySQL 架构非常的简单,就是简单的两部分而已,但实际上每一层 中都含有各自的很多小模块,尤其是第二层 SQL Layer ,结构相当复杂的。下面我们就分别 针对 SQL Layer 和 Storage Engine Layer 做一个简单的分析。我们看下图体系结构:

MySQL 服务器拿到查询请求后,会先到查询缓存看看,之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式,被直接缓存在内存中。key 是查询的语句,value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key,那么这个 value 就会被直接返回给客户端。如果语句不在查询缓存中,就会继续后面的执行阶段。执行完成后,执行结果会被存入查询缓存中。

图片 2

看上去没毛病,这样做会大大提升 MySQL 的性能,然而,你想多了,MySQL 的查询缓存命中率非常的低,主要原因是如果两个查询请求在任何字符上的不同(例如:空格、注释、大小写),都会导致缓存不会命中。

                                                          图2

还有就是缓存有可能获取到错误的数据,以某些系统函数举例,可能同样的函数的两次调用会产生不一样的结果,比如函数NOW,每次调用都会产生最新的当前时间,如果在一个查询请求中调用了这个函数,那即使查询请求的文本信息都一样,那不同时间的两次查询也应该得到不同的结果,如果在第一次查询时就缓存了,那第二次查询的时候直接使用第一次查询的结果就是错误的!

1.Connectors

指的是不同语言中与SQL的交互

除了这些之外,MySQL 缓存的失效也非常的频繁,MySQL的缓存系统会监测涉及到的每张表,只要该表的结构或者数据被修改,如对该表使用了 INSERT、 UPDATE、DELETE、TRUNCATE TABLE、ALTER TABLE、DROP TABLE 或 DROP DATABASE 语句,那使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除!

2 Management Serveices & Utilities: 

系统管理和控制工具

看到这里你知道查询缓存很鸡肋了吧,缓存对 MySQL 数据库来说弊大于利,所以在 MySQL 8.0 版本直接将查询缓存的整块功能删掉了

3 Connection Pool: 连接池

管理缓冲用户连接,线程处理等需要缓存的需求。

负责监听对 MySQL Server 的各种请求,接收连接请求,转发所有连接请求到线程管理模块。每一个连接上 MySQL Server 的客户端请求都会被分配(或创建)一个连接线程为其单独服务。而连接线程的主要工作就是负责 MySQL Server 与客户端的通信,
接受客户端的命令请求,传递 Server 端的结果信息等。线程管理模块则负责管理维护这些连接线程。包括线程的创建,线程的 cache 等。

语法解析和预处理

4 SQL Interface: SQL接口。

接受用户的SQL命令,并且返回用户需要查询的结果。比如select from就是调用SQL Interface

如果查询缓存没有命中,接下来就需要进入正式的查询阶段了。因为客户端程序发送过来的请求只是一段文本而已,所以 MySQL 服务器程序首先要对这段文本做语法解析。

5 Parser: 解析器。

SQL命令传递到解析器的时候会被解析器验证和解析。解析器是由Lex和YACC实现的,是一个很长的脚本。

在 MySQL中我们习惯将所有 Client 端发送给 Server 端的命令都称为 query ,在 MySQL Server 里面,连接线程接收到客户端的一个 Query 后,会直接将该 query 传递给专门负责将各种 Query 进行分类然后转发给各个对应的处理模块。
主要功能:
a . 将SQL语句进行语义和语法的分析,分解成数据结构,然后按照不同的操作类型进行分类,然后做出针对性的转发到后续步骤,以后SQL语句的传递和处理就是基于这个结构的。
b.  如果在分解构成中遇到错误,那么就说明这个sql语句是不合理的

首先通过关键字将 SQL 语句进行解析,并且生成一个“解析树”。MySQL 解析器将使用 MySQL 语法规则验证和解析查询,例如,关键字是否使用正确、关键字的顺序是否正确或者引号是否前后匹配等。

6 Optimizer: 查询优化器。

SQL语句在查询之前会使用查询优化器对查询进行优化。就是优化客户端请求的 query(sql语句) ,根据客户端请求的 query 语句,和数据库中的一些统计信息,在一系列算法的基础上进行分析,得出一个最优的策略,告诉后面的程序如何取得这个 query 语句的结果

他使用的是“选取-投影-联接”策略进行查询。
       用一个例子就可以理解: select uid,name from user where gender = 1;
       这个select 查询先根据where 语句进行选取,而不是先将表全部查询出来以后再进行gender过滤
       这个select查询先根据uid和name进行属性投影,而不是将属性全部取出以后再进行过滤
       将这两个查询条件联接起来生成最终查询结果

预处理是根据一些 MySQL 规则进一步检查解析树是否合法,例如数据表和数据列是否存在,还会解析名字和别名,看看他们是否有歧义等。

7 Cache和Buffer: 查询缓存。

他的主要功能是将客户端提交 给MySQL 的 Select 类 query 请求的返回结果集 cache 到内存中,与该 query 的一个 hash 值 做
一个对应。该 Query 所取数据的基表发生任何数据的变化之后, MySQL 会自动使该 query 的Cache 失效。在读写比例非常高的应用系统中, Query Cache 对性能的提高是非常显著的。当然它对内存的消耗也是非常大的。

如果查询缓存有命中的查询结果,查询语句就可以直接去查询缓存中取数据。这个缓存机制是由一系列小缓存组成的。比如表缓存,记录缓存,key缓存,权限缓存等

查询优化

8 、存储引擎接口

存储引擎接口模块可以说是 MySQL 数据库中最有特色的一点了。目前各种数据库产品中,基本上只有 MySQL 可以实现其底层数据存储引擎的插件式管理。这个模块实际上只是 一个抽象类,但正是因为它成功地将各种数据处理高度抽象化,才成就了今天 MySQL 可插拔存储引擎的特色。

     从图2还可以看出,MySQL区别于其他数据库的最重要的特点就是其插件式的表存储引擎。MySQL插件式的存储引擎架构提供了一系列标准的管理和服务支持,这些标准与存储引擎本身无关,可能是每个数据库系统本身都必需的,如SQL分析器和优化器等,而存储引擎是底层物理结构的实现,每个存储引擎开发者都可以按照自己的意愿来进行开发。
    注意:存储引擎是基于表的,而不是数据库。

语法解析和预处理之后,你的需求就明白了,需要查询哪张表,查询的数据列是哪些、条件是什么等等。但是使用怎么样的方式是最优查询方式呢?查询优化就是来干这个事的,MySQL 的优化程序会对我们的语句做一些优化,如外连接转换为内连接、表达式简化、子查询转为连接等等。优化的结果就是生成一个执行计划,这个执行计划表明了应该使用哪些索引进行查询,表之间的连接顺序是啥样的。

执行器

执行器会执行查询优化后的执行计划,通过与存储引擎交互,完成数据的查询操作,返回最终的数据结果。

开始执行的时候,要先判断一下你对这个表 T 有没有执行查询的权限,如果没有,就会返回没有权限的错误,如下所示 (在工程实现上,如果命中查询缓存,会在查询缓存返回结果的时候,做权限验证。查询也会在优化器之前调用 precheck 验证权限)。

mysql select * from user where ID=1;ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'

如果有权限,就打开表继续执行。打开表的时候,执行器就会根据表的引擎定义,去使用这个引擎提供的接口。

比如我们这个例子中的表 user 中,假设 ID 字段没有索引,那么执行器的执行流程是这样的:

1、调用 InnoDB 引擎接口取这个表的第一行,判断 ID 值是不是 10,如果不是则跳过,如果是则将这行存在结果集中;

2、调用引擎接口取“下一行”,重复相同的判断逻辑,直到取到这个表的最后一行。

3、执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

到这里,执行 SQL 语句就执行完了,其实这内部还是非常复杂的。

存储引擎

到上面为止,SQL 语句就执行完了,但是与真实数据打交道的是存储引擎,存储引擎是 MySQL服务器对数据的存储和提取操作的封装模块。我们知道表是由一行一行的记录组成的,但这只是一个逻辑上的概念,物理上如何表示记录,怎么从表中读取数据,怎么把数据写入具体的物理存储器上,这都是存储引擎负责的事情。

为了实现不同的功能,MySQL提供了各式各样的存储引擎,不同存储引擎管理的表具体的存储结构可能不同,采用的存取算法也可能不同。比如,MySQL5.7 之后默认的 InnoDB 存储引擎。

可以看出一条 SQL 语句的执行还是非常复杂的,涉及到了很多的模块,文章到这里就结束了,感谢您的阅读,希望这篇文章对你的学习和工作有所帮助,如果您觉得文章有用,欢迎点赞 转发。

最后

目前互联网上很多大佬都有 MySQL 内部架构相关文章,如有雷同,请多多包涵了。原创不易,码字不易,还希望大家多多支持。若文中有所错误之处,还望提出,谢谢。

欢迎扫码关注微信公众号:「平头哥的技术博文」,和平头哥一起学习,一起进步。

编辑:亚洲城ca88唯一官方网站 本文来源:幕后藏着什么莫测高深的绝密

关键词: 亚洲城ca88