InnoDB maintains a storage area
called the buffer pool
for caching data and indexes in memory. Knowing how the
InnoDB buffer pool works, and taking
advantage of it to keep frequently accessed data in memory, is
an important aspect of MySQL tuning. For information about how
the InnoDB buffer pool works, see
InnoDB Buffer Pool LRU Algorithm.
You can configure the various aspects of the
InnoDB buffer pool to improve performance.
Ideally, you set the size of the buffer pool to as large a
value as practical, leaving enough memory for other
processes on the server to run without excessive paging. The
larger the buffer pool, the more InnoDB
acts like an in-memory database, reading data from disk once
and then accessing the data from memory during subsequent
reads. Buffer pool size is configured using the
innodb_buffer_pool_size
configuration option.
With 64-bit systems with large memory sizes, you can split the buffer pool into multiple parts, to minimize contention for the memory structures among concurrent operations. For details, see Section 14.6.3.2, “Configuring Multiple Buffer Pool Instances”.
You can keep frequently accessed data in memory despite sudden spikes of activity for operations such as backups or reporting. For details, see Section 14.6.3.3, “Making the Buffer Pool Scan Resistant”.
You can control when and how InnoDB
performs read-ahead requests to prefetch pages into the
buffer pool asynchronously, in anticipation that the pages
will be needed soon. For details, see
Section 14.6.3.4, “Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)”.
You can control when background flushing of dirty pages
occurs and whether or not InnoDB
dynamically adjusts the rate of flushing based on workload.
For details, see
Section 14.6.3.5, “Configuring InnoDB Buffer Pool Flushing”.
You can fine-tune aspects of InnoDB
buffer pool flushing behavior to improve performance. For
details, see
Section 14.6.3.6, “Fine-tuning InnoDB Buffer Pool Flushing”.
You can configure InnoDB to preserve the
current buffer pool state to avoid a lengthy warmup period
after a server restart. You can also save the current buffer
pool state while the server is running. For details, see
Section 14.6.3.7, “Saving and Restoring the Buffer Pool State”.
InnoDB manages the buffer pool as a list,
using a variation of the least recently used (LRU) algorithm.
When room is needed to add a new page to the pool,
InnoDB evicts the least recently used page
and adds the new page to the middle of the list. This
“midpoint insertion strategy” treats the list as
two sublists:
At the head, a sublist of “new” (or “young”) pages that were accessed recently.
At the tail, a sublist of “old” pages that were accessed less recently.
This algorithm keeps pages that are heavily used by queries in the new sublist. The old sublist contains less-used pages; these pages are candidates for eviction.
The LRU algorithm operates as follows by default:
3/8 of the buffer pool is devoted to the old sublist.
The midpoint of the list is the boundary where the tail of the new sublist meets the head of the old sublist.
When InnoDB reads a page into the
buffer pool, it initially inserts it at the midpoint (the
head of the old sublist). A page can be read in because it
is required for a user-specified operation such as an SQL
query, or as part of a
read-ahead
operation performed automatically by
InnoDB.
Accessing a page in the old sublist makes it “young”, moving it to the head of the buffer pool (the head of the new sublist). If the page was read in because it was required, the first access occurs immediately and the page is made young. If the page was read in due to read-ahead, the first access does not occur immediately (and might not occur at all before the page is evicted).
As the database operates, pages in the buffer pool that are not accessed “age” by moving toward the tail of the list. Pages in both the new and old sublists age as other pages are made new. Pages in the old sublist also age as pages are inserted at the midpoint. Eventually, a page that remains unused for long enough reaches the tail of the old sublist and is evicted.
By default, pages read by queries immediately move into the
new sublist, meaning they will stay in the buffer pool for a
long time. A table scan (such as performed for a
mysqldump operation, or a
SELECT statement with no
WHERE clause) can bring a large amount of
data into the buffer pool and evict an equivalent amount of
older data, even if the new data is never used again.
Similarly, pages that are loaded by the read-ahead background
thread and then accessed only once move to the head of the new
list. These situations can push frequently used pages to the
old sublist, where they become subject to eviction. For
information about optimizing this behavior, see
Section 14.6.3.3, “Making the Buffer Pool Scan Resistant”, and
Section 14.6.3.4, “Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)”.
InnoDB Standard Monitor output contains
several fields in the BUFFER POOL AND
MEMORY section that pertain to operation of the
buffer pool LRU algorithm. For details, see
Section 14.6.3.8, “Monitoring the Buffer Pool Using the InnoDB Standard Monitor”.
Several configuration options affect different aspects of the
InnoDB buffer pool.
Specifies the size of the buffer pool. If the buffer pool
is small and you have sufficient memory, making the buffer
pool larger can improve performance by reducing the amount
of disk I/O needed as queries access
InnoDB tables.
Divides the buffer pool into a user-specified number of
separate regions, each with its own LRU list and related
data structures, to reduce contention during concurrent
memory read and write operations. This option only takes
effect when you set
innodb_buffer_pool_size
to a value 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 1 gigabyte.
See Section 14.6.3.2, “Configuring Multiple Buffer Pool Instances” for
more information.
Specifies the approximate percentage of the buffer pool
that InnoDB uses for the old block
sublist. The range of values is 5 to 95. The default value
is 37 (that is, 3/8 of the pool). See
Section 14.6.3.3, “Making the Buffer Pool Scan Resistant”
for more information.
Specifies how long in milliseconds (ms) a page inserted into the old sublist must stay there after its first access before it can be moved to the new sublist. If the value is 0, a page inserted into the old sublist moves immediately to the new sublist the first time it is accessed, no matter how soon after insertion the access occurs. If the value is greater than 0, pages remain in the old sublist until an access occurs at least that many milliseconds after the first access. For example, a value of 1000 causes pages to stay in the old sublist for 1 second after the first access before they become eligible to move to the new sublist.
Setting
innodb_old_blocks_time
greater than 0 prevents one-time table scans from flooding
the new sublist with pages used only for the scan. Rows in
a page read in for a scan are accessed many times in rapid
succession, but the page is unused after that. If
innodb_old_blocks_time is
set to a value greater than time to process the page, the
page remains in the “old” sublist and ages to
the tail of the list to be evicted quickly. This way,
pages used only for a one-time scan do not act to the
detriment of heavily used pages in the new sublist.
innodb_old_blocks_time
can be set at runtime, so you can change it temporarily
while performing operations such as table scans and dumps:
SET GLOBAL innodb_old_blocks_time = 1000;
... perform queries that scan tables ...
SET GLOBAL innodb_old_blocks_time = 0;
This strategy does not apply if your intent is to
“warm up” the buffer pool by filling it with
a table's content. For example, benchmark tests often
perform a table or index scan at server startup, because
that data would normally be in the buffer pool after a
period of normal use. In this case, leave
innodb_old_blocks_time
set to 0, at least until the warmup phase is complete.
See Section 14.6.3.3, “Making the Buffer Pool Scan Resistant” for more information.
Controls the sensitivity of linear
read-ahead that
InnoDB uses to prefetch pages into the
buffer pool.
See Section 14.6.3.4, “Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)” for more information.
Enables random
read-ahead
technique for prefetching pages into the buffer pool.
Random read-ahead is a technique that predicts when pages
might be needed soon based on pages already in the buffer
pool, regardless of the order in which those pages were
read.
innodb_random_read_ahead
is disabled by default.
See Section 14.6.3.4, “Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)” for more information.
Specifies whether to dynamically adjust the rate of flushing dirty pages in the buffer pool based on workload. Adjusting the flush rate dynamically is intended to avoid bursts of I/O activity. This setting is enabled by default.
See Section 14.6.3.5, “Configuring InnoDB Buffer Pool Flushing” for more information.
Low water mark representing percentage of redo log capacity at which adaptive flushing is enabled.
See Section 14.6.3.6, “Fine-tuning InnoDB Buffer Pool Flushing” for more information.
Specifies whether flushing a page from the buffer pool also flushes other dirty pages in the same extent.
See Section 14.6.3.6, “Fine-tuning InnoDB Buffer Pool Flushing” for more information.
Number of iterations for which InnoDB keeps the previously calculated snapshot of the flushing state, controlling how quickly adaptive flushing responds to changing workloads.
See Section 14.6.3.6, “Fine-tuning InnoDB Buffer Pool Flushing” for more information.
A parameter that influences the algorithms and heuristics
for the flush operation
for the buffer pool. Primarily of interest to performance
experts tuning I/O-intensive workloads. It specifies, per
buffer pool instance, how far down the buffer pool LRU
list the page_cleaner thread scans
looking for dirty
pages to flush.
See Section 14.6.3.6, “Fine-tuning InnoDB Buffer Pool Flushing” for more information.
InnoDB tries to
flush data from the
buffer pool so that the percentage of
dirty pages does
not exceed this value. Specify an integer in the range
from 0 to 99. The default value is 75.
See Section 14.6.3.5, “Configuring InnoDB Buffer Pool Flushing” for more information.
innodb_max_dirty_pages_pct_lwm
Low water mark representing percentage of dirty pages where preflushing is enabled to control the dirty page ratio. The default of 0 disables the pre-flushing behavior entirely.
See Section 14.6.3.6, “Fine-tuning InnoDB Buffer Pool Flushing” for more information.
Specifies the name of the file that holds the list of
tablespace IDs and page IDs produced by
innodb_buffer_pool_dump_at_shutdown
or
innodb_buffer_pool_dump_now.
See Section 14.6.3.7, “Saving and Restoring the Buffer Pool State” for more information.
innodb_buffer_pool_dump_at_shutdown
Specifies whether to record the pages cached in the buffer pool when the MySQL server is shut down, to shorten the warmup process at the next restart.
See Section 14.6.3.7, “Saving and Restoring the Buffer Pool State” for more information.
innodb_buffer_pool_load_at_startup
Specifies that, on MySQL server startup, the buffer pool
is automatically warmed
up by loading the same pages it held at an earlier
time. Typically used in combination with
innodb_buffer_pool_dump_at_shutdown.
See Section 14.6.3.7, “Saving and Restoring the Buffer Pool State” for more information.
Immediately records the pages cached in the buffer pool.
See Section 14.6.3.7, “Saving and Restoring the Buffer Pool State” for more information.
Immediately warms up
the buffer pool by loading a set of data pages, without
waiting for a server restart. Can be useful to bring cache
memory back to a known state during benchmarking, or to
ready the MySQL server to resume its normal workload after
running queries for reports or maintenance. Typically used
with
innodb_buffer_pool_dump_now.
See Section 14.6.3.7, “Saving and Restoring the Buffer Pool State” for more information.
Interrupts the process of restoring buffer pool contents
triggered by
innodb_buffer_pool_load_at_startup
or
innodb_buffer_pool_load_now.
See Section 14.6.3.7, “Saving and Restoring the Buffer Pool State” for more information.