How to Fix a Crashed MySQL Table in WordPress

This one hit one of the older sites we look after. It broke without a normal error code: no useful message, no stack trace, just a broken site. Blaming the database was an educated guess. A good one, as it turned out:

Table ’./database_name/wp_options’ is marked as crashed and last (automatic?) repair failed

Note the question mark in “(automatic?)”. Even MySQL isn’t sure what it tried. Translation: a table got half-written, MySQL doesn’t trust it anymore, and its own fix didn’t work.

What Does “Crashed Table” Mean?

A table gets corrupted when something yanks the rug out from under a write. The usual suspects:

• Server running out of disk space mid-write
• Unexpected server restart or power loss
• Hardware issues with the storage drive
• MySQL process being killed during an update

MySQL notices, marks the table as “crashed” and tries to repair it on its own. When that fails too, you get the error above, and it’s your turn.

How to Identify the Problem

If the site isn’t giving you anything useful (mine wasn’t), ask MySQL directly:

CHECK TABLE wp_options;

If the table is corrupted, you’ll see a status like Table is marked as crashed in the results.

The Fix

Run this SQL command through phpMyAdmin or your MySQL client:

REPAIR TABLE wp_options USE_FRM;

The USE_FRM flag tells MySQL to rebuild the table structure using the .frm file (the table definition) even if the index file is damaged. It’s more aggressive than a standard repair and works when automatic repair fails.

Note for MySQL 8.0+: there are no .frm files any more, but USE_FRM still works: it rebuilds the index header from the data dictionary instead. Try a plain REPAIR TABLE wp_options; first, because USE_FRM also resets the table’s AUTO_INCREMENT counter.

You should see output confirming the repair succeeded:

Prevention Tips

• Monitor disk space — most crashes happen when the server runs out of room
• Use InnoDB — it handles crashes more gracefully than MyISAM
• Regular backups — corruption sometimes destroys data that even repair can’t recover

When Repair Isn’t Enough

If REPAIR TABLE fails too, you’re down to restoring from a backup or rebuilding the table from scratch. And wp_options is where WordPress keeps the site URL, active plugins and theme settings, so “from scratch” is not a fun afternoon. Have backups. The WordPress security checklist starts with them for a reason.

Scary-looking error, one line of SQL. The real fix is the boring one: watch your disk space and keep backups.