InnoDB · mysql-server 8.4.11 source

MySQL 8.4 Data Paths

Follow one transaction or one query from the client down to the disk. Change a setting on the left and the path re-routes: watch which file gets a write(), which gets an fsync(), and what is still sitting in the OS cache when the client gets OK.

row / data page undo redo log binary log fsync: OS cache → disk request / wake-up

Speed Source refs

Steps in this scenario

Click any step to replay it. The list changes as you change settings.

What a crash right after OK would cost

Computed from the settings on the left, following what the commit path actually waits for.

Flush pacing

How hard the page cleaner flushes. It reacts to two things: how many pages are dirty, and how full the redo log is.

Dirty pages in pool Redo log fill innodb_io_capacity innodb_io_capacity_max innodb_max_dirty_pages_pct innodb_adaptive_flushing

Every disk write, in one table

All the places InnoDB and the binlog touch disk, including the background ones the animation summarises. Hover a row to find the file in the diagram.

File	Operation	Done by	When / controlled by

Traced from the MySQL 8.4.11 sources (storage/innobase, sql/binlog.cc, sql/handler.cc). Defaults are the 8.4 compiled defaults on Linux. The animation shows one representative transaction. In a real server, group commit merges many sessions into one write and fsync, and background threads run all the time rather than in sequence. Flush pacing is a simplified version of InnoDB's formula, which also averages over recent flush and redo rates.