Fix Corrupted WordPress Database Tables: Repair & Prevent

Your site was fine an hour ago. Now the homepage loads but the blog list is empty, or wp-admin throws "One or more database tables are unavailable" and won't budge. Nothing about your files changed — but somewhere inside MySQL, a table got corrupted, and WordPress doesn't know how to read past it. Here's how to find the damaged table, repair it without losing data, and stop it from happening again.

Symptom: What a Corrupted Table Actually Looks Like

Database corruption rarely takes the whole site down cleanly. It's messier than that. Depending on which table got hit, you might see:

• A white screen or partial page load, with posts, comments, or menus simply missing
• An admin notice reading "One or more database tables are unavailable. The database may need to be repaired"
• PHP errors in your error log mentioning Table './yourdb_wp/wp_posts' is marked as crashed and should be repaired
• Search or the block editor timing out, while the rest of the site works normally
• phpMyAdmin refusing to open a specific table, or showing a red warning icon next to it in the table list

That last symptom is the fastest way to confirm it's actually a table issue and not a plugin conflict or a memory limit problem — if phpMyAdmin itself is flagging a table, you're in the right place.

Cause: Why Tables Get Corrupted

WordPress tables usually corrupt for one of a handful of reasons, and knowing which one hit you changes what you should do afterward:

• An interrupted write. The server crashed, ran out of disk space, or MySQL was restarted mid-query — often during a large plugin update or import.
• An abrupt process kill. A hosting-level resource limit killed a long-running import or backup script partway through writing to a table.
• Bad disk sectors or filesystem issues. Rare on managed hosting, more common on aging VPS storage.
• A dirty migration or restore. A .sql file that was only partially imported, or copied while the source database was still being written to.

MyISAM tables (older WordPress installs, and some plugins still create them) are far more prone to this than InnoDB, which has built-in crash recovery. If you've never converted your tables, that's worth doing once you're back up and running — more on that below.

Fix: Repair the Table Without Losing Data

Repairing a table rebuilds its index and, in most cases, recovers the rows intact. It's not the same as restoring from backup, and it's almost always your first move — not your last.

Step 1 — Back Up First, Even If It's Already Broken

Before you touch anything, export the database as-is. A corrupted table can often still be exported, and having a snapshot means you can't make things worse.

mysqldump -u yourdb_user -p yourdb_name > pre-repair-backup.sql

In cPanel, you can also just download a full backup from Backup > Download a MySQL Database Backup before proceeding.

Step 2 — Repair via phpMyAdmin (Easiest)

1. Open phpMyAdmin from cPanel and select your WordPress database
2. Tick the checkbox next to the affected table (or select all tables if you're not sure which one is bad)
3. From the "With selected" dropdown at the bottom, choose Repair table
4. phpMyAdmin will show a status message per table — OK means it's fixed

Step 3 — Repair via WP-CLI (Fastest If You Have SSH)

If your plan includes SSH access, terminal" class="auto-link">WP-CLI can repair the entire database in one command:

wp db repair --allow-root

This runs a REPAIR TABLE against every table in the WordPress database and reports which ones needed fixing. Follow it with an optimize pass while you're in there:

wp db optimize --allow-root

Step 4 — Repair via Raw SQL (No WP-CLI, No phpMyAdmin GUI Access)

If you only have MySQL command-line access, the direct route works on any MyISAM table:

REPAIR TABLE wp_posts;
REPAIR TABLE wp_options;

Run CHECK TABLE wp_posts; first if you want to confirm which tables are actually flagged before repairing all of them.

What If Repair Fails or Rows Are Missing Afterward?

Occasionally a table is damaged badly enough that repair recovers the structure but not every row — usually the most recently written ones. If that happens, restore just that table from your most recent clean backup rather than the whole database, so you don't lose newer content that's still intact elsewhere:

mysql -u yourdb_user -p yourdb_name < backup.sql --tables wp_posts

If you're on SkyServer shared or managed VPS hosting and don't have a recent backup handy, open a support ticket — nightly account-level backups are kept on a rolling window and we can pull the last known-good copy of just that table.

Repair Method Comparison

Prevention: Stop It Happening Again

A repaired table is fine, but the underlying cause is worth addressing so you're not doing this again next month.

• Convert MyISAM tables to InnoDB. In phpMyAdmin, select a table, go to Operations, and change the storage engine — InnoDB handles crashes far more gracefully and supports row-level locking, which also helps with the "too many connections" pile-ups that plague busy MyISAM sites.
• Watch your disk space. A database that runs out of disk mid-write is one of the most common causes of corruption. Set up an alert well before you hit 100% usage.
• Avoid killing long imports. If a large SQL import is running, let it finish or cancel it cleanly rather than closing the terminal or browser tab mid-transfer.
• Schedule a weekly optimize pass. A simple cron job running wp db optimize keeps table overhead low and surfaces problems early, before they cascade into a crash.
• Keep backups outside the same disk. If the corruption was caused by a failing drive, a backup stored on that same drive won't help you.

Frequently Asked Questions

Will repairing a table delete my posts or comments?

No — REPAIR TABLE rebuilds the table's structure and index using the data that's still readable. It doesn't intentionally delete anything. In rare cases where part of the table was physically unreadable before the repair, those specific rows may be lost, which is why exporting a backup first matters even when the database is already broken.

How do I know which table is actually corrupted?

Check your PHP error log for a line like Table './yourdb_wp/wp_posts' is marked as crashed, or run CHECK TABLE tablename; in phpMyAdmin's SQL tab against your core WordPress tables one at a time. The status column will say OK or flag the problem.

Should I repair the whole database or just the affected table?

Repairing just the flagged table is safer and faster. Running a full-database repair isn't harmful, but it takes longer on large sites and touches tables that were never broken in the first place.

Does converting to InnoDB fix corruption for good?

It won't make corruption impossible, but InnoDB's crash recovery is significantly better than MyISAM's, and it recovers automatically from most abrupt shutdowns without needing a manual repair. It's the single biggest improvement you can make if you're still on MyISAM tables.

My repair keeps failing with "table doesn't exist" errors. What now?

That usually means the corruption affected the table's .frm or index files badly enough that MySQL can't even locate the table definition. At that point, restoring from a recent backup is more reliable than continuing to attempt repairs — contact your host's support team if you don't have direct file-level access to the MySQL data directory.