Overall MySQL architecture and statement execution process

mysql The overall architecture of the server

It is mainly divided into two parts ,server layer and Storage engine

• server Layers include The connector 、 The query cache 、 analyzer 、 Optimizer 、 actuator etc. , cover mysql Most of the core service functions of , And all the built-in functions , All cross-storage engine functionality is implemented in this layer , Like stored procedures , trigger , View etc.
• The storage engine layer is responsible for data storage and reading , Its architecture pattern is plug-in , Support InnoDB、MyISAM Wait for multiple engines . from mysql5.5.5 Version start InnoDB Became the default engine .

MySql Query process

from mysql Client initiates request , The connector Be responsible for connecting with the client and verifying the permissions , Start querying the cache after the connection is successful （ When cache is on ）, If it hits, it returns data directly , If it doesn't hit, it will be handed over to analyzer Conduct sql Lexical and grammatical analysis , And then to Optimizer Select the index generation execution plan , At the end of the day actuator To call the storage engine API Get the result and return

The query cache

When MySQL The server gets one SQL After query statement , First, the cache is queried , See if this statement has been executed before . If it has been carried out , Will be cached in memory , At this time, you can directly return the previously cached query results to the client ; If the corresponding record is not found in the cache , Will continue the following operations , And after the final execution , Save the query results to the query cache .

notes ：MySQL 8.0 Query caching will no longer be supported at the beginning of version .

Can pass show variables like '%query_cache%'; Statement to view the settings of the system query cache

query_cache_type by OFF Indicates that the default is off . You can configure this value in the configuration file to decide whether to enable query caching .

analyzer

If the query cache is not enabled or does not hit , Start to really implement SQL Query statement .

MySQL Will pass analyzer Yes SQL Lexical analysis of sentences , To determine what to do , such as select Represents a query statement ,update Indicates update statements, etc , What is the table name , Which fields are queried , What are the query conditions .

Optimizer

If SQL There is no problem with sentence morphology and grammar analysis , Next , Through Optimizer Generate execution plan , The main work here is when the data table contains indexes , Determine whether to use the index , And which indexes are most efficient （ Minimum number of scan lines ）, We can execute a SQL The query statement is preceded by explain Statement to view its execution plan ：

actuator

Carry out according to the execution plan sql When querying statements , The permission will be verified first , Only with corresponding permission can the execution continue , Otherwise, a permission error will be reported

The specific query operation is provided by the storage engine API Interface completed . The executor can call these interfaces to complete such tasks as reading the next row of records 、 insert record 、 Daily database operations such as updating records , perform SQL The same is true when the query returns all the result sets that meet the conditions .

SQL UPDATE statement execution process and log writing

and sql Same as query statement ,MySql Client submit SQL Before update statement , First establish the connection through the connector , Connector verification permission and other related operations , Then it is handed over to the analyzer for lexical and grammatical analysis, and the executor is responsible for the specific execution .（ modify 、 The same goes for delete statements ）

When a data table is updated , The corresponding query cache data will be cleared .

Unlike the query process , Updating also involves writing logs ,redo log( Redo log ) and binlog( Archive log )

Log write

MySql Introduced by the designers WAL technology (Write-Ahead Logging), That is to write a log first , Writing to disk .

such as InnoDB engine , When records need to be updated ,InnoDB Will write the record first redolog inside , And update memory , At this time, the update operation is completed , etc. InnoDB In my spare time , Update this operation to the disk . This is done because if you write to disk every time you update , Whole IO The cost would be very high .

redo log

redo Log yes InnoDB The logging system provided by the engine ,bindlog You can always append writes , Be responsible for the backup and recovery of full database data , The master-slave synchronization of the database cluster is also based on binlog Realized .

binlog

binlog It belongs to MySql Server Level of , All storage engines can share it

stay InnoDB Before the engine appeared ,MySQL The default storage engine is MyISAM, At that time, in order to realize data backup and recovery , It uses binlog, however binlog It's a file journal , It does not have the data recovery function after the database crashes and restarts

The writing process of the two logs

1. The actuator passes through API Interface passes the update data to the storage engine to perform the update operation ;
2. The storage engine gets the updated data , Update it to memory first , At the same time, record the update operation to redo log, here redo log be in prepare state , Then tell the actuator that the execution is finished , You can commit a transaction at any time ;
3. The actuator generates the binlog, And put binlog Write to disk （ Write timing can be configured , For transactional operations , They are written persistently only when the transaction is committed , Related details will be introduced in detail later when we talk about database data consistency ）;
4. The executor calls the engine's commit transaction interface , The engine just wrote redo log Change to commit state , Update complete .

In the above steps , take redo log The write of is divided into two steps ：prepare and commit, This is it. 「 Two-phase commit 」.

If you don't use two-phase commit , The data recovered from the two logs will be inconsistent ： For example, first write redo log,binlog It's not written yet , The database crashes and restarts ; Or write first binlog,redo The database has not been written to crash and restart , Will cause inconsistency in the recovered data .

After using two-phase commit , You can ensure that the data recovered from the two logs is consistent ： Only binlog If the writing is successful , To submit redo log, otherwise redo log be in prepare state , The transaction rolls back , thus , It ensures the consistency of data .