Life experience of an update statement

---

Server layer and storage engine layer

One SQL Statement execution on , Generally speaking, it can be divided into ：Server Layer and storage engine layer （InnoDB）

1. Server layer

1.1 The connector

Responsible for establishing connections with clients 、 Account password verification 、 Access permissions 、 Maintaining and managing connections .

1.2 analyzer

After passing the verification , The parser will analyze the statement , Judge whether there are grammatical errors, etc .

1.3 Optimizer

Choose the index , Generate execution plan .

1.4 actuator

According to the execution plan generated by the optimizer , Call the storage engine API perform SQL.

2. InnoDB Engine layer

2.1 Transaction execution

Read the data page
Get into InnoDB Behind the engine layer , First of all, we will judge that SQL Whether the data page involved exists in BP(buffer pool) in ;
If it doesn't exist, go through B+Tree Read the data page to the disk , And then load it into BP：
Find the record corresponding to this page by dichotomy

• adopt space id and page no After hashing, put The index page is loaded into the specified buffer pool instance in
• Judge free list Whether there are free pages available ( Innodb_buffer_pool_pages_free、 Innodb_buffer_pool_wait_free ), If not, the dirty pages will be eliminated lru list Of old page
• Put data page copy To free list in , And then load it into lru list Of old District midpoint（ Head ）

Lock
Try to put an exclusive lock on the corresponding row record , The process is as follows ：

• Whether the row lock of the corresponding row record is occupied by other transactions , When occupied, enter the lock and wait ;
• After entering the lock and waiting , At the same time, judge whether it will lead to deadlock due to your participation ;
• After detecting that there is no lock waiting and no deadlock is caused , Row record with exclusive lock ;

Write logic undo log
Write the record before modification to undo in ;
Modify the value of the current row , Fill in the transaction number ;
Use the rollback pointer to point to undo log Line before modification in , Build rollback segment , Used to roll back data and implement MVCC Multiple versions of .

Write redo log buffer
First judge redo log buffer Is it enough for , If not enough, wait , It can be done by Innodb_log_waits It's worth checking ;
Update the field value of the corresponding line record , And record the modification operation to redo log buffer in ;
The corresponding data page is added flush list In the list .

Write binlog cache
The modified information will correspond to event Format to write binlog cache in .

Write change buffer
If this time update The operation involves modifying the secondary index , Then write change buffer page .

2.2 Transaction submission

InnoDB Storage engine transaction submission is divided into prepare、commit Two-phase commit

1. redo log prepare
   take redo log buffer Refresh to disk file , For crash recovery ; The way to brush the disc is determined by innodb_flush_log_at_trx_commit decision （ unmark commit）, The storage engine tier is in prepare state .
2. binlog write & fsync
   Actuator handle binlog cache The whole business and redo log prepare Medium XID event Write to binlog in ;
   send out binlog_cache Inside event To slave And wait for （ Asynchronous mode does not wait ） slave ack ;
   perform fsync Brush set ( For big business, this step is very time-consuming ), And empty binlog cache;# binlog The way to brush the disc is determined by sync_binlog decision .
3. redo log commit
   commit Stage , Due to the previous transaction redo log already sync It's on disk , So this step is just redo log Inside mark commit, Indicates that the transaction was committed successfully . In semi synchronous mode, if it cannot be received slave ack This step will be in a waiting state .
4. Transaction submitted successfully , Release the exclusive lock held by the row record .
5. Refresh the dirty pages
   The database performs dirty page brushing operations according to certain policies .

2.3 Transaction rollback

If the transaction is explicitly rolled back because of an exception or , Is with the aid of undo log To recover the data in :

• about in-place( In situ ) to update , Rollback data to the oldest version ;
• about delete + insert By , Clean up deleted records marked for deletion , At the same time, the inserted clustered index and secondary index records will also be deleted directly .

Please correct me if there is any mistake