Free tools Windows power users keep installed
One-click scans. No signup required.
A corrupted WordPress database should be treated as a data-recovery incident, not a routine optimization task. First preserve the evidence and export the current database. Then determine whether the failure is a connection or configuration problem, a damaged table, or an incomplete software upgrade. Use the least invasive method that matches your access—WordPress’s temporary browser repair page, phpMyAdmin, or WP-CLI—and restore a known-good backup when logical repair cannot make the data readable.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Do not overwrite your only backup, run reset or drop commands, or repeatedly retry a failing server. A database repair can bring back posts, pages, comments, users, and settings, but a database dump does not contain themes, plugins, media uploads, or wp-config.php; those files must be backed up and restored separately.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
What “corrupted WordPress database” actually means
WordPress stores content and configuration in MySQL or MariaDB tables. “Corruption” is often used for several different failures that need different fixes:
- Connection or configuration failure: WordPress cannot authenticate or reach the server. Incorrect
DB_HOST,DB_NAME,DB_USER, orDB_PASSWORDvalues, an unavailable database service, exhausted server resources, or a damaged table can all produce “Error establishing a database connection.” - Table damage: MySQL reports messages such as “table is marked as crashed,” “record file is crashed,” or MySQL Error 145. These messages identify a table that needs a check, repair, engine-level recovery, or restoration.
- Schema or migration failure: A missing column immediately after a WordPress or plugin update can mean that an upgrade stopped halfway. It is not proof of physical table corruption. Complete the pending WordPress or plugin migration before editing tables.
The exact error, the named table, and the time the problem began determine the safest path. Save those details before changing anything.
Preserve evidence and make a backup before repair
WordPress Developer Resources states: “It is strongly recommended that you backup your database at regular intervals and before an upgrade.” Follow that advice even when the database already appears damaged. A backup made after corruption may still contain readable rows that a later repair could remove.
Immediate incident checklist
- Record the failure. Copy the complete browser message, MySQL error number, table name, timestamp, and the URL that fails. Save relevant PHP and database-server log entries.
- Stop new writes. Put the site in maintenance mode, or temporarily block forms, checkouts, imports, scheduled jobs, and other processes that could continue writing while you investigate.
- Export the current database. Keep the original export untouched. Make a second working copy for repair experiments, and record the filename and time of each attempt.
- Back up the WordPress files separately. Copy themes, plugins, the uploads directory, and
wp-config.php. They are not included in a database export. - Check storage and readability. Confirm that the destination has enough free space and that the SQL file can be opened or inspected. Never replace the only backup with a new export.
If the server is out of disk space, resolve that condition before running repair or creating another dump. A failed export is not evidence that no recoverable data exists.
Diagnose the failure before choosing a repair tool
Connection and authentication symptoms
An “Error establishing a database connection” page, intermittent timeouts, or a site that cannot authenticate does not automatically mean a crashed table. Compare the values in wp-config.php with the database and hosting account, verify that MySQL or MariaDB is running, and check whether the host has imposed memory, connection, or disk limits. If credentials or server availability are wrong, table repair will not solve the outage.
Table-damage symptoms
A named table that is “marked as crashed,” a “record file is crashed” message, MySQL Error 145, or failed reads from one table points toward CHECK TABLE/REPAIR TABLE operations or a restore. WordPress advises administrators who are uncomfortable with phpMyAdmin to ask their host to run the checks instead of guessing at SQL.
Missing-column and upgrade symptoms
If an update introduced an “unknown column” error, identify which WordPress or plugin release was being installed. Finish the pending database upgrade and follow that plugin’s documented migration procedure. Destructive table repair can make an incomplete migration harder to recover.
Choose the least invasive method you can safely use
| Method | Access required | Best fit | MyISAM support | InnoDB support | Partial-data preservation | Typical downtime and host involvement |
|---|---|---|---|---|---|---|
| WordPress browser repair | Edit wp-config.php and visit a browser URL |
A quick check or repair when WordPress files still run | Can invoke the available database repair | May skip or fail; use another method | Depends on the underlying database operation | Short maintenance window; host help if tables are skipped |
| phpMyAdmin | Hosting panel and database login | Selecting specific tables and inspecting results | Repair action is generally available | Repair action may be unavailable or ineffective | Can target only affected tables, but export first | Usually short; host assistance for limits or engine errors |
| WP-CLI | Shell access or a host-provided command runner | Repeatable checks, scripted backups, and server-side recovery | Runs the database check/repair utility | May not repair physical InnoDB corruption | Use dumps and targeted queries; avoid destructive commands | Depends on command runtime; host help for server-level failures |
| Restore a known-good SQL backup | Database import access and a verified backup | Repair fails, rows remain unreadable, or corruption is physical | Replaces damaged structures with the backup copy | Recreates the database from a consistent logical export | Only data present in the backup; newer changes may be absent | Planned outage recommended; host may need to run large imports |
Start with a check or export, not a repair. If the database engine reports disk, InnoDB, or repeated crash errors, skip repeated logical repairs and escalate.
Method A: WordPress’s temporary browser repair page
WordPress includes a maintenance repair page controlled by the WP_ALLOW_REPAIR constant. It is useful when you can edit the configuration file but do not have database-shell access.
- Complete the backup and evidence steps above.
- Open the site’s
wp-config.phpand add this line before the file’s “stop editing” comment:
define( 'WP_ALLOW_REPAIR', true );- Visit
/wp-admin/maint/repair.phpon the affected site. Use the available check or repair operation and wait for the complete result. - Read the output table by table. Note any table that was skipped, could not be checked, or returned an error.
- Remove the constant, or disable it, immediately after the maintenance work. The page is intended as a temporary tool and should not remain enabled.
- Clear maintenance mode and retest the original failing URL, login, editing screens, scheduled jobs, and a representative post or page.
A successful page response does not prove that every row is readable. Skipped tables generally require phpMyAdmin, WP-CLI, engine-level recovery, or a restore from backup.
Rank #3
Method B: Repair tables in phpMyAdmin
phpMyAdmin provides a visual way to identify and target affected tables. The labels vary slightly by hosting panel, but the sequence is consistent.
- Sign in to the hosting control panel and open phpMyAdmin.
- Open the database named in
wp-config.php. Do not guess when the account contains multiple WordPress databases. - Use the recorded error to select only the affected table first. Select all WordPress tables only when the error report clearly indicates broad damage and your export is complete.
- Choose Repair table from the table-actions dropdown, then wait for the result. Save the exact status text.
- Re-test the failing URL and inspect the PHP and MySQL error logs. A green or “successful” interface message does not guarantee that every row can be read.
Why the storage engine matters
MyISAM tables support the traditional repair operation used by mysqlcheck. InnoDB tables are different: phpMyAdmin may not offer a repair action, or the action may not correct physical corruption. For InnoDB problems, make a logical export if possible, ask the host for engine-level recovery, or restore a verified backup. Do not convert engines or delete tables merely to make a menu option appear.
Method C: Check and repair with WP-CLI
WP-CLI is appropriate when you have shell access, a host command runner, or a staging copy. Run commands from the WordPress installation directory, or supply the correct path explicitly.
- Make and verify a database dump before issuing repair commands.
- Check the tables:
wp db check- If the check identifies repairable damage, run:
wp db repair- Capture the command output and correlate it with the database-server log. Repeat the site tests only after the command finishes.
The official wp db repair command invokes mysqlcheck --repair=true with credentials loaded from wp-config.php. The broader wp db family also provides dump, export, import, query, and optimize operations. Use --path when the WordPress root is not the current directory, --ssh when the command must run on the web host, or explicit database options when configuration differs from the default.
Do not use reset, drop, or equivalent destructive commands while attempting recovery. A repair command that completes without a fatal error still needs application and log validation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When repair fails: restore a known-good database
Restoration is usually safer than repeated repair when tables remain unreadable, the engine reports physical errors, or the first corruption symptom predates your current export. Prefer a backup from before the incident and verify that it belongs to this site and uses the same table prefix.
Use a staging database first
- Create a new empty database where the host permits it. Avoid overwriting the damaged database until the import has been validated.
- Import the SQL backup into the new database. For large files, use the host’s command-line or database-import facility; browser uploads can time out. Ask the host to raise execution or upload limits rather than splitting SQL blindly.
- Point a staging copy of
wp-config.phpto the new database and test the site privately. - Check posts, pages, comments, users, settings, menus, widgets, custom post types, and plugin-specific data. Compare the table prefix and character-set settings with the original installation.
- After validation, schedule a maintenance window, switch production to the restored database, and keep the damaged database and original export untouched until the site has operated normally.
Restore the matching files too
A database-only restore brings back the records stored in the database: content, comments, users, and settings. It does not restore the themes, plugins, uploads, or wp-config.php required by the running site. Restore those files from the same backup set when possible. Mixing a database from one release with files from an incompatible release can create new schema or plugin errors.
Account for changes after the backup
A backup from before corruption may omit legitimate posts, comments, orders, or settings created afterward. Preserve the damaged database and current export so a professional can attempt selective extraction if those changes matter. Do not promise that a repair or restore can reconstruct rows that were never present in a backup.
Validate the site after repair or restore
Use a deliberate test list instead of relying on the home page alone:
- Open the original failing URL and several older and newer posts.
- Log in as an administrator and confirm that the dashboard, media library, menus, widgets, and settings load.
- Create and edit a test draft, then save and reopen it.
- Submit a controlled comment or form if the site uses them.
- Run due scheduled jobs and check that cron tasks are not repeatedly failing.
- Review PHP, web-server, and database logs for new errors after the repair.
- Confirm that plugins and themes load from the restored file set and that uploads resolve.
If only one table was repaired, test the features that read and write that table. For example, a damaged wp_options table can affect login, plugin settings, scheduled tasks, and basic site bootstrap even when posts remain readable.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When to stop and escalate
Contact the hosting provider or a database professional when any of these conditions applies:
- Tables remain unreadable after a logical check or repair.
- The server reports disk, InnoDB, MyISAM, filesystem, or repeated crash errors.
- Exports fail, cannot be opened, or do not complete because of resource limits.
- You lack database credentials, shell access, or permission to create a staging database.
- The database is very large, contains business-critical transactions, or requires selective row recovery.
- You suspect unauthorized access or credential exposure.
Send the professional the exact error text, affected table, timestamps, backup filename, database engine if known, and every command or UI action already attempted. Providing this timeline is safer than repeatedly trying different repairs without a record.
Secure the site after recovery
- Rotate database credentials if they may have been exposed, then update the matching values in
wp-config.php. - Update WordPress, plugins, and themes from trusted sources after the restored site is stable. Complete any pending database migrations one at a time.
- Review administrator accounts, scheduled jobs, and unfamiliar options or plugins.
- Remove temporary repair constants, maintenance files, and exported SQL files from publicly reachable directories.
- Take a fresh backup after validation and label it with the date, WordPress version, database version, and file set.
Prevent the next database incident
Use automated, off-site database exports on a schedule appropriate to how often the site changes. Keep at least one immutable copy that routine jobs cannot overwrite, and test a restore on staging rather than assuming that a successful backup job is usable. Back up the database and WordPress files as separate, identifiable components, then document how to reconnect them through wp-config.php.
Before every WordPress or plugin upgrade, create a fresh database and file backup, confirm available disk space, and record the current versions. Monitor database and PHP logs for recurring warnings, and investigate intermittent connection failures before they become table damage. A tested restore is the only reliable proof that your recovery plan works.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
