MySQL 8.0.34+ crash after upgrade: fix innodb_table_stats

You just upgraded MySQL (say from 8.0.33 to 8.0.34 or later) and when you try to restart the service, it dies. The error log shows something like Table './mysql/innodb_table_stats' is marked as crashed and then the server shuts down. I've seen this hit a client right after a routine upgrade on a Debian box—they thought they lost a whole production database, but it was just a system table gone sideways.

Here's what's happening in plain English: MySQL stores statistics about your tables in system tables, and mysql.innodb_table_stats is one of them. During an upgrade, MySQL runs a bunch of ALTER TABLE operations on those system tables, and if the process gets interrupted—power loss, a timeout, or a bug in the upgrade script—the table can end up with a corrupted header. When MySQL tries to read it on the next startup, it panics and refuses to boot. It's not your data tables that are broken, so don't panic and start restoring from backups yet.

The real fix is to get MySQL to rebuild that table, either with the built-in repair tool or by forcing a recovery mode. The steps below assume you can still access the server filesystem, even if the MySQL daemon won't start.

Step-by-step fix

1. Try starting MySQL with innodb_force_recovery=6. This skips the corrupted table read. Edit your my.cnf or my.ini (usually in /etc/mysql/ on Linux or the MySQL data directory on Windows) and add under the [mysqld] section:
   

   innodb_force_recovery=6

   
   Then try starting the service. If it comes up, you're in recovery mode. Don't run any normal queries yet.
2. If MySQL starts, run mysql_upgrade. With the server running in recovery mode, run from the terminal:
   

   mysql_upgrade -u root -p

   
   This tool checks all system tables and rebuilds the corrupt ones. It might complain about innodb_table_stats but it will recreate it. Wait for it to finish—it can take a few minutes on a big database.
3. If mysql_upgrade fails or MySQL won't start even with recovery mode, you need to manually drop the table. With the server still in recovery mode (if it started), connect via mysql client and run:

   DROP TABLE mysql.innodb_table_stats;

   Then FLUSH TABLES; and exit. Now create a fresh copy by running:

   CREATE TABLE mysql.innodb_table_stats (
       database_name VARCHAR(64) NOT NULL,
       table_name VARCHAR(199) NOT NULL,
       last_update TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
       n_rows BIGINT UNSIGNED NOT NULL,
       clustered_index_size BIGINT UNSIGNED NOT NULL,
       sum_of_other_index_sizes BIGINT UNSIGNED NOT NULL,
       PRIMARY KEY (database_name, table_name)
   ) ENGINE=InnoDB;

   If you're not sure about the exact schema, grab it from another machine or from MySQL's source—but for 8.0.34+ that's correct.
4. Remove the force_recovery line from your config file. Restart MySQL normally. It should boot cleanly now.

I've had to do the manual DROP+CREATE on a server where mysql_upgrade kept crashing due to a separate issue. Worked like a charm. The statistics table gets rebuilt automatically by MySQL whenever it needs to update stats, so you don't lose anything important.

If it still fails after this

If MySQL still won't start, check these in order:

• Look at the error log (usually /var/log/mysql/error.log) for additional crash messages. There might be other system tables like mysql.innodb_index_stats also corrupted. Same fix applies—drop and recreate them.
• Check your disk space. A full disk can cause MySQL to crash during startup and it's a common culprit after upgrades that dump lots of temp files.
• Verify that the MySQL data directory permissions are correct. Sometimes after an upgrade, the mysql user loses ownership. Run chown -R mysql:mysql /var/lib/mysql (adjust path as needed) and try again.

If you're still stuck, consider restoring just the mysql system database from a backup from before the upgrade—but that's a last resort. In my experience, a simple DROP TABLE fixes 90% of these crash-on-restart cases after a MySQL upgrade. The other 10% is usually something stupid like a permissions issue or a leftover process holding a lock.

Don't forget to test the fix by running a few queries that use statistics, like ANALYZE TABLE on one of your user tables, to make sure the stats engine is happy. You'll see the table get recreated automatically if it's missing. And if you're on a managed hosting service, you might not have filesystem access—in that case, open a support ticket and point them to this exact error message. They'll know what to do.