Inside InnoDB: Unpacking MySQL’s Table Space, Segments, Extents, Pages & Rows

Overall Structure

InnoDB’s logical structure is hierarchical, consisting of table space, segment, extent, page, and row.

Table Space

A table space is the top‑level container for all InnoDB data. By default MySQL creates a shared tablespace file ibdata, but it also supports independent per‑table tablespaces (file‑per‑table mode), where each table gets its own file.

The table space manages overall data storage and is the core of InnoDB’s architecture.

Segment

Segments are logical components within a tablespace used to store different kinds of data. Types include data segments (holding table rows), index segments (holding index structures), and undo segments (holding transaction rollback information). InnoDB’s algorithms manage these segments to optimize access performance and space utilization.

Extent

An extent is a group of contiguous pages inside a segment, typically 1 MB in size (64 pages of the default 16 KB page size). When the page size changes, the extent size adjusts accordingly. Initially InnoDB allocates 32 fragmented pages to improve space usage for small tables, then gradually uses more contiguous pages as data grows. Extents are allocated dynamically on demand to avoid pre‑allocating large disk areas.

Page

A page is the smallest unit of disk I/O in InnoDB, defaulting to 16 KB but configurable via the innodb_page_size parameter (e.g., 8 KB, 16 KB, 32 KB). InnoDB defines several page types:

Data page : stores table records.

Undo page : stores transaction rollback information.

System page : stores metadata.

Index page : stores index entries.

Insert buffer bitmap page, transaction‑related pages, etc. : handle finer‑grained storage tasks.

Pages are the key building blocks that enable efficient data management in the storage engine.

Row

Rows are the fundamental data units stored inside pages. InnoDB supports two row formats—Compact (default) and Redundant. Each row contains the primary key, column values, and internal metadata such as flags and transaction IDs. Large column values (e.g., BLOB or TEXT) that exceed the page capacity are stored off‑page in overflow pages with a pointer.

Rows are stored in clustered tables, meaning the physical order of rows follows the primary‑key order. If a table lacks an explicit primary key, InnoDB creates a hidden 6‑byte surrogate key. This layout yields high performance for primary‑key lookups and ensures physical and logical order alignment.

InnoDB also employs row‑level locking to manage concurrent transactions, providing isolation and consistency for OLTP workloads.

Conclusion

By organizing data into a hierarchy of table space, segment, extent, page, and row, InnoDB achieves efficient storage, dynamic allocation, and flexible performance tuning, forming a solid foundation for understanding MySQL’s storage mechanisms.