InnoDB
The default storage engine for MySQL, using a B+ tree index structure. It supports full ACID transactions and row-level locking, balancing read/write performance with data consistency. InnoDB is the most widely used storage engine in MySQL production environments.
Core Facts
Timeline (last 90 days)
Migrating online business from InnoDB to Iceberg is not just a matter of changing the connection string, but requires redefining the trade-offs among consistency, latency and cost.
InnoDB excels at high-frequency small transactions and low-latency point lookups, while Iceberg excels at massive batch writes, analytical scans and schema evolution.
InnoDB's complexity comes from the premise of 'in-place updates', while Iceberg's simplicity comes from the premise of 'immutable files'; when choosing a storage solution, one should first determine the write pattern and storage medium before deciding the metadata form.
InnoDB is MySQL's row-based storage engine, oriented toward online transaction processing, with data organized in 16KB pages, and the table itself is a B+ tree ordered by primary key (a clustered index).
InnoDB's write path is log-first: any modification is first written to the redo log, then dirty pages are flushed asynchronously; after a crash, recovery is done by replaying redo, and rollback and multi-version reads are achieved through undo.
InnoDB's MVCC is implemented by modifying rows in place and tracking old versions with an undo chain: each row hides a transaction ID and a rollback pointer, and the rollback pointer strings together old versions in the undo log to form a version chain; read committed (RC) generates a new snapshot on each statement execution, while repeatable read (RR) generates a snapshot at transaction start.
InnoDB's old versions do not disappear automatically; the purge thread must asynchronously clean them up after confirming that no earlier active transaction references them; long transactions hold back purge, causing undo space to bloat.
The key reason InnoDB uses a B+ tree rather than a B tree is that B+ tree non-leaf nodes store only keys and no data, so a single page can hold more index entries, resulting in lower tree height and fewer disk IOs.
On the same hardware, MyRocks achieves approximately 50% storage space reduction compared to InnoDB while reducing write I/O by approximately 60%.
All Facts (11)
MySQL's InnoDB storage engine uses the B+ tree as the default index data structure.
65%UnverifiedMySQL's LIMIT offset, N pagination method has a deep pagination performance problem: even if only N records need to be returned, it must first scan and discard the preceding offset records.
60%UnverifiedMigrating online business from InnoDB to Iceberg is not just a matter of changing the connection string, but requires redefining the trade-offs among consistency, latency and cost.
50%UnverifiedInnoDB excels at high-frequency small transactions and low-latency point lookups, while Iceberg excels at massive batch writes, analytical scans and schema evolution.
50%UnverifiedInnoDB's complexity comes from the premise of 'in-place updates', while Iceberg's simplicity comes from the premise of 'immutable files'; when choosing a storage solution, one should first determine the write pattern and storage medium before deciding the metadata form.
50%UnverifiedInnoDB is MySQL's row-based storage engine, oriented toward online transaction processing, with data organized in 16KB pages, and the table itself is a B+ tree ordered by primary key (a clustered index).
50%UnverifiedInnoDB's write path is log-first: any modification is first written to the redo log, then dirty pages are flushed asynchronously; after a crash, recovery is done by replaying redo, and rollback and multi-version reads are achieved through undo.
50%UnverifiedInnoDB's MVCC is implemented by modifying rows in place and tracking old versions with an undo chain: each row hides a transaction ID and a rollback pointer, and the rollback pointer strings together old versions in the undo log to form a version chain; read committed (RC) generates a new snapshot on each statement execution, while repeatable read (RR) generates a snapshot at transaction start.
50%UnverifiedInnoDB's old versions do not disappear automatically; the purge thread must asynchronously clean them up after confirming that no earlier active transaction references them; long transactions hold back purge, causing undo space to bloat.
50%UnverifiedThe key reason InnoDB uses a B+ tree rather than a B tree is that B+ tree non-leaf nodes store only keys and no data, so a single page can hold more index entries, resulting in lower tree height and fewer disk IOs.
50%UnverifiedOn the same hardware, MyRocks achieves approximately 50% storage space reduction compared to InnoDB while reducing write I/O by approximately 60%.
50%