WordPress Database Performance: A Practical Guide

A slow WordPress database rarely announces itself. The site works, it is just heavy, and every page takes a little longer than it should. Then traffic doubles and it stops working entirely.

Advertisement. We earn a commission if you sign up through this link, at no extra cost to you.

There are four things that actually make a WordPress database slow, and they are not the ones the cleanup plugins advertise most loudly.

Autoloaded options: the one that matters most

Start here, because it is the most common serious problem and almost nobody checks it.

The wp_options table has an autoload column. Everything marked yes is loaded into memory on every single request, before WordPress knows what page it is building. Not queried when needed — loaded, always, on the front page and on an image request alike.

Core uses this for a small amount of essential configuration. Plugins use it for whatever they like, and plugins that have been deleted often leave their options behind, still marked autoload, still loaded on every request forever.

Healthy is under about 800 KB. A megabyte is worth attention. Sites with 5 MB of autoloaded options exist, and they are paying that cost on every request of every day.

Check it:

SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options WHERE autoload = 'yes';

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 25;

The second query names your problem. Typically it is one or two enormous rows — a cached API response, a log, a settings blob from a plugin uninstalled two years ago.

WordPress 6.6 added automatic management that stops very large options from being autoloaded, which helps new problems but does not retroactively fix an old install. Query Monitor and the Advanced Database Cleaner plugin both surface this without SQL if you would rather not touch the database directly.

The fix is to set the offender to autoload = no, or delete it if its plugin is gone. Back up first, and be sure of what you are deleting — an option belonging to an active plugin will be regenerated, one belonging to a deleted plugin will not.

Post revisions

WordPress saves a full copy of a post every time you save. By default the number is unlimited, so a heavily edited page can carry fifty copies of itself, each with its own metadata rows.

This bloats wp_posts and wp_postmeta, though it is worth being accurate about the impact: revisions are excluded from front-end queries, so they slow down the admin and the backup more than they slow down visitors. It is a real problem, just not the emergency it is often presented as.

Cap it in wp-config.php:

define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 120);

Five is a sensible number: enough to recover from a mistake, not enough to accumulate. Setting it to false disables revisions entirely, which saves a little more and removes your undo history — a poor trade on a site anyone edits.

Transients

Transients are cached values with an expiry, stored in wp_options. The subtlety: expiry means WordPress will not use a stale transient, not that the row disappears. Without a persistent object cache, expired transients accumulate as dead rows in the same table your autoloaded options live in.

Deleting expired ones is safe — anything still needed gets regenerated. Every cleanup plugin offers this.

The better fix, if you have logged-in traffic or a shop, is a persistent object cache — Redis or Memcached. Transients then live in memory instead of the database, which both removes the accumulation and makes them dramatically faster to read. Most managed WordPress hosts offer this as a toggle.

The postmeta table

On most mature sites wp_postmeta is the largest table, and on WooCommerce sites it can be enormous.

Two things go wrong. Orphaned rows: metadata belonging to posts that were deleted, which nothing cleans up automatically. And queries on meta_value: WordPress indexes meta_key, but not the value. Any query filtering by meta value scans, and on a large table that scan is the slowest thing on the page.

Clear the orphans:

DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

The meta_value problem is architectural rather than a cleanup job. If a plugin is querying by meta value on every page load, the answers are a targeted index on that specific key, a taxonomy instead of a meta field, or a different plugin. Query Monitor will tell you which query it is; that is the starting point.

The rest of the housekeeping

Smaller items, worth doing once and then scheduling:

Spam and trashed comments. Empty both. On a site with an open comment form these can be the majority of wp_comments.
Trashed posts. WordPress empties the trash after 30 days by default; anything older is already gone.
Orphaned term relationships left behind by deleted taxonomies.
Table engine. Everything should be InnoDB. MyISAM tables on an old install use table-level locking, which under concurrency is a real bottleneck. SHOW TABLE STATUS tells you.
Optimize tables to reclaim space after large deletions. Useful once after a cleanup, pointless as a weekly ritual.

WP-Optimize and Advanced Database Cleaner do all of this through an interface, with scheduling. Both are safe if you back up first, and “back up first” is not a formality here — a database cleanup that goes wrong goes wrong completely.

What cleaning will not fix

Worth saying, because database optimization gets sold as a cure for slowness in general.

If a page runs 400 queries, a smaller database makes it run 400 queries slightly faster. The problem is the query count, and that comes from a plugin or a theme doing something inefficient in a loop. Find it with Query Monitor and fix the cause.

If TTFB is slow because PHP workers are saturated, the database is not your constraint at all.

And a monthly cleanup schedule on a site that is not accumulating anything is maintenance theater. Do it once properly, cap revisions, add an object cache, and check back in six months.

The short version

Measure autoloaded options first — it is the most common serious problem and the one nobody looks at. Cap revisions at five. Add a persistent object cache if you have logged-in traffic, which fixes transients as a side effect. Clear orphaned postmeta once. Make sure everything is InnoDB. And when a page is slow, count its queries before you blame the database’s size.

Working through this list on your own site and would rather not? That is what an Expert Web Audit is for.