1. MySQL logical architecture
Before starting to learn MySQL, drawing a basic logical architecture diagram of MySQL is helpful for us to learn MySQL.
The following is the modified result of the MySQL logical architecture diagram provided by Lin Xiaobin (screen name Ding Qi) in "MySQL 45 Lectures", the cache query part is deleted (this module is removed after MySQL 8.0).
2. Server layer components
2.1. Connector
Connectors are an architecture that most network-based client/server tools have. Mainly responsible for client connection establishment, permission acquisition, authorization authentication and connection management.
The client initiates a connection command to the MySQL server, which will perform permission verification (user name, password, etc.). After the verification is completed, the server establishes a thread for the connection.
After the connection is established, the connector will query the permissions in the permission table. At this time, the permissions have been determined, and subsequent permission determinations depend on the permissions at this time. Even if the administrator account modifies the permissions, it will not affect The permissions of the established connection will change until the next time the connection is reconnected.
Short and long connections
We often hear short and long connections. In essence, MySQL does not provide these two types of connections. These two types of connections are also defined based on the length of time you stay connected.
The execution process of the short connection:
The execution process of the long connection:
Maintaining a connection is to avoid performance loss caused by frequent authorization verification, authorization query, etc. If your business will frequently interact with the database, then after the connection is established, it will be placed in the connection pool and will be taken out when needed. use.
If you only need to query once a day (such as scheduling tasks), then disconnect the connection in time after the query is completed, which can reduce the performance loss caused by idle connections.
Idle connection
After the connection is established, if it is not used for a long time, the connection is in the Sleep state, and an idle connection is generated at this time.
You can use the following command to view the current link:
show processlist;
At this time, there are 3 root user connections in my MySQL. Among them, the connection with ID=459 is active. As for the other two connections, they are in the Sleep state, which are two idle connections.
As for the connection maintained by the event_scheduler with ID=5, it can also be seen from Daemon that this is a daemon process. event_scheduler, event scheduler, a new function added in MySQL 5.1, replacing part of the scheduling tasks that can only be done in the operating system task scheduler.
Automatically disconnect
If you don't actively disconnect, will it stay forever?
The MySQL connector will automatically disconnect connections that have not been used for a long time. This time parameter is determined by wait_timeout.
You can use the following command to view wait_timeout:
show variables like 'wait_timeout';
Connection optimization
Establishing a MySQL connection is a complicated process. If you create a connection frequently, it consumes a lot of memory.
This is because the memory temporarily used by MySQL during execution is managed in the connection object. These resources will be released when the connection is disconnected. If the long connection accumulates, it may cause too much memory usage and be forcibly killed by the system. Out (OOM), from the perspective of the phenomenon, MySQL restarts abnormally. – Lin Xiaobin, "45 Lectures on MySQL Actual Combat"
At the same time, Lin Xiaobin provided two suggestions:
- Regularly disconnect idle long connections and re-establish the connection to release resources;
- After executing a query that occupies a large amount of memory, use mysql_reset_connection (command provided after MySQL 5.7) to reset the connection resource. This process does not require reconnection and re-authentication, but the connection will be restored to the initial state.
2.2. Analyzer
Before MySQL 8.0, MySQL provided a cache query. Only SQL statements that could not be hit by the cache would enter the analysis-optimization-execution process. However, for data, the data that is frequently queried usually changes frequently, and the changes are less frequent. It does not query frequently, so the cache hit rate is very low. MySQL officials are also aware of this, so the cache module is deleted in MySQL 8.0 (since you do not enable the cache, then I will delete it).
The analyzer is used to parse SQL statements and build internal data structures (parse trees). The analyzer can be divided into two parts: the lexical analyzer and the syntax analyzer .
The lexical analyzer is used to build a parse tree. E.g:
select user_name from user;
Under the work of the parser, it will recognize:
- select, query statement;
- from user, query table user;
- user_name, get the value of the column user_name.
The syntax analyzer is used to verify whether the input SQL statement is correct.
Usually the "You have an error in your SQL syntax" we see is discovered and prompted by the syntax parser.
2.3. Optimizer
After the work of the analyzer is completed, the optimizer is next to work. The optimizer is mainly responsible for: rewriting queries, reading order of tables, selecting appropriate indexes, etc.
Usually, after the optimizer, MySQL has got an optimal execution plan (but it's not absolute), and then the executor will execute the SQL statement.
If we want to know how the optimizer makes decisions, we can ask the optimizer to explain, such as:
-- 表结构
CREATE TABLE `t_user` (
`user_id` bigint NOT NULL AUTO_INCREMENT,
`user_name` varchar(20) DEFAULT NULL,
`age` int DEFAULT NULL,
`gender` varchar(2) DEFAULT NULL,
`address` varchar(100) DEFAULT NULL,
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
-- 查看执行计划
explain select * from user where id = 1;
You can see that MySQL chose to use the primary key after optimization by the optimizer (the specific execution plan will be analyzed later).
However, the choice of the optimizer is not the best under extremely small probability. We can view the execution plan, view the choice of the optimizer, and "lead" the optimizer to re-select according to the result.
Although the optimizer does not care about the underlying storage engine, in fact, the choice of the optimizer will be affected by the storage engine.
In the process of optimization by the optimizer, the storage engine will be requested to provide capacity, operating overhead, statistical information of table data, and so on. And as the optimizer's selection dimension, to optimize the SQL statement.
2.4. Actuator
After experiencing the analyzer and optimizer, it is time for the SQL statement to be executed.
At the beginning of execution, the executor will judge the permissions. If there is no execution permission, it will return an error of no permission (before MySQL 8.0, the query cache will also verify the permissions).
The executor realizes query, modification and deletion by calling the interface of the storage engine.