WordPress can load normally while one plugin screen, search, comments or scheduled task fails because only its table is damaged. MySQL errors such as “table is marked as crashed” are stronger evidence than a generic plugin error.
Do not run repair against every table immediately. Preserve a backup and identify the exact table, engine and failure.
Capture the database error
Match the failed feature’s timestamp with PHP and MySQL logs. Record database/table name, error code and query fingerprint without query values.
Useful evidence:
table name and prefix
storage engine
CHECK TABLE result
last known working time
disk/server events
feature/plugin ownerRedact customer and content values.
Back up before repair
Create a database dump if MySQL can still read the table and preserve the hosting snapshot where available. A logical dump may skip the damaged table, so read its output and error log.
Do not overwrite the last pre-corruption backup with a new incomplete one. Record backup time and restore instructions.
If disk is full, use external storage or free space safely before generating large temporary files.
Identify storage engine
MyISAM supports repair operations that do not apply to InnoDB. InnoDB corruption can require server-level recovery and restore rather than a simple REPAIR TABLE.
Use read-only inspection:
SHOW TABLE STATUS LIKE 'wp_example';
CHECK TABLE wp_example;Replace the prefix/table explicitly. Run through an authorised account and do not issue engine-inappropriate repair commands.
Determine business importance
Map the table to WordPress core or the plugin that created it. Confirm whether it stores reconstructable cache/log data or authoritative content, orders, submissions or settings.
Never drop a table because its plugin can “recreate” schema until you know whether the rows are replaceable.
Check vendor documentation for supported repair and migration tools.
Repair MyISAM cautiously
For a confirmed crashed MyISAM table, use cPanel/Plesk/phpMyAdmin or the host’s supported repair action after backup. Keep the site read-only or in maintenance if writes could continue.
Monitor output and compare row counts afterward. A successful engine message does not prove every logical record is intact.
Do not run concurrent optimisation, import or backup during repair.
Handle InnoDB through the host
Review MySQL error logs for page/checksum, tablespace and crash-recovery messages. Contact the managed host or database administrator with exact evidence.
Emergency innodb_force_recovery modes are for extracting data and can prohibit writes; they require server-level expertise and a restoration plan.
Avoid copying individual InnoDB table files between servers without matching metadata and procedures.
Find the original cause
Table damage can follow disk full, forced shutdown, storage faults or server crash. Repairing rows without resolving infrastructure invites recurrence.
Check disk/inodes, filesystem and MySQL shutdown history. Update the responsible plugin if it issued invalid schema operations.
Schedule table maintenance outside traffic and prevent overlapping backups/imports.
Validate logical consistency
Engine repair can make pages readable while leaving missing relationships. For a core table, compare related posts, metadata, terms or comments; for a plugin table, use its integrity or reconciliation tool.
Check recent IDs and timestamps against a backup and application logs. Do not invent missing foreign references or renumber rows. When records are unrecoverable, document the bounded loss and restore only the affected data through a tested, application-aware process.
Verify the feature and data
Test reads and writes for the exact feature, plus WordPress login, editor and scheduled tasks. Compare row counts and recent records with backups or external evidence.
Monitor MySQL errors through several write cycles. Recurring care should verify disk and backups; a repaired table is trustworthy only when the application works and the storage condition that damaged it is understood.