A WordPress database doesn't tidy itself up over time.
Spam comments pile up, expired transients linger, post revisions accumulate, and tables left behind by uninstalled plugins never quite go away.
All of that adds up to bloated tables, and occasionally to actual table corruption.
This is territory the admin dashboard barely shows you — but WP-CLI reaches it directly with two short commands: and .
Note: WP-CLI's subcommands operate directly on the MySQL (or MariaDB) database WordPress uses, without going through the admin dashboard.
Connection details are read automatically from . — verifying table health Under the hood, this runs the equivalent of against every table and reports each one's status: If a table comes back , and queries against it start failing.
That can surface as something oddly specific — a single page going blank, one particular post refusing to save — with no obvious connection to a database problem.
Running on a regular schedule catches that kind of issue before it turns into a visible symptom. — defragmenting tables This one runs the equivalent of , applying to each table.
Tables that see a lot of row deletions and updates tend to become fragmented on disk over time. rebuilds the table and reclaims the space that deleted rows used to occupy.
Note: behavior differs by storage engine.
WordPress's default engine, InnoDB, handles internally as a table rebuild (roughly equivalent to ), which both defragments the table and refreshes its statistics.
The older MyISAM engine doesn't reclaim space from deleted rows automatically at all — that disk space only gets released once runs.
Some installs set up through a hosting provider's one-click installer still carry MyISAM tables left over from an older default, so it's worth checking for a mixed-engine setup once with . locks each table for writes while it runs.
On a large table that can mean a brief slowdown for site visitors, so it's safer to run during a low-traffic window rather than in the middle of the day.
When to actually run these Neither command causes harm if run at an arbitrary time, but a few moments make the payoff clearer: Right after a bulk deletion — clearing out spam comments in bulk, deleting a large batch of posts, or uninstalling a plugin that no longer gets used, all shrink row counts suddenly Before a major update — running ahead of a large WordPress core or plugin update makes it easier to tell, after the fact, whether a problem was caused by the update or was already sitting in the database beforehand As part of routine maintenance — folding these into a weekly or monthly cycle turns fragmentation and corruption from "discovered too late" into something checked on a predictable schedule If corruption turns up — When reports a table as , WP-CLI offers (the equivalent of ) as a next step.
Repair isn't guaranteed to restore the data perfectly — depending on how severe the corruption is, some data can still be lost.
Taking a fresh backup before attempting a repair is a prerequisite, not an optional step.
A backup taken moments before the corruption is worth far more than one taken after the fact.
Summary What you want to do Command Check every table's health Defragment tables and reclaim disk space Attempt to repair a corrupted table (back up first) Check for mixed storage engines Both and are lightweight — they finish in seconds to a few minutes — yet they leave a record of the state of the one part of a WordPress site that's hardest to see from the dashboard.
That's exactly why it's worth checking mechanically and on a schedule, rather than relying on symptoms to surface first.
WP-CLI's ability to reach the database directly, without going through the admin dashboard, is the same idea behind safely rewriting serialized data with and recovering from a wp-admin lockout.
Checking database health is one more basic operation built on that same foundation.