MySQL Table Marked as Crashed: How to Repair It Safely

Site suddenly throwing database errors, and when you check the MySQL error log you see "Table './username_wp/wp_options' is marked as crashed"? That's not the same problem as a "too many connections" error or a wrong password in wp-config.php - it means a table's data or index file has actually been damaged. Here's how to confirm it, repair it without losing data, and stop it from happening again.

Symptom: what a crashed table actually looks like

A crashed table rarely announces itself cleanly. You'll usually see one of these instead:

• WordPress shows "Error establishing a database connection" even though the credentials in wp-config.php are correct.
• A specific page - often the homepage, a WooCommerce product page, or wp-admin - returns a 500 error while the rest of the site loads fine.
• phpMyAdmin refuses to open a table and shows a red error instead of rows.
• The MySQL error log (/var/log/mysql/error.log or in WHM under Server Status > Service Manager logs) has lines like:

[ERROR] Table './username_wp/wp_options' is marked as crashed and should be repaired
[ERROR] Incorrect key file for table 'wp_posts'; try to repair it

If you can SSH in, confirm it directly instead of guessing from symptoms:

mysqlcheck -u username_dbuser -p username_wp

Any table listed as anything other than OK is the one causing the errors.

Cause: why a table crashes in the first place

Tables don't crash randomly - something interrupted MySQL mid-write or damaged the underlying files. The usual suspects:

• An unclean server restart or crash. If the VPS rebooted, ran out of memory (the OOM killer took MySQL down mid-transaction), or the host had a power event, any table being written to at that moment can end up half-saved.
• Disk full during a write. MySQL can't finish writing an index if the disk runs out of space partway through.
• Killing the MySQL process directly. A kill -9 on mysqld, or a hosting panel force-restart of the database service, skips the graceful shutdown that flushes tables safely.
• Old MyISAM tables specifically. This error is almost exclusively a MyISAM problem - MyISAM stores indexes in a separate .MYI file that's easy to corrupt. InnoDB (the modern WordPress default) handles crashes with transaction logs and almost never needs a manual "repair" in this sense - if InnoDB looks corrupted, that points to a deeper issue like a bad disk sector or a botched migration, not a routine crash.
• A backup or migration tool copying files while MySQL was still writing to them. Copying .MYD/.MYI files directly (instead of using mysqldump) while the database is live is a common way to end up with an inconsistent table.

Fix: repair the table

You have three ways to do this depending on what access you have. Try them in this order.

Option 1: Repair via phpMyAdmin (no SSH needed)

1. In cPanel, go to Databases > phpMyAdmin.
2. Click your database in the left sidebar, then tick the checkbox next to the crashed table.
3. Scroll to the bottom, open the "With selected" dropdown, and choose Repair table.
4. phpMyAdmin runs the repair and shows a status message. Refresh the table and confirm it opens normally.

This works for MyISAM tables and is the safest option if you're not comfortable on the command line.

Option 2: Repair via SSH with mysqlcheck

If you have shell access, this is faster and works across every table in the database at once:

# Check every table in a database
mysqlcheck -u username_dbuser -p username_wp

# Repair only the tables that need it
mysqlcheck -u username_dbuser -p --auto-repair username_wp

# Repair every database on the server (careful on shared/multi-site boxes)
mysqlcheck -u root -p --auto-repair --all-databases

You'll be prompted for the database user's password. --auto-repair only touches tables that actually report a problem, so it's safe to run against a whole database.

Option 3: Manual REPAIR TABLE from the MySQL prompt

If you'd rather target one table directly, log in to MySQL and run the repair statement yourself:

mysql -u username_dbuser -p username_wp
mysql> REPAIR TABLE wp_options;
mysql> CHECK TABLE wp_options;

If the standard repair fails or reports it can't fix the table, MyISAM has an "extended" mode that rebuilds indexes more aggressively - it takes longer but recovers more:

mysql> REPAIR TABLE wp_options USE_FRM;

USE_FRM rebuilds the table from its structure definition when the index file itself is too damaged to read - use it only after the plain REPAIR TABLE fails, since it can drop rows that were only partially written.

Before you repair anything: take a backup

Repair operations rewrite the table's index and, in extended mode, can discard rows MySQL decides are unrecoverable. Before running any repair on a table that matters, export it first:

mysqldump -u username_dbuser -p username_wp wp_options > wp_options_backup.sql

If the repair goes wrong, you can restore from this dump rather than losing data outright. cPanel's own backup tool (Backup Wizard) also works if you'd rather not use SSH.

Prevention: stop it from crashing again

• Convert MyISAM tables to InnoDB. If you're on an older WordPress install or a site that's been migrated a few times, some tables may still be MyISAM. Check with SHOW TABLE STATUS and convert with ALTER TABLE tablename ENGINE=InnoDB; - InnoDB's crash recovery is dramatically more reliable.
• Watch disk space. A full disk during a write is one of the most common crash triggers. Set up a disk usage alert in WHM or check df -h regularly on a VPS.
• Never copy database files directly while MySQL is running. Always use mysqldump, cPanel's Backup Wizard, or stop the service first.
• Avoid force-killing MySQL. Restart the service properly (systemctl restart mysql or through WHM's Service Manager) instead of killing the process.
• Keep MySQL/MariaDB patched. Version upgrades often include storage-engine bug fixes that reduce corruption risk after unexpected shutdowns.

When repair doesn't work

If REPAIR TABLE (even with USE_FRM) still fails, or the table won't open at all, stop trying variations and restore from your most recent clean backup instead - repeated repair attempts on a badly damaged .MYD file can make data recovery harder, not easier. This is also the point to open a support ticket if you're on Getwebup hosting; we can pull a server-side backup or inspect the raw table files without you needing shell access.