InnoDB Comparison: MySQL 5.7 vs MySQL 8.0
MySQL 8.0 delivered the most significant architectural changes to the InnoDB storage engine since MySQL 5.1, affecting redo log management, MVCC and undo storage, the data dictionary, and the SHOW ENGINE INNODB STATUS output format itself. Understanding the differences between MySQL 5.7 and 8.0 InnoDB is essential both for planning migrations and for correctly interpreting status output from servers running different versions. Some 8.0 improvements — like online redo log resizing and atomic DDL — are purely additive. Others — like the removal of the query cache and changes to default variable values — require deliberate reconfiguration before upgrading. This guide compares the most impactful InnoDB differences between MySQL 5.7 and 8.0 from a performance and operations perspective.
Redo Log Architecture Changes
Fixed Files (MySQL 5.7) vs Dynamic Capacity (MySQL 8.0.30+)
In MySQL 5.7, redo log capacity is fixed by innodb_log_file_size × innodb_log_files_in_group, requires a clean shutdown to change, and stores redo log data in static ib_logfile0 and ib_logfile1 files in the MySQL data directory. MySQL 8.0.30+ replaces this with innodb_redo_log_capacity — a single parameter that can be changed online with SET GLOBAL, taking effect without a restart. The redo log files are now stored in a dedicated #innodb_redo/ directory as multiple smaller files (up to 32 by default), making the rotation mechanism smoother and reducing the risk of a single large ib_logfile file becoming a recovery bottleneck. Existing 5.7 configurations can be migrated by simply setting innodb_redo_log_capacity = old_log_file_size × old_log_files_in_group after upgrading.
New LSN Fields and Log Writer Thread in MySQL 8.0
MySQL 8.0 introduced a dedicated log writer thread that handles redo log writes asynchronously, decoupling the redo log write path from transaction commit. In MySQL 5.7, each committing transaction must write its redo log records and then call fsync() on the log file inline with the COMMIT. In 8.0, log writing is handled by a background log_writer thread, and log flushing by a log_flusher thread, with transaction threads only needing to wait for the log_flusher to signal completion. This architectural change reduces commit latency by eliminating the per-thread fsync serialisation bottleneck at high concurrency. The SHOW ENGINE INNODB STATUS LOG section in MySQL 8.0 shows additional LSN fields (log_writer LSN, log_flusher LSN) absent from the 5.7 output, reflecting the more granular logging pipeline.
Transaction and MVCC Improvements
Undo Tablespace Reorganization in MySQL 8.0
MySQL 8.0 reorganised undo tablespace management significantly. In MySQL 5.7, undo logs live primarily in the system tablespace (ibdata1) unless innodb_undo_tablespaces >= 2 is configured — a common misconfiguration that causes ibdata1 to grow indefinitely due to undo log accumulation. MySQL 8.0 creates two undo tablespaces (undo_001 and undo_002) by default, completely separating undo storage from the system tablespace. Automatic undo tablespace truncation (innodb_undo_log_truncate=ON, default) shrinks undo files once all transactions have been purged from them. If you are upgrading from 5.7 with undo logs in ibdata1, the undo data migrates to the new tablespaces on first start, but ibdata1 does not automatically shrink — this requires an explicit ALTER UNDO TABLESPACE operation or a dump-and-restore.
TempTable Engine and Reduced InnoDB Temp Table I/O
MySQL 8.0 replaces the old MyISAM-backed internal temporary tables with the TempTable storage engine (innodb_temp_tablespace_idir, controlled by the TempTable plugin). TempTable stores temporary result sets in memory first, spilling to disk only when the result set exceeds temptable_max_ram (default 1 GB). The spill-to-disk storage uses memory-mapped files rather than InnoDB tablespace pages, reducing InnoDB buffer pool pressure from temporary table operations. For reporting workloads that generate large temporary tables from GROUP BY, ORDER BY, or subquery materialisation, the switch from MyISAM to TempTable can reduce InnoDB I/O significantly. Monitor SELECT * FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE '%TempTable%' to verify TempTable is serving temporary storage in-memory rather than spilling.
Migration and Compatibility Considerations
STATUS Output Format Differences Between Versions
The SHOW ENGINE INNODB STATUS output format differs between MySQL 5.7 and 8.0 in several ways that can break naive text-parsing scripts. MySQL 8.0 adds new sections (REDO LOG, BACKGROUND THREAD detail) and new fields within existing sections (additional LSN types in LOG, per-instance buffer pool statistics). The SEMAPHORES section format changed in MySQL 8.0 to use a structured "RW-latch" notation rather than the older "mutex" format. MySQL 5.7 reports innodb_log_file_size × 2 as total redo capacity, while MySQL 8.0.30+ reports innodb_redo_log_capacity directly. Tools that parse SHOW ENGINE INNODB STATUS programmatically — including Percona Toolkit, innodbstatus.com, and custom monitoring scripts — must handle both formats. Always test monitoring scripts against the specific MySQL version deployed in production.
Deprecated Parameters and 8.0 Replacement Settings
Several MySQL 5.7 InnoDB parameters were deprecated and removed in MySQL 8.0. innodb_file_format and innodb_file_format_max (Antelope/Barracuda) were removed — MySQL 8.0 always uses Barracuda file format. innodb_large_prefix (enabling long index prefixes) was removed — long prefixes are always enabled. innodb_log_checksums was removed — log checksums are always enabled in 8.0. query_cache_size and query_cache_type were removed — the query cache was deprecated in 5.7.20 and fully removed in 8.0. Before upgrading, run mysqlcheck --all-databases on the 5.7 instance and use the MySQL Shell Upgrade Checker utility (util.checkForServerUpgrade()) to identify deprecated settings and table format incompatibilities that must be resolved before the upgrade proceeds safely.