MySQL practice 45 [SQL query and update execution process]

01 | Infrastructure ： One SQL How query statements are executed ？

SQL Statements in MySQL The execution process in each function module of

Server Layers include connectors 、 The query cache 、 analyzer 、 Optimizer 、 Actuators etc. , cover MySQL Most of the core service functions of , And all the built-in functions （ Such as date 、 Time 、 Mathematics and cryptographic 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 extraction . Its architecture pattern is plug-in , Support InnoDB、
MyISAM、Memory Wait for multiple storage engines . Now the most commonly used storage engine is InnoDB, It is from MySQL5.5.5 Version began to be the default storage engine .

Among them Command The column is shown as “Sleep” This line , It means that there is an idle connection in the system

If the client does not move for a long time , The connector will automatically disconnect it . This time is determined by the parameter wait_timeout The control of the , The default value is 8 Hours

Relevant command ：

--  The client side.   Non interactive connection time , Unit second 
SHOW VARIABLES LIKE 'wait_timeout%';
--  The client side.   Interactive connection time , Unit second 
SHOW VARIABLES LIKE 'interactive_timeout%';

Actuator flow


mysql Slow log

--  Check whether the log query function is enabled 
SHOW VARIABLES LIKE 'slow_query%';

#  Turn on  MySQL  Slow query log function 
SET GLOBAL slow_query_log=ON;
#  Set slow sql Time for , Execution time exceeded  1  Of a second  SQL  The statement will be recorded in the log 
SET GLOBAL long_query_time=1;

02 | Log system ： One SQL How update statements are executed ？

When there is an update on a table , The query cache associated with this table will fail , So this statement will put the table T All cached results on are cleared . That's why we generally don't recommend using query caching

Unlike the query process , The update process also involves two important logging modules :redo log（ Redo log ） and binlog（ Archive log ）

MySQL It's often said in WAL technology ,WAL The full name is Write-Ahead Logging, The key point is to write a log first , Write the disk again , That is to write the pink board first , Don't write down the account book until you are not busy

When a record needs to be updated ,InnoDB The engine will write the record first redo log（ Powder board ） Inside , And update memory , At this time, the update is finished . meanwhile ,InnoDB The engine will... At the right time , Update this operation record to disk , And this update is often done when the system is relatively idle , It's like what the shopkeeper does after closing .

InnoDB Of redo log It's fixed size , For example, it can be configured as a group 4 File , The size of each file is 1GB, So this one “ Powder board ” In total, you can record 4GB The operation of . Write from the beginning , Write at the end and go back to the beginning

write pos Is the location of the current record , Move back as you write , Write to No 3 Go back to... At the end of file 0 The beginning of file No .checkpoint Is the current location to erase , It's also going back and forth , Before erasing a record, update the record to a data file .

write pos and checkpoint Between is “ Powder board ” The empty part of the top , It can be used to record new operations . If write pos Catch up checkpoint, Express “ Powder board ” Full of , No new updates can be performed at this time , You have to stop and erase some records , hold checkpoint Push on .

With redo log,InnoDB It can guarantee that even if the database is restarted abnormally , The records submitted before will not be lost
loss , This ability is called crash-safe.

MySQL On the whole , In fact, there are two pieces ： One is Server layer , The main thing it does is MySQL Functional things ; The other is the engine layer , Responsible for specific storage related matters .

redo log yes InnoDB Engine specific logs , and Server Layer also has its own log , be called binlog（ Archive log ）

There are three differences between the two kinds of logs

1. redo log yes InnoDB Engine specific ;binlog yes MySQL Of Server Layer , All engines
   You can use .
2. redo log It's a physical log , The record is “ What changes have been made on a data page ”;binlog It's logic day
   Records , What is recorded is the original logic of this statement , such as “ to ID=2 In this line c Field plus 1 ”.
3. redo log It's written in cycles , The space will be used up ;binlog Can be added to write .“ Additional writing ” Refer to
   binlog When the file is written to a certain size, it will switch to the next , Does not overwrite previous logs

sql Update process

1. Find the engine for the actuator first ID=2 This business .ID It's the primary key , The engine uses tree search to find this line . If
   ID=2 The data page where this line is located is already in memory , Directly back to the actuator ; otherwise , You need to start with magnetism
   Disk read into memory , And then back again .
2. The actuator gets the row data given by the engine , Add this value to 1, Like it turns out to be N, Now is N+1, obtain
   A new row of data , Then call the engine interface to write the new data .
3. The engine updates this row of new data into memory , At the same time, record the update operation to redo log Inside , here
   redo log be in prepare state . Then tell the actuator that the execution is finished , You can commit a transaction at any time .
4. The actuator generates the binlog, And put binlog Write to disk .
5. The executor calls the engine's commit transaction interface , The engine just wrote redo log Change to submit （commit） shape
   state , Update complete .

update Statement execution flowchart , The light color box in the picture indicates that it is in InnoDB Internally executed , The dark box indicates that it is executed in the actuator

redo log The write of is divided into two steps ：prepare and commit, This is it. " Two-phase commit "

binlog Will record all logical operations , And it uses “ Additional writing ” In the form of . If your DBA Promise to recover in half a month , Then the backup system will certainly save all the last half month binlog, At the same time, the system will backup the whole database regularly . there “ regular ” Depends on the importance of the system , It can be prepared one day , It can also be prepared once a week

In short ,redo log and binlog Can be used to represent the commit state of a transaction , And two-phase commit is to keep these two states logically consistent

sync_binlog This parameter is set to 1 When , For each transaction binlog All persistent to disk . I also suggest that you set this parameter to 1, This ensures MySQL After abnormal restart binlog No loss .

sync_binlog This parameter is set to 1 When , For each transaction binlog All persistent to disk . I also suggest that you set this parameter to 1, This ensures MySQL After abnormal restart binlog No loss .

summary

1. Redo log Not a record data page “ Status after update ”, But record this page “ What changes have been made ”
2. Binlog There are two patterns ,statement The format is to remember sql sentence , row The format records the contents of the line , Make two notes , more
   Both before and after the update

Reference resources

mysql Slow log