Quick answer: WordPress database table errors — including overhead accumulation, collation mismatches, and table corruption — build up silently and slow your site before causing visible failures. Most site owners only discover them when something breaks.
Almost every other WordPress problem announces itself. A broken plugin throws a white screen. A bad theme update mangles your layout. An expired certificate puts a warning in front of every visitor.
Database problems don’t do that. They accumulate quietly over months, degrading performance a little at a time, until one day a query fails outright and takes a page down with it. By then the underlying issue has usually been there far longer than the symptom.
Here’s what actually goes wrong, why you don’t notice, and what to look for.
Overhead: the space that never gets reclaimed
When you delete a row from a MySQL table, the space it occupied isn’t always returned to the operating system. It’s marked as reusable, but the table file itself stays the same size. MySQL reports this as overhead — allocated space holding nothing useful.
On a WordPress site this adds up faster than people expect, because WordPress deletes a lot of rows in the normal course of business:
- Expired transients being cleared out of
wp_options - Post revisions removed when you clean up drafts
- Spam and trashed comments being purged
- Session and cart data from WooCommerce or membership plugins
- Log entries from security and analytics plugins rotating out
A few megabytes of overhead is normal and not worth worrying about. Hundreds of megabytes on a table that WordPress queries on every page load is a different matter — the database is reading through more file to find the same data.
The fix is straightforward: an OPTIMIZE TABLE operation rebuilds the table and releases the empty space. The hard part isn’t fixing it — it’s knowing it happened.
Collation mismatches: the migration souvenir
Collation is the set of rules your database uses for storing and comparing text — which characters are valid, and how they sort against each other. Modern WordPress installs use utf8mb4_unicode_ci, which handles the full range of Unicode including emoji.
The problem appears when tables in the same database don’t agree. This happens more often than you’d think, usually after:
- Migrating between hosts running different MySQL or MariaDB versions
- Restoring a partial backup taken from an older install
- Installing a plugin that creates its own tables with hardcoded settings
- Importing content from a site that was set up years ago
When MySQL has to compare two columns with different collations — say, joining a plugin’s custom table against wp_posts — it can’t use the index efficiently. It falls back to converting values on the fly, row by row. A query that should take milliseconds starts taking seconds.
What makes this one genuinely sneaky is that nothing errors out. The query returns the right answer. It’s just slow, and it stays slow, and there’s no message anywhere telling you why.
MyISAM tables in an InnoDB world
MySQL supports multiple storage engines. WordPress has used InnoDB by default for years, and for good reason — it supports row-level locking and is crash-resistant in ways its predecessor isn’t.
MyISAM, the older engine, locks the entire table during a write. If a long-running write hits your options or postmeta table, every other query touching that table waits in line. On a quiet site you may never notice. Under traffic, it queues up fast.
MyISAM tables usually turn up on sites that have been migrated forward from a much older install, or from plugins that specified the engine explicitly when creating their tables. Converting to InnoDB is normally uneventful, but check with your host first — and take a backup.
Autoloaded options: the one nobody checks
The wp_options table has a column called autoload. Every row flagged yes gets loaded into memory on every single page request, whether it’s needed or not.
A healthy site might autoload a few hundred kilobytes. But plugins sometimes store large blobs of data there — cached API responses, serialized settings arrays, license payloads — and plugins you’ve deleted often leave their rows behind. It’s not unusual to find sites autoloading several megabytes on every request, most of it belonging to software that isn’t installed anymore.
This shows up as a site that’s uniformly sluggish rather than slow on one particular page — which makes it easy to blame on your host.
Actual corruption
Less common than the above, and more urgent. Tables can be genuinely damaged by an ungraceful server shutdown, a disk problem, or a crash mid-write. Symptoms range from specific posts failing to load, to search returning nothing, to the site going down entirely.
WordPress has a built-in repair tool. Add this to wp-config.php:
define('WP_ALLOW_REPAIR', true);Then visit yoursite.com/wp-admin/maint/repair.php. Important: this page is accessible without logging in, which is why it’s off by default — remove that line as soon as you’re finished.
Why these go unnoticed for so long
Every issue above shares a trait: it degrades rather than breaks. There’s no error message, no failed page, nothing in your inbox. The site gets a bit slower each month, and because you’re watching it change gradually, the new normal never feels alarming.
Meanwhile the checks that would catch all of this take about a second to run. The information is right there in MySQL’s own TABLE STATUS output — table sizes, overhead, collation, storage engine, error states. Nobody looks, because looking means remembering to log in and go check.
What to actually do
- Look at your tables once. phpMyAdmin or Adminer, whatever your host provides. Sort by size, check the collation column, check the engine column. You’ll learn more in five minutes than you expect.
- Check what’s autoloading. Sort
wp_optionsby the length of theoption_valuecolumn and look at the largest rows flagged for autoload. Anything belonging to a plugin you removed can go. - Optimize when overhead is genuinely large. Not weekly out of superstition — when there’s meaningful space to reclaim.
- Fix collation mismatches at the source. If a plugin keeps recreating a table with the wrong collation, converting it once won’t hold.
- Set up something that checks for you. The whole problem is that these are invisible between the moment they start and the moment they hurt.
That last point is why the database health scanner is in Canary Site Monitor’s free tier. It reads table status once a day and flags overhead, collation mismatches, MyISAM tables on core tables, and reported errors — so a problem that would have surfaced in six months surfaces tomorrow instead.
You don’t need to become a database administrator. You just need to find out before your visitors do.