InnoDB: an update statement execution process

What are the steps to execute an update statement under the storage engine InnoDB? Suppose we execute the following SQL. This article macroscopically treats the executor and the storage engine as one (the executor and the storage engine interact).

update user_info set name='岩枭' where id=1 and name='萧炎';

1、Buffer Pool

To perform an update operation, you must first get the data located in the where condition. The storage engine will first search the Buffer Pool to see if there is this piece of data. If there is, it will start. If not, it can only read it from the disk and then load it into the Buffer Pool.

Imagine that there is a user.txt file on the disk (simplified as only one row) that saves a piece of user information. The user information in it needs to be modified. Does it also need to be read into the memory by a program and then written after processing? Back to disk. In this process, if the user information needs to be read, it can be obtained directly from the memory.

2、undo log

Before executing the update, write a log to the undo log to record the original data information. If the program handles abnormally and the transaction needs to be rolled back, then the undo log is required to roll back the data to before the update.

Just think about it, now we are about to update the data loaded into the memory from user.txt. To be on the safe side, should we make a log first to record what the original data was before the update?

3. Dirty data

Now modify the data in the Buffer Pool and change 'Xiao Yan' to 'Yan Xiao'. This produces so-called dirty data, because the memory data has been updated, but the disk data has not been updated.

4、Redo Log

After updating the memory data, write a log to the Redo Log to record the modifications to the data, so that when MySQL goes down, it can be recovered from the Redo Log. Redo Log also has its own buffer. The usual configuration is to flush the Redo Log when a transaction is submitted.

So when the transaction is not committed, it doesn't matter even if MySQL is down, because the data is in memory and the client will receive an exception. After the transaction is submitted, it doesn't matter even if MySQL is down. MySQL can restore the data based on the Redo Log.

5、binlog

Archive log. After the above steps are completed, the logical log will be recorded in the binlog. It can be simply understood as what modifications were made to which data on which data page. Then write the binlog related information to the Redo Log and mark it with a commit mark, and the transaction is completed.

6. Data placement

After the above steps, the IO thread inside the MySQL server will synchronize the memory data back to the disk at a certain moment, so that the disk data is the latest data.

Summarize:

In fact, MySQL can also be regarded as an application (business) system. For MySQL, an update statement is processing a business. In order to support revocation and ensure recovery after a downtime, this application system has done a lot of guarantee work.

おすすめ

転載: blog.csdn.net/weixin_43275277/article/details/127859984