About the MySql database InnoDB storage engine introduction

 Anyone familiar with MySQL knows the InnoDB storage engine. As everyone knows, Redo Log is one of InnoDB's core transaction logs. After InnoDB writes to Redo Log, it commits the transaction instead of writing to the Datafile. After that, innodb asynchronously writes the data of the new transaction to the Datafile and stores it.
 So after the innodb engine has redo log and buffer pool, why can it improve performance while ensuring that no data is lost? What is the specific relationship between Buffer Pool, Redo Log and Datafile?
 In addition, Innodb has a lot of concepts, Dirty Page, LRU, LSN, Checkpoint, etc. How do these concepts work in Innodb?
 Let me tell you through a picture below

The relationship between Buffer Pool, Redo Log and Datafile

Insert picture description here
 You can think of the innodb transaction writing process as the process of writing an article. Innodb's writing process is actually very similar to our writing process.
 Imagine that the leader asked us to write an article and publish it on the forum. Then we thought of a great idea, and decided to put it in the article, but there are other things in our hands. We can’t finish writing for a while, and we are worried that we will forget it later. The leader is still waiting for us to reply. What will it do? We will first conceive an outline, record the outline and some key details in a notebook as a draft, and then immediately tell the leader what to write and let him confirm it. Finally, when you have time in the evening, you can choose words and sentences based on the draft and write the original draft.
 In this process, we used several key things:

 Our brains are used to temporarily remember our ideas

 Draft, we need draft to ensure that we don’t forget the ideas and key details

 The original draft, this is what we finally want to output

 With these few things, we can not only ensure that we will not miss a beautiful article, but also quickly tell the leader that we can do it.

 Innodb actually uses these key things:

 Buffer Pool: is our brain

 Transaction log: just our draft

 Datafile: is our original draft

 As long as you follow the process of writing the article before to write the entire transaction, you can not only ensure that no data is lost, but also can respond quickly.

 A write operation is a transaction. Innodb first writes the transaction data to the Buffer Pool and transaction log, that is, remembers it in the brain and writes a draft. Then you can commit the transaction and respond to the client. After that, InnoDB asynchronously writes the data written this time from the Buffer Pool or the transaction log to the Datafile "when there is time" to form a "positive draft".

 Among them, innodb, in order to ensure that the "draft" of the transaction log can be restored to the original without damage, and not occupy much space, the transaction log needs to have the following characteristics:

 All data content to be written must be saved in the transaction log

 The transaction log will only append the new transaction to the end of the log, and will not modify the previous content

 Once the transaction data is written to the datafile, the "draft" in the transaction log can be deleted

 From the above three characteristics, we can see that the "draft" will not be deleted before the "original draft" is formed; at the same time, the "draft" space can be recycled; finally, as long as the "draft" is there, We must be able to write a "original draft."

 What needs to be explained here is the Recovery process. That is, if the database crashes before forming the "correct draft", we need to restart the entire process, the server, or even copy the data to another server for recovery. At this time, the "draft" of the transaction log played its biggest role-data recovery. This is also very similar to the problem that often arises in our work and life-forgetting things.

 The essence of Buffer Pool is a data structure stored in memory. The memory is "forgetful" just like the human brain. When the database crashes, the data in the Buffer Pool is likely to be "destroyed". Therefore, the transaction log is like our intimate "notepad", it saves our memory as a "draft", when we forget, we can open it to recall the memory.

Guess you like

Origin blog.csdn.net/woaichihanbao/article/details/108050123