What matters first: WordPress reached the database, but one table cannot be read normally. Repair steps differ for MyISAM and InnoDB, and a visible repair can fail if disk or hardware pressure remains.
What this symptom actually tells you
This is not the same as invalid database credentials. The table name, engine, server log and disk state determine whether a table-level repair is appropriate or a restore is safer.
Capture evidence before changing anything
- Record the exact table and SQL error.
- Create a database dump or storage snapshot before repair attempts.
- Check the table engine, free disk space and database error log.
- Determine whether other tables or databases show corruption.
Most common causes
- Unclean shutdown: A crash or forced restart left a non-transactional table inconsistent.
- Disk or filesystem problem: Full disk, I/O errors or failing storage interrupted writes.
- MyISAM index damage: Legacy tables can often be checked and repaired at table level.
- InnoDB corruption: Transactional table damage may require recovery mode or restore, not REPAIR TABLE.
Safe diagnostic and repair sequence
- Stabilize disk space and the database service before modifying the table.
- Use CHECK TABLE to confirm scope and engine-specific guidance.
- Repair only supported engines, or restore the affected table from a verified backup.
- Run application-level checks after recovery because structural success does not prove data completeness.
How to choose between the likely causes
Do not treat Unclean shutdown and Disk or filesystem problem as interchangeable. A crash or forced restart left a non-transactional table inconsistent. By contrast, full disk, I/O errors or failing storage interrupted writes. Use two checks to separate them: Record the exact table and SQL error; and create a database dump or storage snapshot before repair attempts. Those observations usually show whether the next safe move is to stabilize disk space and the database service before modifying the table or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not enable aggressive InnoDB force-recovery values and continue normal writes. Recovery mode is for extracting data under controlled conditions.
How to verify the repair
- The affected table passes structural checks.
- WordPress reads and writes the related feature correctly.
- Database and system logs show no continuing I/O or corruption errors.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
This is not the same as invalid database credentials. The table name, engine, server log and disk state determine whether a table-level repair is appropriate or a restore is safer.
- Record the exact table and SQL error.
- Create a database dump or storage snapshot before repair attempts.
- Check the table engine, free disk space and database error log.
- Determine whether other tables or databases show corruption.
What must be verified
- The affected table passes structural checks.
- WordPress reads and writes the related feature correctly.
- Database and system logs show no continuing I/O or corruption errors.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is a crashed table the same problem as wrong database credentials?+
No. A crashed table means WordPress successfully reached the database but one specific table cannot be read normally, which is a distinct issue from a credentials or connection failure. The repair path depends on the table name, storage engine, and disk state, not on authentication.
Does the repair process differ between MyISAM and InnoDB tables?+
Yes. MyISAM tables can often be checked and repaired at the table level directly. InnoDB corruption is different — it may require recovery mode or a restore from backup rather than a simple REPAIR TABLE command, since the transactional engine handles damage differently.
Is it safe to leave InnoDB force-recovery settings on after extracting the data?+
No. Aggressive InnoDB force-recovery values are meant for extracting data under controlled conditions, not for continuing normal write operations. Leaving them enabled during regular use risks further problems rather than resolving the underlying issue.
If the repair command reports success, does that mean the data is fully intact?+
Not necessarily. Structural success from a repair command does not prove data completeness — run application-level checks afterward to confirm the affected feature actually reads and writes correctly, since some rows or records could still be missing or altered.