How to Repair a WordPress Database

Before anything else: take a copy of the database. Repair operations rewrite table files, and a failed repair on an already-damaged table can make recovery harder. If you cannot export it through the admin, export from phpMyAdmin or run mysqldump — the steps are in how to back up a WordPress site.

Recognise a database problem

Genuine corruption looks like this:

• WordPress shows "One or more database tables are unavailable. The database may need to be repaired."
• Specific content disappears while the rest of the site works.
• Saving a post succeeds but the change does not persist.
• Search returns nothing on a site with plenty of content.
• The error log contains Table './db/wp_options' is marked as crashed.

An "Error establishing a database connection" message is different — that is connectivity or credentials, covered in its own guide.

Method 1: the built-in repair page

Add this to wp-config.php, above the "stop editing" line:

<?php
define('WP_ALLOW_REPAIR', true);

Visit https://example.com/wp-admin/maint/repair.php and choose Repair Database, or Repair and Optimize Database if you can afford the extra time.

Then remove the constant. While it is defined, the page is accessible without authentication, which is why it is off by default.

Method 2: phpMyAdmin

1. Open phpMyAdmin from the hosting panel and select the site's database.
2. Tick the affected tables, or use Check All.
3. Choose Check table from the dropdown to see which report errors.
4. For tables reporting problems, choose Repair table.

Repair is only meaningful for MyISAM-family tables. If the engine column says InnoDB, the operation will report that it is unsupported — go to the backup route instead.

Method 3: the command line

With SSH access:

# Check every table and report status.
wp db check

# Attempt repair.
wp db repair

# Reclaim space and rebuild indexes afterwards.
wp db optimize

Or directly with MySQL:

CHECK TABLE wp_posts, wp_postmeta, wp_options;
REPAIR TABLE wp_options;

mysqlcheck --repair --databases wordpress does the same across the whole database when you cannot get an interactive session.

When repair does not work

InnoDB corruption usually cannot be repaired in place. Options, in order of preference:

1. Restore the most recent clean backup. Fastest and safest if you have one from before the corruption.
2. Export what still reads. Dump the tables that respond, create a fresh database, import them, and rebuild what is missing.
3. Ask the host. They may have their own snapshots, and server-level innodb_force_recovery is their call, not yours — it is a read-only rescue mode, not a fix.

Rebuild priority if you are reconstructing: wp_posts and wp_postmeta hold the content, wp_options holds settings, wp_users and wp_usermeta hold accounts, wp_terms and its companions hold taxonomies.

Find the underlying cause

Tables do not corrupt for no reason. The usual causes:

• A full disk. MySQL cannot complete writes and leaves tables mid-update. Check quota first — it is the most common cause and the easiest to miss.
• An unclean shutdown, crash or forced restart during a write.
• Killed processes during a large import or migration.
• A plugin writing enormous rows, particularly logging and analytics plugins on shared hosting.
• Failing storage at the host, which they should be able to confirm.

If corruption recurs, the cause is environmental. Repairing repeatedly without addressing it just delays the next failure.

Reduce bloat while you are in there

A large wp_options table slows every page load because autoloaded options are read on every request. Find the offenders:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Expired transients from removed plugins are the usual candidates. Delete rows only when you recognise what created them, and take a backup before doing it.

Post revisions and spam comments also accumulate; both can be trimmed safely, and both are worth handling before the database grows to the point where backups start failing. Trimming also helps page generation time — the wider picture is in how to speed up a WordPress site.

Verify the repair

Load the front page, an archive, a single post, the admin dashboard and the search results. Save a draft post and confirm it persists after a reload. Run wp db check once more, and confirm the daily backup still completes — a database that repairs but no longer dumps cleanly is still broken.