The last article "buffer pool (buffer pool), thoroughly understand!" "Introduced the working principle of InnoDB buffer pool.
A brief review: 
(1) MySQL data storage includes two parts: memory and disk;
(2) The memory buffer pool uses pages as the unit to cache the hottest data pages and index pages. ;
(3) to the InnoDB buffer pool management LRU algorithm variants, and be able to solve the problem of "pre-reading failure" and "buffer pool pollution";
voiceover: details see "buffer pool (buffer pool), completely understand! ".
There is no doubt that for read requests, the buffer pool can reduce disk IO and improve performance. The question is, what about the write request?
Situation One
Suppose you want to modify the index page with page number 4, and this page happens to be in the buffer pool. 
As shown in the above sequence number 1-2:
(1) Directly modify the page in the buffer pool, one memory operation;
(2) Write to the redo log, one disk sequential write operation;
this efficiency is the highest.
Voiceover: Write in a sequence like writing a log, tens of thousands of times per second, no problem.
Will there be consistency issues?
Not really.
(1) Reading will hit the pages of the buffer pool;
(2) The LRU data in the buffer pool will be eliminated, and the "dirty pages" will be flushed back to the disk;
(3) The database is abnormally crashed and data can be recovered from the redo log;
When will pages in the buffer pool be flushed to disk?
Flushing the disk regularly, not every time, can reduce disk IO and improve MySQL performance.
Voiceover: Batch writing is a common optimization method.
Situation two
Suppose you want to modify the index page with page number 40, and this page happens to be out of the buffer pool. 
At this point, it’s a little troublesome, as shown in the figure above, you need 1-3:
(1) First load the index page that needs to be 40 from the disk to the buffer pool, a random read operation from the disk;
(2) Modify the page in the buffer pool, a memory operation ;
(3) Write redo log, a disk sequential write operation;
When there is no hit to the buffer pool, at least one disk IO is generated. Is there still room for optimization for business scenarios where more writes and less reads?
This is the problem that InnoDB considers, and it is the change buffer that this article will discuss.
Voiceover: It is easy to see from the name that write buffering is a mechanism to reduce disk IO and improve database write performance.
What is InnoDB's write buffer?
Before MySQL5.5, it was called insert buffer, which was only optimized for insert; now it is also effective for delete and update, called change buffer.
It is a kind of application when the non-unique secondary index page is not in the buffer pool, and the page is written, and the disk page is not immediately loaded into the buffer pool, but only the buffer changes (buffer changes), when the future data is read, the data is merged and restored to the buffer pool. The purpose of write buffering is to reduce disk IO for write operations and improve database performance.
Voiceover: R has a dog, this sentence is so long.
InnoDB has added write buffer optimization, what changes will happen to the above "case two" process?
Suppose you want to modify the index page with page number 40, and this page happens to be out of the buffer pool. 
After adding write buffer optimization, the process is optimized as follows:
(1) Record this operation in the write buffer, one memory operation;
(2) Write to the redo log, one disk sequential write operation;
its performance is the same as that of the index page in the buffer pool ,similar.
Voiceover: As you can see, page 40 is not loaded into the buffer pool.
Will there be consistency issues?
Nor will it.
(1) The database crashes abnormally, and data can be recovered from the redo log;
(2) The write buffer is not just a memory structure, it will also be periodically flushed to the write buffer system table space;
(3) When data is read, there is Another process, merge data into the buffer pool;
It may be assumed that at a later time, there is a request to query the data of the index page 40. 
The process at this time is as serial number 1-3:
(1) Load the index page, the buffer pool misses, this time disk IO is inevitable;
(2) Read related information from the write buffer;
(3) Restore the index page and put it in In the buffer pool LRU;
voice-over: As you can see, page 40 will be loaded into the buffer pool when it is actually read.
There is also an omission. Why is the write buffer optimization only applicable to non-unique ordinary index pages?
In InnoDB, the similarities and differences between clustered index and secondary index are described in detail in "Understanding the Index Differences Between MyISAM and InnoDB in 1 Minute" and will not be expanded.
If the index is set with a unique attribute, InnoDB must perform a uniqueness check during modification operations. In other words, even if the index page is not in the buffer pool, the page read on the disk cannot be avoided (otherwise how to check whether it is unique?), at this time, the corresponding page should be directly put into the buffer pool and then modified, and should not The whole write buffer this Yaozi.
In addition to the data page being accessed, what other scenarios will trigger the flushing of the data in the buffer?
There are also several situations where the data in the buffer will be flushed:
(1) There is a background thread, when the database is considered idle;
(2) When the database buffer pool is not enough;
(3) When the database is shut down normally;
(4) Redo When the log is full;
voice-over: Almost no redo log is full, and the entire database is in an unusable state that cannot be written.
What business scenario is suitable for enabling InnoDB's write buffer mechanism?
Let me first talk about when it is not suitable. As analyzed above, when:
(1) The database is a unique index;
(2) Or, after writing a data, it will be read immediately; for
these two types of scenarios, when the write operation is in progress ( After proceeding), page reads were originally to be performed, and the corresponding pages were originally to be stored in the buffer pool. At this time, write caching became a burden and increased complexity.
When is it appropriate to use the write buffer, if:
(1) Most of the database is non-unique index;
(2) The business is to write more and less read, or not read immediately after writing;
write buffer can be used, and the original need for each write Perform disk IO SQL and optimize periodic batch write to disk.
Voiceover: For example, bill flow business.
The above principles correspond to which parameters in InnoDB?
There are two more important parameters. 
Parameter: innodb_change_buffer_max_size
Introduction: Configure the size of the write buffer, which accounts for the proportion of the entire buffer pool. The default value is 25%, and the maximum value is 50%.
Voiceover: Businesses that write more and read less need to increase this value. For businesses that read more and write less, 25% is actually too much.
Parameters: innodb_change_buffering
Introduction: Configure which write operations enable write buffering, which can be set to all/none/inserts/deletes, etc.
I hope you will gain something, and ideas are more important than conclusions. 
Architect's Road-Sharing technical ideas
related recommendations:
"6 shell tips to make scripts more professional | 1 minute series"
"MyISAM and InnoDB index difference | 1 minute series"
"buffer pool (buffer pool), this time thoroughly understood! ! ! "
Learn to listen, the most important thing in the workplace!" ! ! 》