select * from user this SQL statement, what dark secrets hidden behind?

As a Java developer, to write SQL statements are common, but you know SQL statement processing logic behind it? For example, this SQL statement:

select * from user where id=1

After executing this statement, we will get the information for the user id 1. So for this one SQL statement, MySQL server what had been done to deal with it? This article we take a punch MySQL database processing logic of SQL statements.

Learn MySQL database SQL statements internal processing logic What are the benefits? When we encounter some unusual problems or MySQL, it can Zhichuo nature, more quickly locate and resolve problems .

Understand the logic of the internal processing of SQL statements want better, we can look at the basic architecture diagram MySQL, so that we can stand on a higher point of view to overlook the MySQL database, MySQL's basic architecture diagram is as follows:

The basic architecture diagram of MySQL

From the figure, we can clearly see that MySQL architecture and modules as well as the execution of SQL statements, MySQL database as a whole can be divided into two parts Server layer and the storage layer engine, which is shared by Server layer, and the layer of the storage engine It can be extended in the form of plug-ins. SQL statement will probably experience a link management, analysis and optimization, and finally to the storage engine, the three modules. Next we come to chat with these three modules.

Connection Management

Connection Manager is the first hurdle in the implementation process SQL statements encountered, Link Manager is like a door, like, controls the interaction client and Server server, the connection management main job is to manage the client's identity and connection threads.

Each client establishes a connection with the Server, the server will create a thread to interact with the client, the first interactive content is to verify the client's identity, the authentication credentials are based on the client host initiates a connection request information carried, Username Password. If the authentication fails, the task to end the connection, and returns the Access denied for usererror.

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

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

解析与优化

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

查询缓存

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

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

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

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

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

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

语法解析和预处理

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

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

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

查询优化

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

执行器

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

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


mysql> select * from user where ID=1;

ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'

If you have permission, you open the table to continue. Open the table, the actuator will be defined according to the engine table, use the interface to the engine.

Such as our example table user, assuming ID field is not indexed, then the execution flow actuator is this:

1, the engine interface calls InnoDB take the first row, it is determined ID value is not 10, if it is not skipped, if then there is a line in the result set;

2, the engine interface calls take "next row", the logic repeats the same determination until get to the last row of the table.

3, the actuator will traverse the above-described process for all rows satisfy the condition as a set of records composed of the result set returned to the client.

Here, execute SQL statements on the execution finished, in fact, this interior is still very complicated.

Storage Engine

Until the above, SQL statements executed over, but dealing with real data storage engine, the storage engine for the MySQL server data storage and retrieval module packaging operations. We know the table is composed of records line by line, but this is only a logical concept, how to represent the physical records, how to read data from the table, how the data is written on a specific physical memory, which is memory engine responsible thing.

In order to achieve different functions, MySQL provides a wide variety of storage engine, the specific table storage structure may be different in different storage engine access algorithm may be different. For example, the default after MySQL5.7 InnoDB storage engine.

It can be seen execute a SQL statement is very complex, involving a number of modules, the article to end here, thank you for reading, I hope this article help you study and work, if you feel article useful welcome thumbs up + forward.

At last

Currently on the Internet has a lot of heavyweights MySQL internal architecture related articles, any similarity, please forgive me up. The original is not easy, the code word is not easy, but also hope that we can support. If something incorrect in the text, but also look made, thank you.

Welcome scan code concern micro-channel public number: learn together "flat head brother's technology blog," the first Colombian peace, progress together.

Flathead brother of technical Bowen

Guess you like

Origin www.cnblogs.com/jamaler/p/12122813.html