`wp db check` / `wp db optimize` — the database health commands that get overlooked

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: wp db check and wp db optimize.

Note: WP-CLI's wp db subcommands operate directly on the MySQL (or MariaDB) database WordPress uses, without going through the admin dashboard. Connection details are read automatically from wp-config.php.

wp db check — verifying table health

wp db check

Under the hood, this runs the equivalent of mysqlcheck --check against every table and reports each one's status:

wp_posts                       OK
wp_options                      OK
wp_postmeta                     OK

If a table comes back corrupt, SELECT and INSERT 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 wp db check on a regular schedule catches that kind of issue before it turns into a visible symptom.

wp db optimize — defragmenting tables

wp db optimize

This one runs the equivalent of mysqlcheck --optimize, applying OPTIMIZE TABLE to each table. Tables that see a lot of row deletions and updates tend to become fragmented on disk over time. OPTIMIZE TABLE 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 OPTIMIZE TABLE internally as a table rebuild (roughly equivalent to ALTER TABLE ... FORCE), 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 OPTIMIZE TABLE 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 wp db query "SHOW TABLE STATUS".

wp db optimize 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 wp db check 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 — wp db repair

When wp db check reports a table as corrupt, WP-CLI offers wp db repair (the equivalent of mysqlcheck --repair) 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

Both wp db check and wp db optimize 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 wp search-replace and recovering from a wp-admin lockout. Checking database health is one more basic operation built on that same foundation.