1. One sentence overview of the execution process
- Query statement: permission verification -> cache query -> analyzer -> optimizer -> executor -> permission verification -> executor -> engine.
- Update statement: analyzer -> permission verification -> executor -> engine -> redolog prepare -> binlog -> redolog commit.
2. Detailed explanation of the execution process
MySQL is mainly divided into two parts: server layer and storage engine layer .
- Server layer :
including connectors, query caches, analyzers, optimizers, and executors. All cross-storage engine functions are implemented in this layer, such as stored procedures, triggers, views, functions, etc., as well as the general log module binlog .
-
Connector: Identity authentication and authority related.
Mainly responsible for user login database and user identity verification, including verification code, authority and other operations. -
Query cache: When executing a query statement, it will first query the cache (removed after MySQL8.0 version)
1) No syntax analysis is done in this step.
2) After mysql receives the statement, it judges whether it is a query statement through the command distributor.
3) If the query cache is turned on, first query the cache to find whether the SQL completely matches. The cache is stored in a reference table (Key-Value) and is referenced by a hash value. The hash value Key is the query estimate , Including the query itself, the current database to be queried, the version of the client protocol and other information that may affect the returned results. When judging whether the cache is hit, mysql will not parse the query statement, but directly use the SQL statement and the client Send enough other original information. Therefore, any difference in characters, such as spaces, comments, etc., will cause cache misses. If they match, verify whether the current user has query permissions. If the permissions are verified, the result set (Value) is directly returned to the client. Continue down execution.
4) The reason for the new version to remove the cache: query cache invalidation may be very frequent in actual business scenarios, because all query caches that update a table will be cleared. For data that is not frequently updated, it is still possible to use the cache. -
Analyzer: If there is no cache hit, the SQL statement will go through the analyzer to check whether the syntax of the statement is correct.
1) Extract keywords, extract query tables, field names, query conditions, etc.
2) Determine whether it conforms to mysql syntax. -
Optimizer: execute according to the optimal plan that MySQL thinks.
-
Executor: execute the statement, and then return data from the storage engine.
It is necessary to determine the user permissions before execution. If there is permission, the interface of the engine is called to return the execution result; if there is no permission, an error message will be returned.
- Storage engine layer :
Responsible for data storage and reading, adopts a replaceable plug-in architecture, and supports multiple storage engines such as MyISAM, InnoDB, and Memory. Starting from MySQL version 5.5.5, InnoDB is used as the default storage engine, and the InnoDB engine has its own log module.
Three, log module
The log module needs to be introduced when executing statement updates. Mysql comes with its own log module binlog (archive log), which can be used by all storage engines; InnoDB engine also comes with its own log module redolog (redo log). We can summarize the flow of an update statement as follows:
1) Query whether the data has a cache, and if there is, use the cache.
2) Get the query statement, call the engine interface, and write the data. The InnoDB engine saves the data in the memory and records the redolog. At this time, the redolog enters the prepare state, and then tells the executor that the execution is complete and it can be submitted.
3) The executor records the binlog after receiving the notification, and calls the engine interface to submit the redolog as the submission state.
4) The update is complete.
Question 1: Why use two log modules and one log module?
At first, MySQL did not work with InnoDB engine (InnoDB engine was plugged into MySQL by other companies). MySQL's own engine is MyISAM, but we Knowing that the redo log is unique to the InnoDB engine and no other storage engine, this will result in no crash-safe capability (the crash-safe capability will not be lost even if the database is restarted abnormally), the binlog log only Can be used for archiving.
Question 2: How to ensure data consistency through redolog and binlog?
Guaranteed by the processing mechanism of MySQL.
1) Determine whether the redolog is complete, and submit it immediately if it is complete.
2) If redolog is only pre-committed but not in commit state, you need to determine whether the binlog is complete, if it is complete, submit the redolog, and roll back the transaction if it is incomplete.