Fix WordPress Error: Table 'wp_options' is marked as crashed and should be repaired

The Error

You try to load your WordPress site or admin dashboard and get a blank page or a database error like this:

WordPress database error: Table 'wp_options' is marked as crashed and should be repaired
for query SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'

Nothing loads. Not the homepage, not wp-admin — nothing. Sometimes you get the full fatal error page; sometimes just a white screen. Either way, WordPress can't read its core settings because wp_options is unreadable.

Why This Happens

wp_options is the backbone of WordPress. It stores your site URL, active plugins, theme settings, and all autoloaded values. On a typical site, this table holds 500–2,000+ rows — and WordPress queries every single one on each page request.

Crashes like this are usually triggered by:

• The server losing power or being force-restarted mid-write
• The mysqld process getting killed during a write operation
• The disk filling up mid-write
• The table running on MyISAM, which has no crash recovery whatsoever

MyISAM has no crash recovery. When a write gets interrupted, the index file goes out of sync with the data file. MySQL detects the mismatch and marks the table crashed.

Step 1: Check Which Tables Are Crashed

Don't assume it's only wp_options. Log in via SSH and check all core tables at once:

mysql -u your_db_user -p your_database_name

Then run:

CHECK TABLE wp_options, wp_posts, wp_postmeta, wp_users, wp_usermeta, wp_terms, wp_term_relationships, wp_term_taxonomy, wp_commentmeta, wp_comments;

Scan the Msg_text column for crashed. Note every affected table — you'll repair them all in one shot.

Step 2: Repair the Table via MySQL CLI (Fastest)

Still in the MySQL shell, run:

REPAIR TABLE wp_options;

Got multiple crashed tables? Fix them together:

REPAIR TABLE wp_options, wp_posts, wp_postmeta;

Expected output:

+--------------------+--------+----------+----------+
| Table              | Op     | Msg_type | Msg_text |
+--------------------+--------+----------+----------+
| yourdb.wp_options  | repair | status   | OK       |
+--------------------+--------+----------+----------+

OK means the repair succeeded. Exit MySQL with \q and reload your site.

Step 3: Repair Using mysqlcheck (No MySQL Login Needed)

Prefer staying in the shell without entering MySQL's interactive mode? Use mysqlcheck directly:

mysqlcheck -u your_db_user -p --repair your_database_name wp_options

To scan and repair everything in your WordPress database at once:

mysqlcheck -u your_db_user -p --auto-repair --check your_database_name

It checks every table, repairs only the broken ones, and skips the rest. No guessing required.

Step 4: Repair via phpMyAdmin (No SSH Access)

No SSH? phpMyAdmin handles this just fine:

• Open phpMyAdmin from your hosting panel (cPanel → phpMyAdmin)
• Select your WordPress database from the left sidebar
• Find wp_options in the table list — it may show a red icon or "crashed" status
• Check the checkbox next to it
• At the bottom of the page, open the dropdown and choose Repair table
• Click Go

A confirmation message appears if the repair succeeded.

Step 5: Repair via WP-CLI (Best for Automation)

WP-CLI users get the cleanest path:

wp db repair --path=/var/www/html/your-wordpress-folder

This runs mysqlcheck --repair across the entire WordPress database. Ideal for cron jobs or when you're managing multiple sites on the same server.

Check database health afterward:

wp db check --path=/var/www/html/your-wordpress-folder

Verify the Fix

Run a quick health check on the repaired table:

mysql -u your_db_user -p your_database_name -e "CHECK TABLE wp_options;"

You want to see OK, not crashed:

+--------------------+-------+----------+----------+
| Table              | Op    | Msg_type | Msg_text |
+--------------------+-------+----------+----------+
| yourdb.wp_options  | check | status   | OK       |
+--------------------+-------+----------+----------+

Load your WordPress site and wp-admin. Back to normal? You're done.

Prevent This From Happening Again

The real fix is converting from MyISAM to InnoDB. InnoDB uses a transaction log, so it rolls back and recovers automatically after an unexpected shutdown. This specific crash simply won't happen.

First, check what engine your tables are currently using:

SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name';

Convert wp_options alone:

ALTER TABLE wp_options ENGINE = InnoDB;

Convert every MyISAM table in one shot with this shell one-liner:

mysql -u your_db_user -p your_database_name -e \
  "SELECT CONCAT('ALTER TABLE ', TABLE_NAME, ' ENGINE=InnoDB;') \
   FROM information_schema.TABLES \
   WHERE TABLE_SCHEMA = 'your_database_name' AND ENGINE = 'MyISAM';" \
  | grep ALTER | mysql -u your_db_user -p your_database_name

MySQL 8.x and MariaDB 10.x default to InnoDB for new installations. Databases created before 2015 — or migrated from old shared hosting — often still run entirely on MyISAM.

After converting, run wp db check one more time to confirm everything is clean.