InnoDB Free Pages, MySQL

​

At a glance

The number of pages in the InnoDB buffer pool that are currently unallocated, that is, neither holding data nor dirty. The free list is the pool of empty pages InnoDB hands out when it needs to bring a new page in from disk. A healthy instance keeps a small free buffer so reads never have to wait for an eviction. When the free list runs near empty, every new page read must first evict an existing page (and flush it first if dirty), which adds latency to the read path. This card is the absolute-count complement to InnoDB Dirty Pages % and the read-pressure peer to InnoDB Buffer Pool Hit Rate %.

​

Calculation

free_pages        = Innodb_buffer_pool_pages_free
free_pages_ratio  = Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total
alert             = free_pages_ratio < 0.01

1. A warm pool runs with very few free pages, and that is fine, up to a point. After an instance has been up long enough to read its working set into memory, the pool fills and the free list shrinks to a small steady-state buffer maintained by the page-cleaner threads. A low free count is therefore normal; the alert fires only when it drops below the 1% slack that InnoDB needs to absorb read bursts without forcing synchronous evictions.
2. Free pages and dirty pages compete for the same space. pages_total = pages_data + pages_dirty-overlap + pages_free (dirty pages are a subset of data pages, modified in place). When dirty pages cannot be flushed fast enough, the page cleaner cannot return pages to the free list, so the free count collapses. A near-zero free count co-timed with a high InnoDB Dirty Pages % is the classic flush-can’t-keep-up signature.
3. Eviction cost. When the free list is empty and a new page must come in, InnoDB evicts a least-recently-used page; if that victim is dirty it must be flushed to disk first, turning a single read into a read-plus-write. This is why an empty free list shows up as read-latency inflation, not just a write problem.

​

Worked example

free_pages_ratio = 6,400 / 1,000,000 = 0.0064 = 0.64%   -> below 1% threshold

1. The reindex scan is consuming the free list. A cold-table scan pulls new pages in continuously, draining the free list faster than the page cleaner can replenish it. Because dirty pages are simultaneously at 72%, many evictions require a flush-before-evict, which is why the free list cannot recover on its own.
2. Read latency is inflating right now. With the free list nearly empty, each new page read on the OLTP path is queuing behind an eviction (and possibly a flush). Query Latency p95 (ms) will be rising, and InnoDB Buffer Pool Hit Rate % will be dropping as the scan evicts the hot working set.
3. The fix is workload placement, not config. The durable answer is to run the reindex / large scan against a replica so the primary’s pool keeps its hot OLTP working set resident. As an immediate stopgap, raising innodb_io_capacity lets the page cleaner flush and free pages faster, which restores some free-list headroom, but it does not stop the scan from evicting hot pages.

Decision trace:
  - free pages: 0.64% (below 1% floor)
  - dirty pages: 72% (page cleaner cannot return pages fast enough)
  - hit rate (sibling card): dropped from 99.9% to 96.1% in same window
  Conclusion: a cold-table scan on the primary is the single cause.
  Action: move the reindex to the read replica; primary free list and hit
  rate recover within minutes once the scan stops evicting hot pages.

1. A low free count is normal on a warm pool; below the 1% floor is the warning. The alert exists because at that point InnoDB has no slack to absorb read bursts.
2. Free pages and dirty pages are two views of the same pressure. When flushing falls behind, free pages collapse; read them together.
3. The cause is almost always a specific scan or job. Free-list collapse on an otherwise steady instance points at a cold-data scan evicting the hot set, best fixed by moving the job off the primary.

​

Sibling cards merchants should reference together

​

Reconciling against the source

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_free'; for the raw free-page count, and Innodb_buffer_pool_pages_total for the denominator behind the 1% alert. SHOW ENGINE INNODB STATUS\G , the BUFFER POOL AND MEMORY section, which prints “Free buffers” directly alongside “Database pages” and “Modified db pages”. SELECT @@innodb_buffer_pool_size, @@innodb_page_size; to confirm the pool size in bytes and the page size used to convert pages to bytes. On Amazon RDS / Aurora, Performance Insights buffer-pool counters; on Google Cloud SQL, the InnoDB metrics in Cloud Monitoring.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre