•Adds pages in  chunks  (chunk size is defined by  innodb_buffer_pool_chunk_size ) •Coverts hash tables, lists, and pointers to use new addresses in memory •Adds new pages to the free list •Defragments the buffer pool and withdraws (frees) pages •Removes pages in  chunks  (chunk size is defined by  innodb_buffer_pool_chunk_size ) •Converts hash tables, lists, and pointers to use new addresses in memory While these operations are in progress, other threads are blocked from accessing the buffer pool. When decreasing the size of the buffer pool, the resizing operation: Of these operations, only defragmenting the buffer pool and withdrawing pages allow other threads to access to the buffer pool concurrently. For systems with buffer pools in the multi-gigabyte range, dividing the buffer pool into separate instances can improve concurrency, by reducing contention as different threads read and write to cached pages. This feature is typically intended for systems with a buffer pool size in the multi-gigabyte range. Multiple buffer pool instances are configured using the  innodb_buffer_pool_instances  configuration option, and you might also adjust the  innodb_buffer_pool_size  value. When the  InnoDB  buffer pool is large, many data requests can be satisfied by retrieving from memory. You might encounter bottlenecks from multiple threads trying to access the buffer pool at once. You can enable multiple buffer pools to minimize this contention. Each page that is stored in or read from the buffer pool is assigned to one of the buffer pools randomly, using a hashing function. Each buffer pool manages its own free lists, flush lists, LRUs, and all other data structures connected to a buffer pool. Prior to MySQL 8.0, each buffer pool was protected by its own buffer pool mutex. In MySQL 8.0 and later, the buffer pool mutex was replaced by several list and hash protecting mutexes, to reduce contention. To enable multiple buffer pool instances, set the  innodb_buffer_pool_instances  configuration option to a value greater than 1 (the default) up to 64 (the maximum). This option takes effect only when you set innodb_buffer_pool_size  to a size of 1GB or more. The total size you specify is divided among all the buffer pools. For best efficiency, specify a combination of  innodb_buffer_pool_instances  and innodb_buffer_pool_size  so that each buffer pool instance is at least 1GB. For information about modifying  InnoDB  buffer pool size, see Section 15.8.3.1, “Configuring InnoDB Buffer Pool Size” . Rather than using a strict LRU algorithm,  InnoDB  uses a technique to minimize the amount of data that is brought into the buffer pool and never accessed again. The goal is to make sure that frequently accessed (“hot” ) pages remain in the buffer pool, even as read-ahead and full table scans bring in new blocks that might or might not be accessed afterward. Newly read blocks are inserted into the middle of the LRU list. All newly read pages are inserted at a location that by default is  3/8  from the tail of the LRU list. The pages are moved to the front of the list (the most-recently used end) when they are accessed in the buffer pool for the first time. Thus, pages that are never accessed never make it to the front portion of the LRU list, and “age out”  sooner than with a strict LRU approach. This arrangement divides the LRU list into two segments, where the pages downstream of the insertion point are considered “old”  and are desirable victims for LRU eviction. 3115 15.8.3.3 Making the Buffer Pool Scan Resistant 15.8.3.2 Configuring Multiple Buffer Pool Instances InnoDB Buffer Pool Configuration