MySQL modules work with each other

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　MySQL modules work with each other

After learning the various MySQL modules, let's look at how MySQL works together with each other. Next, we start with MySQL, client connection, request query, get back results, and finally exit, so
An entire process for analysis.

When we execute the start MySQL command, the MySQL initialization module reads the system parameters and command line parameters from the system configuration file and initializes the entire system with parameters, such as requesting and allocating buffer, initializing global variables,
and various structures and so on. At the same time, each storage engine is also started, and the respective initialization work is done. When the entire system is initialized, it is taken over by the connection management module. The connection management module initiates the listener that handles the client connection request, and the package
TCP/IP-aware network monitoring, and a UNIX socket. At this point, MySQL Server completes the basic boot and is ready to accept the client request.

When the connection management module hears the client's connection request (with the help of the Network interaction module), the connection management module will connect with the protocol "greeting" through the protocols defined by the client & Server Interaction Protocol module.
The request is forwarded to the thread Management module to request a connection thread.

The thread management module will now hand over the control to the connection thread module, telling the connection thread module: Now I have a connection request coming over, need to establish a connection, you quickly deal with. Connection thread module after receiving the connection request, first checks whether there is an idle connection thread in the current connection thread pool, and if so, takes out one and the client request connection, and if there is no idle connection thread, establishes a new connection thread to connect with the client request. Of course, the connection thread module does not immediately take out a connection request after receiving a connection thread attached and a client connection, but rather first by invoking the user module for authorization checks, only after the client request passed the authorization check, he will be the client request and responsible for the requested connection line thread attached.

In MySQL, there are two types of client requests: A query that calls Parser, which is the query parsing and forwarding module parsing to execute, and a command that does not need to call Parser to
To directly execute the request. If the function of full Query Logging is turned on in our initialization configuration, then the query parsing and forwarding module invokes the logging module to count the request into the log, whether it is a Query-type request or a command-type request, it will be logged into the log. Therefore, for performance reasons, it is generally very rare to turn on fullquery Logging functionality.

When the client request and the connection thread "exchange the password (interworking protocol)", the connection thread begins processing various commands (or query) sent by the client request, accepting the request. It turns the received query statement
To query parsing and forwarding module, query parser first to query the basic semantic and syntactic parsing, and then depending on the type of command, some will be processed directly, some will be distributed to other modules to deal with. If it is a query-type request, control is given to the query parser. The query parser first parses to see if it is a select type of query, and if it does, call the querying cache module and let it check whether the query already exists in query cache. If so, the data in the cache is returned directly to the connection thread module, which then transmits data to the client through the thread connected to the client. If it is not a query type that can be used by the cache, or the data in the cache does not have the query, then query will be passed back to the query parser, with the query parser handled accordingly, and distributed to the relevant processing module by the query dispatcher.

If the parser resolves the result to be a SELECT statement that is not the cache, the control is given to Optimizer, the Query optimizer module, and if it is DML or a DDL statement, it is given to the table change management module, if it is some update statistics, detection, repair, and collation of the class Q Uery will be given to the table maintenance module to process, copy the relevant query to the replication module to do the corresponding processing, the request status of the query is forwarded to the State Collection report module. In fact, the table change management module differs from the corresponding processing request by the Insert processor, the delete processor, the update processor, the Create processor, and the Alter processor, which are the small modules responsible for different DML and DDL. After each module receives the Query resolution and the distribution module to distribute the request, first through the Access control module to check whether the connection user has access to the target table and the Target field permissions, if any, will call the Table Management module request the corresponding table, and obtain the corresponding lock. The table Management module first checks to see if the table already exists in table cache, if it is already open, locks-related processing, if not in the cache, you need to open the table file to get the lock, and then hand the open table to the table change management module.

When the table change management module "gets" The open table, the table's storage engine type and other related information are judged based on the relevant meta information for that table. According to the storage engine type of the table, submit the request to the Storage Engine interface module, call the corresponding storage engine implementation module, and handle accordingly. However, for the table Change management module, only the storage Engine interface module provides a series of "standard" interface, the underlying storage engine implementation of the module implementation, for the table change management module is transparent. He only needs to invoke the corresponding interface and indicate the table type, and the interface module calls the correct storage engine according to the table type to handle it accordingly.

When a query or command processing completes (success or failure), control is returned to the connection thread module. If the processing succeeds, the processing result (either a result set or a successful or failed identity) is fed back to the client through the connection thread. If an error occurs during processing, the appropriate error message is also sent to the client, and then the thread module cleans up and continues to wait for the subsequent request, repeating the process mentioned above, or completing a client disconnect request.

If, in the process above, the relevant module changes the data in the database, and MySQL opens the Binlog function, the corresponding processing module also calls the log processing module to record the corresponding change statement in the form of the update event
into the binary log file specified by the relevant parameter. During the processing of each of the above modules, the core arithmetic processing functions of each module are highly dependent on the core API modules of MySQL, such as memory management, file I/O, digital and string processing, etc.

After understanding the entire process, we can draw the diagram of each of the above modules:

MySQL modules work with each other