Understanding InnoDB Buffer Pool: Architecture, Components, and Management
This article explains how InnoDB’s buffer pool works, covering its purpose, configuration parameters, internal structures such as free, flush, and LRU lists, multi‑instance handling, adaptive hash indexing, and strategies for page eviction and performance optimization.
Understanding InnoDB Buffer Pool
Data is usually persisted on disk, and if InnoDB accessed the disk directly for every client request, both I/O pressure and response time would be unacceptable. Therefore, InnoDB loads whole pages into a memory cache called the buffer pool, keeping pages there according to eviction policies so that subsequent accesses can avoid disk reads, improving response time and reducing I/O.
Buffer Pool
The cache mentioned above is the buffer pool , whose size is set by the innodb_buffer_pool_size variable. The default size is 128 MB, with a minimum of 5 MB; it can be configured to several gigabytes or even hundreds of gigabytes depending on the server.
Internal Composition
The buffer pool contains data pages, index pages, the change buffer, adaptive hash, and other structures. Data and index pages occupy most of the pool, but the pool also holds change‑buffer (formerly insert buffer) and adaptive hash structures for fast lookups, as well as small portions for lock information and the data dictionary.
Page Data
When MySQL starts, it allocates a contiguous memory region for data and index pages. Each page is 16 KB by default, and InnoDB creates a control block of about 800 bytes for each page, storing the tablespace ID, page number, memory address, and linked‑list pointers. Only the memory occupied by these buffer pages counts toward the buffer pool size.
Free List
Because InnoDB cannot know which buffer pages are free, it maintains a free list. A free list head node (40 bytes, not counted in the pool) points to control blocks of unused pages. When a page needs to be loaded from disk, InnoDB takes a control block from the free list, fills it with the page data, and removes the block from the free list. The page’s location is also recorded in a hash table keyed by tablespace ID and page number.
Flush List
Writes are first performed in memory. Modified pages are later flushed to disk according to rules described in the redo‑log article. The set of dirty pages is tracked by a flush list, which works similarly to the free list. When flushing, InnoDB takes control blocks from the flush list, writes the associated pages to disk, then moves those blocks back to the free list.
LRU List
Because the buffer pool size is limited, InnoDB uses an LRU eviction strategy. If a page is already in the pool, its control block is moved to the head of the LRU list; if it is not, the page is loaded and its block is placed at the LRU head, possibly evicting the tail page when the pool is full. To avoid evicting hot data during large scans or prefetches, InnoDB splits the LRU into "young" and "old" segments controlled by innodb_old_blocks_pct (default 37%). Pages first enter the old segment; if they stay long enough (controlled by innodb_old_blocks_time , default 1000 ms) they are promoted to the young head. Additional heuristics keep pages that reside in the first quarter of the young segment from being moved.
Multiple Buffer Pool Instances
For large memory configurations, a single buffer pool can become a contention point. InnoDB allows multiple instances via innodb_buffer_pool_instances . Starting with MySQL 5.7.5, each instance is divided into chunks; the chunk size is set by innodb_buffer_pool_chunk_size (default 128 MB). The total pool size must be a multiple of innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances .
Adaptive Hash Index
While B‑tree lookups have O(log N) complexity, InnoDB can create an adaptive hash index for hot pages, achieving O(1) lookups. The hash is built automatically for pages that satisfy two conditions: (1) the query pattern matches a specific index prefix (e.g., WHERE a = … vs. WHERE a = … AND b = … ), and (2) the access frequency exceeds MAX(100, page_rows/16) . Enabling the adaptive hash index can double read/write speed and increase join performance for secondary indexes by up to five times.
Conclusion
By reviewing the concepts above, readers should gain a solid understanding of the InnoDB buffer pool. For deeper insight, run SHOW ENGINE INNODB STATUS and examine the various parameters to fully master buffer pool behavior.
Rare Earth Juejin Tech Community
Juejin, a tech community that helps developers grow.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.