WordPress: 'One or More Database Tables Are Unavailable' Fix

You open your site and instead of your homepage you get one blunt line: "One or more database tables are unavailable. The database may need to be repaired." No stack trace, no wp-admin, nothing. If you've already ruled out a wrong password in wp-config.php — that error looks different, it says "Error establishing a database connection" — you're dealing with a damaged table, not a connection problem. Here's how to get back up without losing content.

Symptom: What This Error Actually Means

WordPress can reach your MySQL server and log in fine. It just can't read one or more tables it needs — usually wp_options, wp_posts, or a table a plugin created. MySQL itself is flagging the table as corrupted, and WordPress is passing that flag straight to your screen instead of crashing silently.

A few things confirm you're in the right place before you touch anything:

• wp-admin is also unreachable, or loads partially and then breaks on a specific screen (often Posts or Settings).
• The front end shows the same message, not a blank white screen or a PHP fatal error.
• The site was working, then something interrupted it — a bad shutdown, a killed process, a disk that filled up mid-write, or a migration/import that got cut off.

If you can see the MySQL error log (in WHM under Server Status > Service Manager, or /var/log/mysql/error.log on a VPS), a corrupted table usually logs a line like Table './yourdb/wp_options' is marked as crashed. That confirms it — you're not chasing a permissions or credentials issue.

Cause: Why the Table Got Marked as Corrupted

Tables don't corrupt on their own. Something interrupted MySQL while it was in the middle of writing:

• An unclean restart. The VPS rebooted, ran out of memory and the OOM killer took MySQL down, or the host had a power blip while a table was mid-write.
• Disk full during a write. If the disk ran out of space while WordPress was saving a post or a plugin was writing to its own table, the write can leave the table half-updated.
• A killed MySQL process. A forced restart of the database service (not a graceful stop) skips the flush that keeps tables consistent.
• An interrupted import or migration. A large SQL import that timed out partway through, or a migration plugin that got killed by a PHP execution limit, can leave a table in an inconsistent state.

Older MyISAM tables are far more prone to this than InnoDB, which is the default storage engine for WordPress installs today. If you're on InnoDB and still seeing this, it usually points to something more serious — a bad disk sector or a genuinely botched migration — worth a support ticket rather than a DIY repair.

Fix: Use WordPress's Built-In Repair Tool

WordPress ships with a repair page that most people never know exists, because it's disabled by default for a good reason — anyone who finds the URL can run it, no login required. You turn it on for one session, use it, then turn it back off.

Step 1: Enable the repair constant

Open wp-config.php via cPanel File Manager or SFTP and add this line above the "That's all, stop editing!" comment:

define( 'WP_ALLOW_REPAIR', true );

Step 2: Load the repair page

Visit:

https://yourdomain.com/wp-admin/maint/repair.php

You'll get two buttons: Repair Database and Repair and Optimize Database. Pick the first one — optimize is a separate maintenance task and not something you want to run blind on a table that's already damaged. WordPress runs CHECK TABLE and REPAIR TABLE against every core table and reports what it found, one line per table.

Step 3: Read the results, don't just close the tab

Most tables will report "OK." The ones that were actually broken will show a repair status. If a table repairs cleanly, you're done — reload your site and confirm it loads. If a table reports it "couldn't be repaired," that's usually deeper MyISAM corruption than the built-in tool can fix, and you'll need to repair it manually via phpMyAdmin (Databases > phpMyAdmin in cPanel, select the table, choose Repair table from the "With selected" dropdown) or with mysqlcheck --auto-repair over SSH if you have shell access.

Step 4: Turn the repair page back off

This is the step people skip. Remove the line you added, or set it to false:

define( 'WP_ALLOW_REPAIR', false );

Leaving it set to true means /wp-admin/maint/repair.php stays reachable by anyone, logged in or not, indefinitely. It's a low-severity issue on its own, but it's an easy thing for a security scan to flag and an easy thing to just close off.

Prefer the Command Line? Use WP-CLI

If you have SSH access and WP-CLI installed, skip the browser entirely:

wp db repair

This runs the same repair routine as the web UI without needing to edit wp-config.php or expose the repair endpoint at all — WP-CLI already runs with database credentials, so there's nothing to leave open afterward. If you're not sure WP-CLI is installed, check with wp --info first.

What If the Site Still Won't Load After Repair

Two things to check before assuming it's still broken:

• Clear any object cache (Redis, Memcached, or a caching plugin) — a stale cached query against the old, broken table state can make the site look unfixed even after the repair succeeded.
• Check wp-content/debug.log if WP_DEBUG_LOG is on — if a specific plugin table failed to repair, the error will usually point to a plugin-specific query, not core WordPress.

Prevention: Stop This From Happening Again

• Take regular database backups — cPanel's backup wizard or a plugin like UpdraftPlus, scheduled daily, means a corrupted table is a five-minute restore instead of a repair gamble.
• Watch disk usage. A full disk mid-write is one of the most common causes here, and it's fully preventable with basic monitoring or a cPanel disk usage alert.
• If you're still on MyISAM tables from an old install, consider converting to InnoDB — it handles unclean shutdowns with transaction logs instead of leaving half-written index files behind.
• Avoid killing long-running imports or migrations manually. Let them time out or fail on their own rather than force-stopping the process mid-write.

This error looks alarming because it takes the whole site down at once, but it's rarely a data-loss event. Run the repair, confirm the tables come back clean, close the door behind you, and you're back to normal in a few minutes.