How each module works together in MySQL

MySQL each module how to work together, we start MySQL, client connection, request query, get the results returned, and finally exit. Take a look at this process.

After executing the start MySQL command,the MySQL initialization module reads the system parameters and command line parameters from the configuration file and initializes the entire system by parameters. At the same time, each storage engine is also started, and the respective initialization work is done.

When the entire system is initialized, the connection Management module takes over, and the connection management module initiates a listener that handles client connection requests, including TCP/IP network snooping, and a UNIX socket. At this point, the MySQL server basic boot is complete, ready to accept client requests.

When the connection management module hears the client's connection request, the two parties pass the Protocol "greeting" through the Client&server Interaction Protocol module, and the connection Management module forwards the connection request to the thread management module to request a connection thread.

The thread management module immediately gives control to the connection thread module , which tells the connection thread module: I have a connection request and need to establish a connection. After connecting the thread module to the connection request, first check if there is a cache in the current thread connection pool that has an idle connection thread, if any, take out one and the client requests the connection, and if not, establish a connection thread to connect with the client. Of course, the connection thread module does not receive the connection request immediately after the connection thread and the client connection, but the first call the user module for authorization check , only after the client request passed the authorization check, it will be the client request and line thread attached connected.

In MySQL, there are two types of client requests: A query, a request that calls parser and a forwarding module to execute, and a command that does not need to call parser to execute the request directly. (If the full query logging feature is turned on in the configuration file, the query parsing and forwarding module invokes the logging module to log the request, whether it is a query-type request or a command-type request, it is logged into the log)

When a client requests a connection thread, the connection thread begins processing various commands sent by the client request or query. It forwards the received query to the query parsing and forwarding module , and the query parser first makes basic semantic and syntactic parsing of query, and then depending on the type of command, some are processed directly, and some are forwarded to other modules for processing.

If it is a query type request, give control to the query parser , the query parser first analyzes is not a SELECT, if it is, call the query cache module , let it check the query in the query The cache is present, and if so, the data in the cache is returned directly to the connection thread module and then transferred to the client through the connection thread with the client. If not, then query will return the query parser to the query parser for processing, and then to the relevant processing module through the query dispatcher.

If the parser resolves a select that is not a cache, give control to optimizer, the query optimizer module .

If it is DML or DDL, it is given to the table Change Management module ,

If the query for some update statistics, detection, repair, and collation classes is given to the table maintenance module

Copy the relevant query to the replication module

Query for request status to the Status Collection report module

After each module receives query resolution and the distribution module is divided into the request, first through the access control module to check whether the connection user has access to the target table and the permissions of the field, if any, the Call Table Management module requests the corresponding table, and obtain the corresponding lock. (The table management module will see if the table is in table cache, and if it is already open, lock-related processing, if not the cache, you need to open the table file to get the lock, and then give the open table to the Table management module)

When the table Change Management module obtains the open table, according to the table's related meta information, the table's storage engine type of other relevant information, according to the table storage engine type, submitted to the Storage Engine interface Module , call the corresponding storage engine implementation module , and then handle accordingly. (For the Table Change management module, visible is only a series of APIs provided by the storage engine, the underlying storage engine implementation of the module implementation, for the table change management module is transparent, it only needs to call the corresponding interface, indicating the table type, Interface module table according to the table type call the correct storage engine for the corresponding processing)

When a query or command processing completes (success is a failure), control is given to the connection thread module . If the processing succeeds, the processing results are returned to the client through the connection thread, and if the processing fails, the corresponding error message is sent to the client, and the thread module cleans up and continues to wait for the subsequent request, repeating the process mentioned above, or completing the client disconnect request.

If, in the above process, the relevant module changes the data in the database and MySQL opens the Binlog, the corresponding processing module invokes the log processing module to record the corresponding change statement as an update event in the binary log file specified by the relevant parameter.

In each of the above module processing, the respective core computing processing function part is highly dependent on the entire MySQL core API module, such as: memory management, file I/O, digital and string processing and so on.

Organized from: MySQL Performance Tuning and Architecture design chapter II MySQL architecture composition

This article is from the "just out of the shell of the Birds" blog, please be sure to keep this source http://qhd2004.blog.51cto.com/629417/1829563

How each module works together in MySQL