Repair a corrupted WordPress database by first preserving the evidence and making a fresh, readable backup, then matching the symptom to the least invasive tool: WordPress’s temporary browser repair page, phpMyAdmin, or WP-CLI. A connection error is not automatically table corruption. Verify credentials, server health, and resource limits before running repair commands; restore a known-good SQL backup when a table remains unreadable or the database engine reports physical damage.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Identify what actually failed
WordPress can display similar symptoms for very different failures. Repairing tables when the server simply cannot authenticate wastes time and can make recovery harder. Start by recording the exact message, the URL that fails, the time it began, and any table name shown in the error or server log.
As an Amazon Associate I earn from qualifying purchases.
| Symptom or message | Most likely class of problem | First action |
|---|---|---|
| Error establishing a database connection, intermittent downtime, or a site that cannot log in | Wrong DB_HOST, DB_NAME, DB_USER, or DB_PASSWORD; an unavailable MySQL/MariaDB server; exhausted connections, memory, or disk; or a damaged table |
Check wp-config.php, database-server status, hosting resource limits, and the PHP/MySQL error log before repairing tables |
| “Table is marked as crashed,” “record file is crashed,” MySQL Error 145, or failed reads from a named table | Table-level damage, commonly associated with a MyISAM table or an interrupted write | Back up the current database, then run a check/repair on the named table or restore it from a known-good backup |
| A missing column or unknown field appears after a WordPress or plugin update | An incomplete schema migration rather than physical table corruption | Finish the pending WordPress or plugin database upgrade and follow that plugin’s documented migration procedure; do not drop columns or tables |
A connection error can coexist with table damage, but it does not prove it. If the database server is down, no browser repair page or SQL statement can work until the service is available. If credentials are wrong, correcting the configuration is safer than altering data.
Protect the site before attempting repair
WordPress Developer Resources states: “It is strongly recommended that you backup your database at regular intervals and before an upgrade.” Treat repair as a change to production data and make that backup before issuing any check, repair, import, or optimization command.
- Stop new writes where practical. Put the site in maintenance mode, pause publishing and form submissions, and stop import or synchronization jobs. This prevents new rows from changing while you copy or repair the database.
- Capture the evidence. Save the exact front-end and administrator error text, the affected URL, timestamps, table names, recent updates, and relevant PHP/MySQL log entries. These details help a host distinguish a credential problem from an engine failure.
- Export the current database. Keep the original export untouched. Make a separate working copy for experiments so a failed repair does not destroy your only snapshot of the current state.
- Back up the WordPress files separately. A database export contains posts, pages, comments, users, settings, and other database records, but it does not contain themes, plugins, uploaded media, or
wp-config.php. Copy those files as part of the same recovery set. - Check storage and readability. Confirm that the destination has enough free disk space, that the export completed without truncation, and that the file can be opened or tested. Never overwrite the only backup with a new export.
- Record the table prefix and database identity. Read the active
DB_NAMEand$table_prefixvalues fromwp-config.php. A hosting account can contain several databases; repairing the wrong one can damage an unrelated site.
Choose the least invasive repair method
| Method | Access required | Best use | MyISAM and InnoDB considerations | Downtime and host involvement |
|---|---|---|---|---|
| WordPress browser repair | Ability to edit wp-config.php and reach the site’s maintenance URL |
A quick check or repair of standard WordPress tables when shell and phpMyAdmin access are unavailable | Convenient for supported operations, but skipped or unsupported tables need another method | Short maintenance window; no host intervention if the site and database are reachable |
| phpMyAdmin | Hosting control-panel or phpMyAdmin credentials | Selecting particular tables, reviewing status messages, and running a visual repair | Repair is generally meaningful for MyISAM. InnoDB repair may be unavailable or ineffective; use logical export/restore or engine-level recovery instead | Usually brief, but large tables and host limits can interrupt the operation |
| WP-CLI | Shell access, or a host-provided command runner, plus a correct WordPress path | Repeatable checks and repairs with output captured for logs and support | It invokes the database client’s repair operation; engine limitations still apply, so a successful command does not guarantee InnoDB recovery | Can be run during a controlled maintenance window; host help is needed if shell access or permissions are missing |
| SQL backup restore | A verified SQL backup and database import access | A table that remains unreadable, broad corruption, or a failed logical repair | Replaces damaged logical data with the state captured in the backup; it does not fix an underlying failing disk or database server | Requires a planned cutover and potentially longer downtime; host assistance may be needed for large imports |
Method A: use WordPress’s temporary browser repair page
WordPress includes a maintenance page that can check and repair tables after you enable it in wp-config.php. Use this only after making the backup described above.
- Open the active
wp-config.phpfile and add this line before the file’s “That’s all, stop editing” comment:define( 'WP_ALLOW_REPAIR', true ); - Visit
/wp-admin/maint/repair.phpon the affected site. If the front end is unavailable, use the site’s normal HTTPS and hostname rather than a different installation or staging URL. - Run the available check or repair operation. Read the result table by table rather than assuming that a green or completed page means every row is readable.
- Note any table reported as skipped, inaccessible, or still damaged. Those tables require phpMyAdmin, WP-CLI, engine-level recovery, or a restore.
- Remove the
WP_ALLOW_REPAIRdefinition, or set it back to disabled, immediately after the test. The page is intended as a temporary maintenance tool and should not remain exposed.
Browser repair is useful when the database server responds and the problem is limited to tables supported by the operation. It cannot correct a wrong password, a stopped database service, a full disk, or physical storage failure.
Method B: repair selected tables in phpMyAdmin
- Sign in to the hosting control panel and open phpMyAdmin.
- Select the database whose name is in
DB_NAMEin the site’swp-config.php. Do not choose by guesswork if the account contains multiple WordPress installations. - Start with only the table named in the error. If the report clearly indicates broad damage, select the WordPress tables covered by the report rather than unrelated databases.
- Use the table-actions dropdown and choose Repair table. Confirm the result for each selected table.
- For an InnoDB table, the repair option may be missing or may complete without resolving the underlying problem. Do not repeatedly force a MyISAM-style repair onto InnoDB; move to a logical export/import, a verified backup restore, or host-level engine recovery.
- Retest the URL that failed, then inspect PHP and MySQL error logs. A successful phpMyAdmin status message proves only that the requested operation returned; it does not prove that every row, index, or related table is readable.
Repairing only the affected table limits collateral changes. A full-table selection is justified when the error report names widespread corruption and you have a current, verified export.
Method C: check and repair with WP-CLI
Run these commands from the WordPress installation directory after making a fresh backup:
wp db check
wp db repairThe official wp db repair command invokes mysqlcheck --repair=true using credentials loaded from wp-config.php. Save the complete terminal output and compare it with the server log. If the WordPress root is not the current directory, specify it explicitly:
wp --path=/var/www/example.com db check
wp --path=/var/www/example.com db repairWhen the database is reachable only through a remote host, use the environment’s documented SSH or explicit database options, for example an appropriate --ssh target or database connection flags. The exact option values depend on your hosting layout; do not replace working credentials with guesses.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
The broader wp db family also includes dump, export, import, query, and optimize. Use dump or export to create a separate recovery copy and import only into a deliberately chosen database. Do not run reset, drop, or destructive query commands while trying to recover data.
A command that exits successfully still needs a functional test: load the failing page, open representative posts and the administrator area, submit a controlled test action, and check the logs for recurring table or connection errors.
Know when repair is the wrong operation
InnoDB or engine-level errors
InnoDB tables often do not support the same in-place repair workflow as MyISAM tables. Messages about an InnoDB tablespace, repeated server crashes, disk I/O errors, or inability to start the database indicate a database-engine or storage problem rather than a routine WordPress table issue. Stop issuing repair statements and contact the host or a database professional.
Skipped tables or persistent unreadable rows
If the browser page, phpMyAdmin, or WP-CLI reports that a table was skipped or remains unreadable, treat that result as a failed recovery for that table. Repeating the same command is unlikely to recover missing pages or indexes. Move to a known-good SQL backup or host-assisted recovery while preserving the current export.
Missing columns after an update
A plugin or WordPress upgrade can stop partway through a schema migration. The correct path is to complete the pending upgrade, rerun the plugin’s documented database migration, or repair the deployment that was interrupted. Dropping a table because a column is missing can permanently remove otherwise healthy content.
Import timeouts
Large SQL imports can exceed phpMyAdmin’s upload, execution, or proxy limits. Prefer the host’s command-line import facility or database-management tool, and ask the host to raise the relevant limits. Do not split an SQL file blindly: statement order, triggers, character sets, and transaction boundaries can be broken by arbitrary cutting.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Restore a known-good database when logical repair fails
Restoration is usually safer than continued experimentation once a table cannot be read or corruption affects many tables. Prefer a backup from before the first corruption symptom, and verify that it belongs to the same site and uses the same table prefix.
- Choose the restore point. Compare backup timestamps with the first recorded error. A newer backup may contain the damaged state; an older one may lose recently created content, so document that trade-off.
- Keep the damaged database intact. Do not overwrite it until you have a separate export and a rollback plan.
- Create a new empty database where possible. Import the SQL backup into that database rather than testing over the only copy of production. Confirm that the import completes without errors.
- Test a staging copy. Point a staging copy of
wp-config.phpto the restored database. Check the home page, representative posts and pages, comments, media references, login, administrator screens, and any plugin feature that writes data. - Switch production deliberately. Schedule a maintenance window, stop writes, update production configuration to the restored database, and preserve the old database until the verification period ends.
- Restore the matching files. A database-only restore does not bring back themes, plugins, uploads, or
wp-config.php. Restore those from the corresponding file backup, ideally from the same backup set and time period. - Validate the application. Review PHP and database logs, check scheduled jobs, confirm administrator accounts, and test publishing and comments before removing maintenance mode.
If the import fails through phpMyAdmin, use the host’s command line or managed import service. A host can raise execution or upload limits and identify server-side errors that a browser interface cannot expose.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteVerify recovery without creating new damage
- Load the previously failing URL and several unrelated pages to detect a problem that is broader than the original table.
- Open posts, pages, comments, users, menus, and settings that were present before the incident.
- Check that media URLs resolve. The database stores attachment records and paths, but the actual uploads must exist in the restored files.
- Run a controlled write, such as creating and deleting a private test post, only after the read checks succeed.
- Watch PHP and MySQL/MariaDB logs during normal traffic for recurring connection, index, or table errors.
- If credentials may have been exposed during the incident, rotate database credentials, update
wp-config.php, and confirm that the new account has only the privileges required by the site. - Bring WordPress and plugins up to supported versions after the restored site is stable, following each product’s migration instructions rather than applying unrelated bulk changes during recovery.
When to escalate to the host or a database professional
Stop and request specialist help when any of these conditions applies:
- The database server will not start, repeatedly crashes, or reports disk, InnoDB, MyISAM, or filesystem errors.
- A table remains unreadable after one documented logical repair attempt.
- Your export fails, is truncated, cannot be opened, or cannot be imported into a test database.
- You lack the database password, shell access, sufficient privileges, or a reliable way to identify the correct database.
- The site has high write volume and you cannot safely place it in maintenance mode.
- A restore requires changing server storage, recovering a tablespace, or extracting rows from a damaged physical file.
Give the host the exact error text, affected table, timestamps, database engine if known, backup filename and timestamp, export-validation result, and every command or UI action already attempted. Providing this history prevents the same destructive step from being repeated.
Prevent another corrupted database
- Automate database exports on a schedule appropriate to the site’s publishing volume, and retain copies away from the production server.
- Keep at least one immutable or otherwise protected copy so a compromised account, failed disk, or bad deployment cannot rewrite every backup.
- Back up files separately, including themes, plugins, uploads, and
wp-config.php; pair file and database backups when you need a complete point-in-time restore. - Test restores on staging rather than assuming that a successful backup job is recoverable. Verify that the SQL imports, tables can be read, and the application boots with the matching files.
- Monitor disk space, database availability, connection limits, and error logs. Resource exhaustion can present as a database-connection failure before any table is actually damaged.
- Use maintenance mode for major upgrades and confirm that WordPress and plugins finish their database migrations before allowing normal traffic.
The safest sequence is therefore: preserve evidence, make and validate a fresh backup, diagnose the error class, use one least-invasive documented repair method, and restore a verified backup instead of repeatedly modifying a damaged database. Physical corruption, recurring crashes, and missing access credentials belong with the host or a qualified database professional.
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.
Recommended Free Tools
