What a crashed WordPress database table means
WordPress stores site settings and other application data in database tables. The table commonly shown as wp_options stores WordPress options, although your site may use a different table prefix and therefore a different name.
A "marked as crashed" message usually comes from the database layer rather than WordPress itself. It has historically been associated with MyISAM tables. Modern WordPress installations commonly use InnoDB, and MySQL's REPAIR TABLE statement does not repair InnoDB tables, so the storage engine matters before you choose a repair method.
Symptoms can include a blank or broken front end, wp-admin failing to load, missing settings, or database errors appearing only on pages that query the damaged table.
Common causes of a table being marked as crashed
Table corruption can follow an interrupted database write, an abrupt server or database shutdown, storage problems, a full disk, or failure in an older MyISAM table. Repeated corruption should be treated as a hosting or database reliability issue, not something to solve indefinitely with repeated repairs.
- An unclean database shutdown. A server crash or forced restart can leave table data or indexes inconsistent.
- Storage or filesystem problems. Disk errors and lack of free space can interfere with database writes.
- A legacy MyISAM table fails. MyISAM has repair tools that differ from InnoDB recovery.
- A failed migration or restore leaves inconsistent data. The database may need to be restored from a known-good backup rather than repaired in place.
If several tables show errors at once, or corruption returns soon after a repair, check the database service and underlying hosting environment before making more WordPress changes.
How to repair a crashed WordPress table safely
Before editing wp-config.php, running a repair or changing the database, take a full backup of both files and database. If a normal database export fails, preserve the latest known-good backup and ask the host what snapshot or database-level recovery options are available.
- Confirm the exact table and storage engine. In phpMyAdmin or your database administration tool, check whether the affected table is MyISAM or InnoDB and confirm the site's actual table prefix.
- Try WordPress's built-in repair mode. Add the following line to wp-config.php, above the line that tells you to stop editing:
define( 'WP_ALLOW_REPAIR', true );Then open /wp-admin/maint/repair.php and run the repair. Remove the WP_ALLOW_REPAIR line as soon as you finish. WordPress deliberately allows that repair page to work without login while the setting is enabled, so it should not be left active.
- If WordPress cannot repair a MyISAM table, use the database tool carefully. MySQL supports REPAIR TABLE for MyISAM, ARCHIVE and CSV tables. In phpMyAdmin, select only the affected supported table and use its repair operation, or let an experienced administrator run the equivalent SQL.
- Do not run REPAIR TABLE as an InnoDB fix. If the affected table is InnoDB, or if the repair reports lost rows or repeated corruption, stop and use the host's database recovery process or restore a known-good backup.
After recovery, check the site front end and wp-admin, save a fresh backup, and investigate why the table became corrupted.
When to stop repairing and restore or get help
Stop if the repair reports that rows changed unexpectedly, several tables are damaged, the database repeatedly crashes, or you cannot confirm the storage engine. The wp_options table can contain settings that affect the whole site, so an apparently successful repair that discards rows may still leave WordPress misconfigured.
Do not delete wp-config.php, replace WordPress core files or empty the damaged table. If the database is business-critical, a controlled restore from a known-good backup may be safer than repeated repair attempts.
Our Emergency Fix is £249 per incident with a response within 2 working hours. Care plans start from £59 a month for ongoing maintenance and support.