The concept of mysql's innodb page buffer pool buffer pool

Details: https://blog.csdn.net/liuming690452074/article/details/113811983

Pages, memory, buffer pool, the default is 128M, and each page is 16k by default, which is 8192 blocks.

 

Buffer Pool is the first core component in the database that we have to figure out, because the addition, deletion and modification operations are first performed for the data in the Buffer Pool in memory, and it also cooperates with the subsequent redo log, disk flushing and other mechanisms and operations. .

So the Buffer Pool is a memory component of the database, which caches the real data on the disk, and then the addition, deletion, and modification operations performed by our system on the database are actually mainly performed on the cached data in this memory data structure.

 

Regardless of query or modification, the page will first be copied from the disk to the bufferPool. After the modification in the memory, the data will still be returned to the disk. This is because the memory space may be freed up again.

At this time, the space of the BufferPool may be messy, some are occupied, and some are not. When there are new pages to be placed in the bufferpool, at this time, I don't know where to put the new pages?

 

 

 

 

 

 

-------------------------------------------------------------------------------------------------------------------------------------------

 

The free linked list is used to manage the blank pages of the bufferPool,

The base node stores:

1. Which is the first control block

2. Which is the last control block

3. How many control blocks are there in total?

 

The control block is very small, and it stores a pointer to the corresponding page of the BufferPool.

When fetching a page from the disk and putting it in BufferPool, first find the first control block (head) from the free linked list, put the page data in the space area corresponding to the BufferPool pointer of the control block, and put this control block from the linked list (head) delete.

When the BufferPool has page space free, the corresponding pointer of this page is added to the fee linked list (tail), and the processing performance in the free linked list is very high. In this way, it is very convenient to manage the blank pages in the BufferPool through the linked list.

 

Modified data : Copy the modified data to the BufferPool page. At this time, the modified page is called a dirty page .

When will the modified data be persisted to disk?

There is a process in the mysql background that regularly monitors which pages of the BufferPool are dirty pages (look up from the flush linked list), and then persist the dirty pages to disk

 

There will be another question here, which are dirty pages, how to judge it

As long as the page is updated in the BufferPool, the page address is added to the flush linked list. If there is no such flush linked list, it must be traversed in the BufferPool.

 

What to do when BufferPool is full?

LRU (Least recently used) , the least recently used is eliminated!

Similarly, there is also a linked list called LRU linked list. The most recently accessed is placed first. If it is full, the LRU linked list will be eliminated last. 

 But it has a problem, that is, if a relatively large table select * suddenly comes, it will eliminate all BufferPool hot pages and overwrite them with new pages. This is a blood exchange. At this time, the table will suddenly be full. Scanning eliminates hot pages. At this time, MySQL performance drops sharply. This situation is called buffer pool pollution .

 

How to solve the problem that hot data is not easily overwritten?

The LRU linked list (upgraded version) is actually divided into hot and cold areas, with   heat accounting for 5/8 and cold accounting for 3/8. 

 

A new query comes, and the bufferPool page address will be added to the head node of the cold data area of ​​the LRU linked list, and another one will still be added to the head node of the cold data area. There will be a problem here. The cold data area has been operating. , There is no data in the hot data area,

So when should the control block of cold data be moved to the hot data area?

 

If the cold data is accessed again, add the cold data area time T1, the second access time T2 (full table scan), T2-T1<1s, indicating that the access interval is very short, it is considered as a full table scan, then the cold data block is not Will move to the hot data area, if T2-T1>1S (the first time the page data, the second access to this page is more than 1s, innodb will understand the user's normal access, if it is less than 1s, it will be regarded as the full table Scan ), this will be added to the first thermal data, which becomes the thermal data.

 

Another explanation:

How about this kind of buffer pool pollution problem caused by scanning a large amount of data?

The MySQL buffer pool has added a mechanism of "the old generation residence time window":

(1) Assume that T = the residence time window of the old generation;

(2) The page inserted into the head of the old generation will not be placed in the head of the new generation even if it is accessed immediately;

(3) Only when it meets the requirement of "visited" and "stay time in the old generation" is greater than T, it will be put into the head of the young generation;

 

LRU

 

Will the cold data area be full? It will be cleared when it is full.

 

 

The above principles correspond to which parameters in InnoDB?

There are three more important parameters.

 

参数:innodb_buffer_pool_size

Introduction : Configure the size of the buffer pool. When memory is allowed, DBA will often suggest to increase this parameter. The more data and indexes are put in memory, the better the performance of the database.

 

Parameters : innodb_old_blocks_pct

Introduction : The ratio of the old generation to the length of the entire LRU chain is 37 by default, that is, the ratio of the length of the young generation to the old generation in the entire LRU is 63:37.

Voiceover: If this parameter is set to 100, it will degenerate into a normal LRU.

 

Parameters : innodb_old_blocks_time

Introduction : The stay time window of the old generation, the unit is milliseconds, and the default is 1000, that is, it will be inserted into the head of the new generation only if the two conditions of "visited" and "stay in the old generation exceed 1 second" are met.

 

 

Guess you like

Origin blog.csdn.net/liuming690452074/article/details/113810732