Why MySQL 8.038, 8.4.1, and 9.0 Crash with Thousands of Tables

Background

New MySQL releases promise features, but testing found critical stability problems in recent major versions.

Bug Overview

MySQL 8.0.38, 8.4.1, and 9.0 crash when the number of tables exceeds roughly 10,000, causing the server to restart. Issue tracked as Percona PS‑9306.

Technical Root Cause

The crash originates from bug #115517. When the table count passes about 8,000, InnoDB spawns multiple checking threads; auxiliary threads have an uninitialized THD structure, leading to illegal data‑dictionary (DD) access introduced by commit 28eb1ff.

Performance Impact on Large Schemas

Tests on a schema with one million tables generated by sysbench measured InnoDB startup times: Tablespace_dirs::scan() – 44.4 seconds fetch_global_components(&tablespaces) – 25.5 seconds validate(tablespaces) – 15.8 seconds

Total – 90.7 seconds

The fetch_global_components(&tablespaces) step consumes about 28 % of total time because it reads the DD::tablespace table and builds corresponding objects.

Additional Code Review Findings

dict_name::parse_tablespace_path

passes a std::string by value; using const std::string& would avoid unnecessary copies.

The function handles SUB_PART_SEPARATOR and PART_SEPARATOR but does not account for historic separators #P# and #SP#, which can appear in partition names.

Subsequent call to fil_update_partition_name attempts to resolve these separators, indicating incomplete handling in the original design.

Recommendations

Delay upgrades to newly released MySQL versions; allow at least one year for stabilization before migration.

Perform thorough testing on staging environments, especially for schemas with large numbers of tables.

Consider patching the identified InnoDB functions (e.g., dict_name::parse_tablespace_path) before deployment.

Reference

Percona issue tracker: https://perconadev.atlassian.net/browse/PS-9306