iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
A corrupted WordPress database is not always a database problem. First preserve the error, stop new writes, and export the current database. Then determine whether the failure is a connection/configuration issue, a damaged table, or an incomplete schema upgrade. Use the least invasive option available—WordPress’s temporary browser repair page, phpMyAdmin, or WP-CLI—and restore a verified SQL backup when logical repair cannot make the table readable.
Start with evidence and a recoverable backup
Do not begin by clicking Repair, dropping tables, or repeatedly refreshing the site. A repair command can change indexes or discard unrecoverable rows, while continued visitor, cron, checkout, or editor activity can keep writing to the damaged database. Preserve what exists before attempting a fix.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Put the site in maintenance mode. Use your host’s maintenance control or a temporary maintenance file so that visitors and scheduled jobs do not create new writes. If maintenance mode is unavailable, pause background jobs and make the repair during a quiet period.
- Record the exact failure. Copy the complete browser message, the URL that produced it, the time in UTC, and any named database or table. “Error establishing a database connection” is a different starting point from “table is marked as crashed” or MySQL error 145.
- Export the current database before repair. Use your host export tool, phpMyAdmin, or
wp db export. Keep this export untouched. Make a second working copy for tests, and do not overwrite the only copy with a repaired dump. - Back up the WordPress files separately. A database dump contains posts, pages, comments, users, settings, and other database records, but it does not contain themes, plugins, uploads, 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 and that the SQL file can be opened or imported into a separate test database. A backup that cannot be read is not a recovery plan.
WordPress Developer Resources states: “It is strongly recommended that you backup your database at regular intervals and before an upgrade.” Treat that as a prerequisite for repair, not as an optional precaution.
Identify what actually failed
The correct remedy depends on the symptom. A site can display a database-connection error even when every table is healthy, and a single damaged table can make an otherwise valid connection appear unavailable.
Connection or configuration failure
“Error establishing a database connection,” intermittent logins, or a site that cannot authenticate can result from an incorrect value in wp-config.php, an unavailable MySQL or MariaDB server, exhausted CPU, memory or connection limits, a full disk, or a damaged table. Check these items before issuing table-repair statements:
- Compare
DB_NAME,DB_USER,DB_PASSWORD, andDB_HOSTwith the database shown in your hosting panel. Passwords and hostnames are case-sensitive. - Check whether the database service is running and whether the host reports an outage, connection cap, disk-full condition, or recently changed credentials.
- Review the PHP and MySQL/MariaDB error logs for “too many connections,” authentication failures, timeouts, or storage errors.
- Test with a minimal connection tool supplied by the host, or ask support to verify that the WordPress database user still has permission to connect and select the required database.
Do not “repair” tables to fix a wrong password or stopped database service. Correct the connection cause first; otherwise a repair attempt may add confusion without touching the real fault.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsDamaged-table failure
Messages such as “table is marked as crashed,” “record file is crashed,” failed reads from a named table, or MySQL error 145 identify a table-level problem. Note the exact table name, including its prefix. The default prefix is wp_, but a site may use another value in wp-config.php. A table check followed by a repair, logical export/import, or restoration is appropriate here.
Missing-column or schema failure
A missing column immediately after a WordPress or plugin update often means that a migration stopped part-way through, not that the storage engine is physically corrupt. Complete the pending WordPress or plugin database upgrade, follow that plugin’s documented migration path, and inspect its update log before editing rows or dropping a table. Destructive edits can remove data while leaving the incomplete schema unresolved.
Choose the least invasive repair method
Use the option that matches your access and the table engine. MyISAM tables can often be checked and repaired with the tools below. InnoDB recovery is different: a generic “repair table” button may be unavailable or ineffective, so a logical dump/restore or host-level recovery is usually safer.
| Method | Access required | Best use | MyISAM support | InnoDB support | Data and downtime considerations |
|---|---|---|---|---|---|
| WordPress browser repair | Edit wp-config.php and visit an admin URL |
Quick check or repair when shell and database-panel access are unavailable | Useful for supported check/repair operations | May skip or fail to repair affected tables | Easy to run, but the result is not proof that every row is readable; requires a temporary maintenance window |
| phpMyAdmin | Hosting control panel and database-panel login | Targeting one or several named tables and viewing engine/status messages | Repair action is commonly available | Repair action may be absent or ineffective | Selective repair limits exposure; large exports can hit browser timeouts |
| WP-CLI | Shell or approved remote command access | Repeatable checks, exports, repairs, imports, and log capture | Invokes the server’s repair utility | May require logical recovery or host assistance | Fast and scriptable, with clear output; run from the correct WordPress installation and never use reset/drop commands |
| Host or database professional | Provider-level storage and database access | Physical corruption, repeated crashes, failed imports, or inaccessible credentials | Can inspect files and engine diagnostics | Can use engine-specific recovery procedures | May require downtime, a snapshot, or a provider restore; provide all evidence to avoid guesswork |
Method A: use WordPress’s temporary browser repair page
WordPress includes a maintenance repair page intended for short-term recovery. It is useful when you can edit the configuration file but do not have a shell or phpMyAdmin.
- Confirm that the current database export and WordPress file backup are stored safely.
- Open the site’s
wp-config.phpand add this line above the comment that says editing is finished:
define( 'WP_ALLOW_REPAIR', true );- Visit
/wp-admin/maint/repair.phpon the same site. The page offers the available check and repair operation. - Run the operation once, save the complete result, and look for table names reported as skipped, crashed, or still unreadable.
- Remove the
WP_ALLOW_REPAIRdefinition immediately after the attempt, or set it back to disabled. This page is a temporary maintenance tool and should not remain enabled. - Disable maintenance mode and test the previously failing URL only after the repair output is recorded.
A successful page message does not certify that every row, index, or related table is healthy. Skipped tables generally require phpMyAdmin, WP-CLI, engine-level recovery, or restoration from a known-good dump.
Method B: repair selected tables in phpMyAdmin
phpMyAdmin gives you a visual list of tables and their storage engines. Use the database named in wp-config.php; do not guess when the hosting account contains several databases.
Rank #3
- Sign in to the hosting control panel and open phpMyAdmin.
- Select the exact database specified by
DB_NAME(or the value resolved by the host’s configuration). - On the table list, identify the table named in the error. If the report clearly indicates broad damage, select the WordPress tables as a group; otherwise start with only the affected table.
- Inspect the Type or Engine column. MyISAM and InnoDB require different recovery expectations.
- Choose Repair table from the table-actions dropdown for supported tables. Confirm the result shown by phpMyAdmin and save any warnings.
- Re-test the failing URL and inspect the PHP/MySQL error log. Also test an affected administrative screen and a representative post or page; a green interface message alone does not prove that all rows are readable.
If the repair action is unavailable for an InnoDB table, or the action returns an engine error, stop repeating it. Make a logical export if possible and use a new empty database for an import test, or ask the host to perform engine-level recovery. Repeated attempts can make a marginal table harder to export.
Method C: check and repair with WP-CLI
WP-CLI is preferable when shell access is available because it produces command output that can be saved with your incident notes. Run commands from the WordPress installation directory, or specify the installation explicitly.
- Export the current database to a new filename before checking or repairing:
wp db export ../database-before-repair.sql- Check the tables without changing them:
wp db check- If the check identifies repairable tables, run:
wp db repairThe official wp db repair command invokes mysqlcheck --repair=true using credentials loaded from wp-config.php. The broader wp db family also includes dump, export, import, query, and optimize operations.
- Use
--path=/full/path/to/wordpresswhen the current directory is not the site root. - Use
--ssh=...when WP-CLI must execute on the remote host through its supported SSH transport. - Use explicit database options only when the site’s configuration cannot be loaded; keep credentials out of shell history and process listings where possible.
- Capture standard output, standard error, and the database-server log. Never run reset, drop, or destructive query commands while attempting recovery.
If wp db check reports an InnoDB failure, a server-level error, or an unreadable file, stop at the diagnostic output and escalate or move to a logical restore. WP-CLI cannot repair physical storage damage that the database engine itself cannot open.
Validate the result instead of trusting one green message
After a repair, validation should cover both the database and the application:
- Reload the URL that originally failed and confirm that the exact error is gone.
- Open the WordPress dashboard, the Posts and Pages lists, the Media Library, and a representative front-end page.
- Read several recent and older records, including comments if the site uses them. A table may open while a damaged range of rows remains unreadable.
- Check that scheduled tasks, search, forms, and any plugin features that write data still work.
- Review PHP and MySQL/MariaDB logs for new warnings, crashed-table messages, disk errors, or repeated connection failures.
- Take a fresh post-repair export and label it with the date, time, site, and method used. Keep the pre-repair export unchanged.
If the same table crashes again, treat that recurrence as evidence of an underlying disk, engine, resource, or hardware problem rather than running the same repair indefinitely.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →When to restore a known-good SQL backup
Restore when a table remains unreadable after a logical check, when repair skips the affected table, when the database engine reports physical or InnoDB errors, or when the current data is less trustworthy than a verified earlier copy. Prefer a backup from before the first corruption symptom and verify that it belongs to the same site and uses the same table prefix.
Safer restore sequence
- Keep the original database and the current export untouched. Create a new empty database where the host allows it.
- Import the SQL backup into that new database. If phpMyAdmin times out, use the host’s command-line or database-import facility and ask the host to raise execution, upload, or packet limits rather than splitting SQL blindly.
- Point a staging copy of
wp-config.phpto the imported database and test the dashboard, content, media references, logins, scheduled jobs, and critical forms. - When staging is correct, schedule the production switch, put the site in maintenance mode, and change production configuration to the restored database.
- Restore the matching WordPress core files, themes, plugins, uploads, and configuration from the same backup set. A database-only restore cannot recreate those files.
- After the switch, update WordPress and plugins through their normal upgrade paths, rotate database credentials if exposure is suspected, and review administrator accounts and scheduled jobs.
A restore reverts database content to the backup’s point in time. Changes made after that backup—new posts, comments, orders, users, or settings—will not be present unless they can be recovered separately from another export or application log.
Special case: a crashed wp_options table
wp_options is read during most WordPress requests, so damage there can produce a blank page, a connection-style error, failed logins, or a site that loads only intermittently. Confirm the table name and engine in the error rather than assuming every connection failure is an options-table problem.
- Back up the current database and files first, as for any other table.
- Check or repair only
wp_optionsinitially when the error names that table; repairing every table increases the change surface. - After repair, test the dashboard, permalinks, active-theme settings, cron status, and plugins that store configuration in options.
- If the table is InnoDB and cannot be opened, use a logical restore or host-level recovery. Do not create a replacement table by guessing columns or serialized option values.
Know when to stop and escalate
Contact the host or a database professional when any of the following applies:
- Tables remain unreadable after a logical check or repair.
- The server reports disk failure, filesystem errors, corrupt InnoDB pages, or repeated MyISAM crashes.
- Exports fail, imports cannot complete, or the only backup cannot be validated.
- You lack the shell, database-panel, or credential access required to make a safe copy.
- The site continues to corrupt data after a repair, suggesting resource exhaustion, failing storage, or an application writing invalid data.
Give support the exact error text, affected table, timestamps, database engine, backup filename, available disk-space information, and every command or UI operation already attempted. This lets the host work from evidence instead of repeating destructive guesses.
Quick Recap
Prevent the next corruption event
- Automate database exports on a schedule appropriate to the site’s publishing and transaction rate, and store copies off the server.
- Keep at least one immutable copy so a compromised account or a faulty cleanup job cannot delete every backup.
- Test restores on staging. A successful export job is not proof that the dump can be imported.
- Keep a matching file backup of themes, plugins, uploads, and
wp-config.php; database and file recovery are separate operations. - Monitor disk space, database connections, memory, and error logs. Resource exhaustion often appears before corruption is reported.
- Take a fresh backup before WordPress, plugin, or database upgrades, and complete pending migrations before allowing normal traffic.
- Document the database name, table prefix, engine, host contact, and recovery steps in a private runbook so an incident does not begin with guesswork.
A concise repair decision checklist
- Is the exact error captured, and are writes paused?
- Are the current database export and separate WordPress-file backup readable and protected?
- Do credentials, database availability, disk space, and resource limits check out?
- Does the error identify a crashed table, or does it indicate a pending schema migration?
- Which least-invasive tool is available: browser repair, phpMyAdmin, or WP-CLI?
- Is the affected table MyISAM, or does it require InnoDB-aware logical recovery?
- After repair, have both application behavior and server logs been tested?
- If repair failed, has a pre-corruption SQL backup been imported into a new database and tested before production cutover?
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.
