Revisions and autoloaded wp_options

WordPress post revisions pile up in wp_posts over time, while autoloaded rows in wp_options load on every request. A multi‑megabyte autoload set makes every cache miss slower, even when MySQL itself looks fine. Cap how many revisions you keep, then audit which options still use autoload yes so front‑end work stays light.

Cap revisions in wp-config.php

Open wp-config.php and add a hard limit before the line that says stop editing. A practical setting looks like this:

define('WP_POST_REVISIONS', 10);

New edits will keep only a small set of revisions. Older revision rows stay in the database until you remove them on purpose. Take a JetBackup first, work on staging when you can, and use a query or a plugin you already trust. Avoid random cleaners that also wipe tables such as woocommerce_sessions. Revisions cost disk space and backup time. They are not the same per‑request cost that a large autoload set creates.

Measure wp_options autoload next

In phpMyAdmin or WP-CLI, sum the length of rows in wp_options where autoload is yes. If that total reaches megabytes, list the largest option_name values. Page builders, leftover analytics plugins, and cache plugins that store HTML in options are common sources. Change autoload to no for data that is not needed on every front‑end hit, or delete the option after you remove the plugin that created it. Redis object cache can help until the blob is huge. After that, you still need to fix the option itself, because Redis will cache a multi‑megabyte value and every miss still pays for it once.

Do not lead with a cleanup plugin

Many cleanup tools chase revisions because the table is easy to see. They often leave autoload alone because they do not treat it as the real tax. Use this order instead: cap future revisions, take a backup, delete old revisions only if you must, audit wp_options autoload, then lean on Redis. Doing the reverse leaves you with a smaller wp_posts table and the same slow options load on every request.

After you finish the audit, flush LSCache and Redis so you are not reading old HTML. Check front‑end TTFB on a logged‑out URL. If nothing improved, the blob was not the bottleneck, and you should look at page builder query count next.