How Many Rows Can a Single InnoDB B+ Tree Store?

InnoDB stores data in pages of 16 KB, which are the smallest storage units for the engine; a typical row size of about 1 KB means a leaf page can hold roughly 16 rows.

Each internal (non‑leaf) node stores key‑pointer pairs. Assuming an 8‑byte BIGINT primary key and a 6‑byte pointer, each pair occupies 14 bytes, allowing about 1 170 such pairs per 16 KB page.

Therefore, a B+‑tree of height 2 (root + leaf) can store 1 170 × 16 ≈ 18 720 rows, while a tree of height 3 can store 1 170 × 1 170 × 16 ≈ 21 902 400 rows, easily reaching the tens of millions of records typical in many applications.

In practice, the root page of a primary‑key index is always page number 3 in the tablespace file; the page‑level field at offset 64 within that page indicates the tree height (height = page level + 1). Using tools such as hexdump on the tablespace file, one can read this value to verify the actual B+‑tree height.

Example query: select * from user where id=5; When the B+‑tree is traversed, the root page directs the search to the leaf page containing the record, which might look like: | 5 | zhao2 | 27 | Empirical tests on the TPC‑H benchmark tables (e.g., customer , lineitem ) show that even with millions of rows the primary‑key B+‑tree height remains 3, meaning only 1‑3 I/O operations are needed for a point lookup.

Because B+‑trees keep data only in leaf nodes, they have a higher fan‑out than B‑trees, resulting in shallower trees and fewer I/O operations, which is why MySQL uses B+‑trees for indexing.

In summary, a single InnoDB B+‑tree can store tens of millions of rows, its height is typically 1‑3 levels, and the height can be determined by inspecting the page‑level field of the root page in the tablespace file.