MySQL architecture and SQL execution process

Preface

If you can only write sql statements when using MySQL, then you should read "The underlying logic of MySQL optimization". If you only know how sql is optimized, then you should learn about the architecture of Mysql and the execution process of sql statements through this article.

Architecture

Let’s first look at the architecture of MySQL. The picture below was taken from the official MySQL website, so it is highly authoritative and accurate.

Through this picture, we can intuitively see the internal structure of MySQL, including connectors, caches, parsers, optimizers, storage engines, and SQL interfaces that support DDL, DML, stored procedures, views and other functions. Next, through the execution of a sql statement, we will have an in-depth understanding of the functions and functions of each component of MySQL.

SQL statement execution flow

1. Connect to MySQL

Usually we write sql statements to execute through a client and accept the execution results, such as command line, JDBC, navicat. However, you must successfully establish a connection with the MySQL service before execution. This is the job of "Connector".

Here, the MySQL service is connected through the command line. The command is as follows:

mysql -h127.0.0.1 -uroot -p

The command connects to the local MySQL service. After entering the password, the connector will verify the user and password. If the verification fails, the client will respond with an access denial message.

After successful verification, the connector will successfully establish a connection with the client and read the user's permissions. The user's subsequent operations will be controlled based on permissions.

So where are usernames and passwords and permissions stored?

In MySQL, in addition to the business libraries created by developers, there are also system libraries that support its own operation, including mysql, sys, performance_schema, and information_schema. User information is stored in the mysql library.

Of course, the number of MySQL connections is also limited, which can be controlled through the max_connections parameter.

MySQL [mysql]> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 1215  |
+-----------------+-------+

You can also view the currently connected clients through show processlist.

MySQL [mysql]> show processlist;
+------+------+-----------------+-------+---------+------+----------+------------------+
| Id   | User | Host            | db    | Command | Time | State    | Info             |
+------+------+-----------------+-------+---------+------+----------+------------------+
| 1156 | root | 127.0.0.1:61223 | mysql | Query   |    0 | starting | show processlist |
+------+------+-----------------+-------+---------+------+----------+------------------+

2. Query cache

When the connection is successfully established, the client can send sql statements to the MySQL service. "SQL interface" is just like what we wrote The Controller will also receive the sql statement. If it is a select statement, it will retrieve the result in "cache" and respond to client.

Some blogs say that the cache is queried after parsing. This statement is not rigorous. Here is the official explanation: "If the same statement is received, the server will retrieve the result from the query cache instead of parsing and executing the statement again. statement"

Also in this description you can see "Starting with MySQL 5.7.20, the query cache has been deprecated and removed in MySQL 8.0.< a i=2>" this comment. According to the official statement, " Caching is only suitable for scenarios where the table data does not change frequently. If the table data is updated frequently (obviously most of them are this scenario), the cache hit rate will be low, coupled with frequent Maintaining the cache sometimes causes more problems than it solves, making the cache function seem useless.”

3. Parse SQL statements

After is cached, the " parser" starts working. The purpose of the parser is to check whether the sql statement is correct and to The sql statement is parsed into a structure that MySQL can understand, which is the sql syntax tree.

Likeselect1 id from table1 This sql statement will cause an error when parsing, because the keyword select is not recognized (for column names and table names) Checking and verification are in the preprocessing stage).

And like select id from table1 this sql statement will be parsed into the following picture:

If you want to know the specific parsing process, you can refer tothis blog

4. Optimize SQL statements

After generating the sql syntax tree through the parser, it comes to the "Optimizer" stage. How to execute sql, without using index, and using Which index is processed at this stage is written in "The Underlying Logic of MySQL Optimization" , so I won’t go into details here.

5. Execute SQL statements

After passing through "Optimizer", an optimal execution plan is finally generated and handed over to " for execution The executor obtains data by calling the interface of "Storage Engine", which will not be expanded here. The interaction between the executor and the storage engine will be explained in detail in a later article.

Summarize

At this point, the execution process of a query statement has been very clear, and at the same time, the entire architecture of MySQL and the role of each component have been understood. Finally, use a picture to end the core content of this article and summarize it.

The execution flow of a query SQL statement:

1. The client connects to the MySQL service through the connector.
2. After the connection is successful, a SQL statement request is sent to the SQL interface.
3. When the SQL interface receives a SQL query statement, it will first cache the query. If there is a hit, it will be returned to the client, otherwise it will be handed over to the parser.
4. After getting the SQL statement, the parser will determine whether the syntax is correct. If it is correct, it will generate a SQL syntax tree and hand it over to the optimizer. Otherwise, an error will be reported to the client.
5. The optimizer will generate an optimal execution plan based on the SQL syntax tree and hand it over to the executor for execution.
6. The executor gets the execution plan and calls the storage engine to obtain data and respond to the client.
7. Finish! ! !