Understanding Buffer vs Cache and MySQL’s Flush Strategies

Understanding Buffer vs Cache

Buffer and cache are both used to store data for the application layer, but they serve different purposes.

Differences Between Buffer and Cache

From a translation perspective, Buffer is "缓冲" (buffer) and Cache is "缓存" (cache); they are not the same thing.

At the hardware level, a buffer resides in main memory, while a cache is an on‑CPU integrated cache.

A buffer provides a temporary area that synchronizes devices of different speeds; data written to a buffer is later written to another device.

A cache improves read speed by pre‑loading frequently accessed data; data written to a cache is read by other components.

In software, a buffer is a block‑device buffer, whereas a cache is a file‑system cache. In Linux, the Buffer Cache buffers block‑device operations and periodically syncs them to disk, reducing frequent disk writes.

The Page Cache caches file‑system pages for programs, reducing read‑disk operations.

In short, buffers hold data destined for writing elsewhere, while caches hold data intended for reading elsewhere.

MySQL Buffer Design

MySQL’s buffer architecture includes several layers:

The layers are:

Application layer:

Redo Log Buffer – caches write operations for InnoDB transaction support.

InnoDB Buffer Pool – caches table data in memory to improve read/write performance.

Operating system VFS layer:

Page Cache – OS caches file blocks as pages.

Direct Buffer – used when Direct I/O bypasses the Page Cache.

Disk layer: Disk Buffer – hardware cache on the disk, usually disabled for MySQL.

Write‑Through/Write‑Back and Direct I/O

Write‑Through writes data directly to disk, ensuring durability after a crash; Write‑Back writes only to memory and flushes to disk later.

MySQL controls page‑cache flushing with parameters such as innodb_flush_log_at_trx_commit and innodb_flush_method.

innodb_flush_log_at_trx_commit

This setting balances strict transaction safety and commit performance:

1 (default): Flush log to disk at each transaction commit.

0: Flush log every second; data may be lost on crash.

2: Flush log at commit and every second; data may be lost on crash.

Flush frequency defaults to 1 s, configurable via innodb_flush_log_at_timeout .

innodb_flush_method

This parameter controls how redo log and buffer‑pool data are flushed. Options include:

fdatasync (default, value 0) – fsync for both log and data files.

O_DSYNC (value 1) – O_SYNC for log files, fsync for data files.

O_DIRECT (value 4) – Direct I/O for data files with fsync on each write.

O_DIRECT_NO_FSYNC (value 5) – Direct I/O without fsync for data files.

Only Unix‑like systems are discussed; Windows is omitted.

littlesync and nosync are for internal testing and not recommended.

MySQL Log Flush Strategy

The sync_binlog variable configures binary log flushing:

0 – MySQL does not flush; OS handles it.

1 – Flush before each transaction commit.

N – Flush after N transactions.

This also determines whether Write‑Through or Write‑Back is used.

Typical MySQL Configuration

innodb_flush_log_at_trx_commit=1

– Redo log uses page cache and is fsynced on each commit. innodb_flush_method=O_DIRECT – InnoDB buffer pool uses Direct I/O with fsync on each write.

Redo Log Write Steps

Write to Redo Log buffer.

Write to Page Cache.

fsync flushes dirty pages to disk.

Commit the transaction.

Row Update Steps

Modified data is written to InnoDB Buffer Pool.

Asynchronously:

Dirty pages are flushed via file write.

Data is written to disk.

fsync ensures metadata is persisted.

Reference

[1] Buffer and Cache

[2] MySQL 8.0 Reference Manual – InnoDB Startup Options and System Variables

[3] MySQL 8.0 innodb_flush_method

[4] MySQL 8.0 Reference Manual – Binary Logging Options and Variables

[5] Why MySQL still uses fsync when O_DIRECT is set