MySQL / InnoDB Internals Mind Map

Every MySQL / InnoDB internals visualization on this site on one map. The branches are the main ideas. Each leaf is a page; the grey line under it is the one thing to remember about it. Click a branch to focus on it, click a page to open it.

Recall mode hides the page names. Read the hint, say the name, then click the "?" to check.

1. How the map is organized

Overview of the MySQL / InnoDB internals mind map: Buffer pool, Pages and lookups, MVCC and locks, Durability and recovery, Replication, Server layer. — The map at a glance: 6 branches, 22 pages.

Ask what problem a part of InnoDB solves:

Speed: avoiding disk reads? Caching pages is the buffer pool; the page format and fast ways to search it are pages and lookups.
Correctness with many sessions? Old row versions and locks are MVCC and locks.
Not losing data in a crash? Redo, doublewrite and the binlog handshake are durability and recovery.
Keeping other servers in step? That is replication.

2. The branches side by side

Branch	Main structure	Key setting
Buffer pool	LRU list with young and old parts	`innodb_buffer_pool_size`
Pages and lookups	16 KB clustered index pages	`innodb_adaptive_hash_index`
MVCC and locks	undo log, read view, lock list	`transaction_isolation`
Durability and recovery	redo log, doublewrite, binlog	`innodb_flush_log_at_trx_commit`
Replication	binlog events, GTIDs, relay log	`replica_parallel_workers`

3. Five facts to remember

InnoDB stores the table itself as the primary key B+ tree (the clustered index).
An UPDATE changes the row in place and keeps the old version in the undo log.
REPEATABLE READ is the default; next-key locks stop phantoms for locking reads.
A commit is durable when its redo log is flushed; with the binlog, a two-phase commit keeps the two logs in agreement.
After a crash, a PREPARED transaction is committed only if its Xid is in the binlog.

See all MySQL / InnoDB internals pages in the index, or the other mind maps.