WordPress Database Optimization: Autoload and Tables

A slow WordPress site can have a database bottleneck as well as PHP or caching issues. Forgotten options, accumulated transients or an oversized table can contribute to higher Time To First Byte (TTFB), increased CPU/IO load and slower admin requests, depending on how the data is used. In this guide, we will investigate the wp_options table, the autoload flag, and oversized tables such as wp_postmeta, logs and statistics. These checks are useful on shared hosting, VPS and dedicated servers. A structured approach can help identify removable bloat and determine whether cleanup improves query times before you consider a hosting upgrade. Let’s walk through what to check, what to clean, and how to keep it healthy in the long term.

How WordPress Uses MySQL (And Why It Gets Bloated)

Every standard WordPress installation uses a set of core tables in a MySQL or MariaDB database. The usual suspects are:

• wp_posts: posts, pages, products, revisions, custom post types
• wp_postmeta: metadata for posts (custom fields, WooCommerce product data, SEO data, etc.)
• wp_options: site-wide settings, plugin options, transients, cache entries
• wp_users and wp_usermeta: user accounts and their metadata
• wp_comments and wp_commentmeta: comments and related data
• Taxonomy-related tables: wp_terms, wp_term_taxonomy, wp_term_relationships

On a fresh site, these tables are generally small, but size alone does not determine query speed. Over time, three patterns are worth investigating:

• Autoload bloat in wp_options: too many or too large options loaded together during WordPress requests.
• Unbounded growth of meta tables: especially wp_postmeta for WooCommerce stores, page builders and custom fields.
• Log/statistic tables created by plugins that never rotate or purge old data.

These issues can develop gradually while queries continue to work. Growing data can increase disk IO, CPU and RAM demand, but cleanup is not automatically the answer: use query measurements to distinguish removable bloat from legitimate workload growth. We have already covered server-side tuning in depth in our guide to server-side optimization for WordPress with PHP-FPM, OPcache, Redis and MySQL. Here we will stay inside the database itself.

Diagnosing WordPress Database Performance Problems

1. Check Overall Database and Table Sizes

First, you need a quick picture of what is actually big. On most hosting panels (cPanel, DirectAdmin, Plesk), you can open phpMyAdmin and see the size of each table in your WordPress database. Sort by “Size” and note the top 3–5 tables.

You can also inspect reported table sizes via SQL. Replace your_database_name with your database name. In the later examples, use your site’s actual table names rather than assuming the wp_ prefix. The size_mb result uses a 1024-squared divisor and is therefore MiB. For InnoDB, the reported data/index allocation is approximate; it is not a measure of disposable data or the free space required for a rebuild.

SELECT 
  TABLE_NAME, 
  ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name'
ORDER BY size_mb DESC;

Illustrative patterns to investigate:

• wp_postmeta larger than wp_posts by a big margin (for example 2 GB vs 300 MB).
• wp_options several hundred MB or more.
• Custom plugin tables like wp_xyz_logs, wp_xyz_stats growing into gigabytes.

A table over a few hundred MB can be a useful starting point for investigation, especially on shared hosting or a small VPS, but size alone does not prove bloat or a performance problem. If your database is huge and MySQL also shows high CPU/IO at peak hours, combine this analysis with the techniques we described in our guide to diagnosing CPU, IO and MySQL bottlenecks when your site is slow only at certain hours.

2. Inspect wp_options and Autoload Size

When WordPress executes, it can load the autoload option collection together. WordPress 6.6 and later use yes, on, auto-on and auto as the default active values; the wp_autoload_values_to_autoload filter can narrow that set. A usable object-cache entry avoids repeating the normal database selection, and a full-page cache can serve a request without executing WordPress. Large option collections can add memory and processing costs, but their size alone does not establish a response-time bottleneck.

The following read-only query estimates the stored bytes for WordPress 6.6+ default active autoload flags. Use your actual table prefix. If a site filters the active set, inspect the result of wp_autoload_values_to_autoload() and adapt the IN list. The 1024-squared divisor gives MiB of stored option values, not PHP memory consumption. Cache entries, filters and the core fallback when the database selection is empty can make the final runtime collection differ from this static measurement:

SELECT 
  COUNT(*) AS autoload_count,
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Autoload size is a diagnostic signal, not a universal pass/fail target. For example, a hypothetical site with 10–50 MB of autoload data might have plugins storing large arrays, cached API responses or statistics there. Inspect the largest options and measure the effect of any changes.

Then list the heaviest options using the same default active set (and any site-specific adjustment above). The 1024 divisor reports KiB of stored values:

SELECT 
  option_name,
  autoload,
  ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY size_kb DESC
LIMIT 50;

As an illustrative review threshold, note individual options larger than 100–200 KiB and patterns such as many _transient_* options or old plugin prefixes. Neither size nor naming alone establishes that an option should be removed.

3. Identify Slow Queries

If you have access to the MySQL slow query log (common on VPS, dedicated or managed database servers), enable it and watch for queries against wp_options and large tables. On shared hosting, or when you prefer a WordPress-level view, plugins like Query Monitor can show which database queries are slow on each request.

Look specifically for:

• SELECT queries on wp_options taking more than 0.1–0.2 seconds.
• SELECT/UPDATE queries on wp_postmeta that scan many rows (high Rows_examined).
• Queries on log/stat tables with no useful indexes.

Database tuning and query analysis go hand in hand with a solid backup strategy. Before you touch any data, review your backup plan. We explained practical options in our WordPress backup strategies guide for shared hosting and VPS and also compared MySQL backup tools like mysqldump, Percona XtraBackup and snapshots for more advanced environments.

4. Always Work on a Staging Copy First

Direct SQL changes are powerful but unforgiving. Especially if you work on a live e‑commerce store or a busy blog, clone your site to staging and test there first. Use a separate database and verify that the clone cannot connect to the production database. Put payments in test mode and prevent real customer emails or production actions in external integrations. A separate hostname and database do not isolate server resources; heavy staging tests on the same server can affect live traffic. If you are on cPanel, you can follow our step-by-step guide for creating a WordPress staging environment on cPanel, then test the cleanup steps there. Before production work, take a fresh, restorable backup and validate both application behavior and the production execution plan. A successful staging deletion does not make an unbounded statement suitable for a large live table; follow the separate large-table safeguards below.

Fixing wp_options and Autoload Bloat

1. Clean Up Expired and Stale Transients

Transients are cache entries accessed through the WordPress Transients API. They can use an external object cache instead of database rows. Without that cache, ordinary transients use the current site’s options table; site transients use options on a single site and network metadata on multisite. A transient may be created with no expiration (the default 0), and entries can disappear before an assigned expiry, so callers need a regeneration path. Expired database rows may remain until accessed or cleaned up; a large count is not proof of a plugin bug. Prefixes such as _transient_ and _site_transient_ alone do not identify disposable data.

Count matching transient-related rows in the selected site’s options table. This includes value and timeout rows, not a count of distinct transients, and excludes external cache entries and multisite network metadata:

SELECT COUNT(*) AS transient_count
FROM wp_options
WHERE option_name LIKE '\_transient\_%' 
   OR option_name LIKE '\_site_transient\_%';

A count in the tens of thousands is a reason to investigate, not proof that all matching rows are disposable. Check their size and whether the cached data is still needed.

For expired-only cleanup, use a supported WordPress cleanup function or WP-CLI command. Do not treat expired-only deletion and a full transient purge as consecutive routine steps. After a restorable backup and staging checks, the following command deletes expired database-backed transients for the selected site. Network/site transients require a separate, intentional --network invocation; on multisite, select each intended site with --url. Externally cached entries are outside this database cleanup:

# From the intended WordPress installation directory
wp transient delete --expired

Without shell access, use a maintenance tool with a documented expired-only scope and test its effect on staging. A blanket DELETE matching the prefixes would remove all matching rows in wp_options, including unexpired entries, rather than checking expiration; it would not cover every transient store. The following read-only query instead helps inspect matching names and stored sizes before choosing a supported cleanup method:

SELECT option_name, LENGTH(option_value) AS stored_bytes
FROM wp_options
WHERE option_name LIKE '\_transient\_%'
   OR option_name LIKE '\_site_transient\_%'
ORDER BY stored_bytes DESC
LIMIT 50;

A deliberate full purge is a different maintenance operation: wp transient delete --all removes database-backed transients in the selected scope, including unexpired values, and can trigger regeneration load. The --network scope is separate; this is not a purge of external object-cache entries. Do not append it to expired-only cleanup or flush a shared cache merely to remove expired values. Confirm the intended scope, backup and staging results first.

2. Reduce Oversized Autoloaded Options

An autoloaded option can hold a large serialized array, such as a page-builder cache, analytics data or an API response. Loading the autoload collection makes the stored value available, but does not mean every serialized value is parsed on every page load. In the normal get_option() return path, WordPress applies maybe_unserialize() to the requested option. Measure collection size, actual option access and request behaviour before deciding whether to remove, restructure or change autoloading for that data.

After you run the earlier query listing the largest autoloaded options, inspect the suspicious ones:

SELECT option_name, autoload
FROM wp_options
WHERE option_name = 'suspect_option_name';

Then check the plugin or theme responsible. Often you can:

• Disable a specific feature or cache layer in the plugin’s settings, if it is not needed.
• Check whether a newer version documents a fix for the identified behavior, then test the update.
• Move that data into non-autoloaded options or a custom table where appropriate (requires development work).

If an option is still needed but should not be autoloaded, change its loading policy through the WordPress API so option-cache state is maintained. The following example requires WordPress 6.4 or later and WP-CLI access to the intended installation. Select the correct site on multisite with --url, replace suspect_option_name with the exact reviewed key, record its original loading policy and take a restorable backup. Test on staging first; deletion of genuinely unused settings is a separate step below:

wp eval 'var_export( wp_set_option_autoload_values( array( "suspect_option_name" => false ) ) );'

Disabling autoload for data that is rarely needed may reduce request overhead; it is not necessarily beneficial for options read on most requests. Confirm the option’s usage and measure the effect on staging. The API changes the autoload flag while keeping the value and maintaining the relevant option cache. Check the returned per-option result, the saved flag and the features that use the option; a false result can mean no change was made, so do not infer success from a finished command alone. Do not use a shared-cache flush as a substitute for a correct option update.

3. Remove Options Left Behind by Uninstalled Plugins

Plugins can leave options and tables behind after uninstalling. Deactivation alone does not establish that their data is unused: it may be needed when the plugin is reactivated. Over time, retained data can accumulate in wp_options and other tables.

To identify candidates, look for prefixes from plugins you no longer use. For example, if you used a plugin old_plugin that stored options like old_plugin_settings, you can list them:

SELECT option_name
FROM wp_options
WHERE option_name LIKE 'old|_plugin%' ESCAPE '|';

Document what you find and verify ownership of every matching option. Confirm that the plugin has been removed and that no active code or planned reactivation needs the data, then either:

• Use a plugin-specific cleanup tool if the developer provides one and its scope fits your plan.
• For a separately verified option, use the WordPress deletion API so its option-cache state and deletion hooks are handled. The example below uses one exact option name, not every name that shares a prefix.

# Replace this example key with one reviewed, unused option.
wp eval 'var_export( delete_option( "old_plugin_settings" ) );'

Do this carefully, one reviewed option at a time, with backups and staging tests. Some plugin prefixes are shared with other tools; the escaped-prefix SELECT above only finds candidates and does not prove that they are unused. Use WP-CLI in the intended installation/site, inspect the result and confirm that dependent features still work. WordPress maintains the relevant option caches for this API deletion; direct SQL would bypass that handling. Do not blindly delete everything that “looks old”.

4. Keep Autoload Size Under Control

After cleanup, repeat the read-only size query using the WordPress 6.6+ default active values. As explained above, adapt the set if the site filters it and use the actual table prefix. The 1024-squared divisor reports MiB of stored option values, not runtime PHP memory or a guarantee of fewer database queries:

SELECT 
  COUNT(*) AS autoload_count,
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Reducing autoloaded data—for example, from a hypothetical 20 MB to 2 MB—may reduce PHP memory use and improve TTFB on requests that load those options. The effect depends on option usage, caching and other bottlenecks; compare equivalent requests before and after cleanup rather than assuming a noticeable speedup.

Dealing With Oversized Tables: wp_postmeta, Revisions and Logs

1. wp_postmeta Bloat

wp_postmeta is a common hotspot, especially for WooCommerce stores, page builders and custom fields. Each product, variation, layout element or SEO field can add several rows of meta data. Over time, this can reach millions of rows.

Execution boundary for this section: the unbounded DELETE demonstrations for orphaned metadata, revisions, comments and logs are only for small, validated staging datasets. Do not run them unchanged on large production tables. A small deletion count alone does not guarantee a short scan or brief locking.

For large production cleanup, obtain the data owner’s approval of retention and deletion criteria, verify a restorable backup, and have a database administrator or developer design and test a keyed, small-batch procedure. Review its access plan and intended keys or key ranges, record affected rows, and measure statement, transaction and lock-wait duration on representative data. Commit between independently validated batches rather than wrapping the entire cleanup in one large transaction. Monitor database load, undo/redo pressure, free space and replication lag where applicable. Set workload-specific stop criteria before starting; pause further batches if blocking, latency, lag or resource use exceeds those limits. Confirm how cancellation and rollback will be handled. There is no universal safe batch size or time threshold. Already committed batches require a restoration or compensating plan; rolling back the current transaction cannot undo earlier commits.

In MySQL, a single-table DELETE can use a row limit, but that does not guarantee elapsed time. The multi-table orphaned-metadata DELETE below does not accept that LIMIT clause; it needs a separately designed key/range strategy, not an appended limit. WordPress-aware cleanup tools also need their batch and transaction behavior checked before large production runs.

First, select the target database and replace your_database_name below with its name. Check the row count and reported table size; an exact count can be costly on a large table:

SELECT COUNT(*) AS row_count
FROM wp_postmeta;

SELECT
  ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name'
  AND TABLE_NAME = 'wp_postmeta';

If you have millions of rows, look for:

• Orphaned postmeta: meta records whose post_id no longer exists in wp_posts.
• Old data from deactivated or removed plugins.
• Debug or log data mistakenly stored in postmeta.

To find orphaned meta rows:

SELECT COUNT(*) AS orphan_count
FROM wp_postmeta m
LEFT JOIN wp_posts p ON m.post_id = p.ID
WHERE p.ID IS NULL;

After verifying that the unmatched metadata is genuinely disposable, use the following unbounded deletion only on a small, validated staging dataset with a restorable backup. It removes every row matching the orphan condition, not a bounded sample, and bypasses WordPress hooks and cache handling. Large production cleanup requires the separately reviewed keyed-batch procedure described above, including a plan for affected cache state and concurrent writes:

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

For WooCommerce-heavy sites, also review plugins that log tracking or analytics into postmeta. Sometimes moving such logs to a dedicated table or external service makes more sense. For deeper MySQL/InnoDB tuning specifically for WooCommerce, we shared a detailed checklist in our WooCommerce MySQL/InnoDB tuning article.

2. Cleaning Up Revisions, Trash and Spam

Post revisions are stored as separate rows in wp_posts. Comments live in wp_comments, and their metadata in wp_commentmeta. Review revision, trash and spam retention against your editing and recovery needs; accumulated records are cleanup candidates only when they are no longer needed.

The following unbounded SQL is only a demonstration for a small, validated staging dataset with a restorable backup. It deletes all revisions, with no age filter. It deletes only rows in wp_posts, so associated postmeta may remain orphaned; repeat the orphan check afterward, but do not automatically run its unbounded deletion. Direct SQL bypasses WordPress application-level cleanup. Prefer a WordPress-aware method for routine maintenance, and use a separately reviewed batch procedure for large production datasets:

DELETE FROM wp_posts
WHERE post_type = 'revision';

To limit future revisions, add this setting to wp-config.php before WordPress is loaded, or adjust the existing definition rather than adding a duplicate. Choose the retention count to suit your editing needs. Changing the file does not immediately purge existing revisions; later revision saves can prune the oldest revisions according to the effective limit and filters. This setting is not an immediate historical cleanup command:

define( 'WP_POST_REVISIONS', 10 ); // or a lower number

The two unbounded statements below are only for a small, validated staging dataset with a restorable backup. The first deletes spam and trashed comments; the second deletes all comment metadata without a matching comment, including older orphans. Validate both scopes separately. Direct SQL bypasses WordPress application-level cleanup, so prefer WordPress’s comment tools for routine deletion. For large production datasets, use the separately reviewed keyed-batch procedure rather than executing these statements unchanged or combining them into one large transaction:

DELETE FROM wp_comments
WHERE comment_approved = 'spam' 
   OR comment_approved = 'trash';

DELETE FROM wp_commentmeta
WHERE comment_id NOT IN (SELECT comment_ID FROM wp_comments);

Review trash retention and confirm that scheduled cleanup runs. Check spam retention separately rather than assuming that trash cleanup covers it.

3. Log and Statistic Tables

Certain plugins create their own tables for logs, analytics or debugging (for example wp_pluginname_logs, wp_pluginname_stats). These can easily reach gigabytes if not rotated.

In phpMyAdmin, look for tables with names ending in _logs, _stats, _sessions or similar. Check their row count and data size. If they belong to a plugin you still use:

• Look for built-in retention settings (e.g. “keep logs for 30 days”) and confirm that the chosen period meets your operational and recordkeeping needs.
• If none are provided, ask the plugin developer about a supported purge method. Schedule custom cleanup only after validating ownership, relationships, deletion criteria and batch behavior; a session-table name alone does not make its contents disposable.

For a hypothetical wp_plugin_logs table, the following unbounded DELETE demonstrates a 90-day cutoff only on a small, validated staging dataset with a restorable backup. Confirm that created_at is a date/time column using the same time basis as NOW(), that the data owner approves the retention period, and that the plugin permits deletion of these records. This is not a production cron recipe: large tables require the separately reviewed keyed-batch procedure and its monitoring and stop criteria:

DELETE FROM wp_plugin_logs
WHERE created_at < NOW() - INTERVAL 90 DAY;

Do not truncate or drop log tables blindly; some plugins expect a certain schema. When in doubt, consult the plugin documentation or developer.

4. Consider OPTIMIZE and ANALYZE After Cleanup

After large deletions, tables can have internal fragmentation. OPTIMIZE TABLE can reorganize storage and may reclaim space, depending on the engine and tablespace layout. ANALYZE TABLE updates optimizer statistics; it does not reclaim space. Neither operation guarantees faster queries, and the two statements below are examples, not a required sequence.

Before any planned rebuild, check disk capacity. Inspect table data and index sizes and actual available space both in the database’s temporary-storage location and on the filesystem holding the table. MySQL 8.0 InnoDB rebuilds can need substantial space for temporary sort files and an intermediate rebuilt table in addition to the existing table. Confirm the requirements for your exact MySQL/MariaDB version, engine and chosen operation; do not rely on a universal free-space multiplier. If capacity or permissions cannot be verified, defer the operation and consult the database administrator or hosting provider.

OPTIMIZE TABLE wp_options, wp_postmeta, wp_posts, wp_comments;
ANALYZE TABLE wp_options, wp_postmeta, wp_posts, wp_comments;

Validate the selected operation on staging, retain restorable backups and plan a low-traffic production window with monitoring. In MySQL 8.0, InnoDB OPTIMIZE TABLE rebuilds the table; online operation can reduce disruption but still has exclusive locking phases, and some configurations or indexes require a table-copy method. Check the exact server version and engine rather than assuming nonblocking behavior. Review existing long-running transactions and lock waits, allow for operational headroom, and define when to defer the work if load or blocking is unacceptable. Check the selected version and engine for ANALYZE TABLE locking too; statistics maintenance is not automatically nonblocking.

Indexes, Storage Engine Choice and Other MySQL-Level Tweaks

1. Ensure InnoDB Is Used for Core Tables

InnoDB provides row-level locking and crash recovery, making it a useful choice for concurrent WordPress workloads. Inspect the storage engines of these core tables before deciding whether conversion is appropriate:

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name'
  AND TABLE_NAME IN ('wp_posts','wp_postmeta','wp_options','wp_comments');

If a table is still MyISAM, consider conversion only after checking compatibility for the exact server version, existing indexes and application behavior. Test the following example on staging first, with a current restorable backup and verified space for temporary/intermediate files. Assess locking and choose a monitored maintenance window separately before production conversion:

ALTER TABLE wp_posts ENGINE=InnoDB;

Review each other table separately rather than converting all tables automatically. For each planned conversion, recheck compatibility, data/index size, temporary and intermediate disk capacity, current backups and the restoration plan.

2. Add or Fix Missing Indexes

WordPress core ships with sensible indexes for its queries, but some plugins create tables with poor indexing or even perform heavy queries on core tables using non-indexed columns.

Typical index improvements include:

• Composite indexes on custom plugin tables for columns frequently used together in WHERE/JOIN clauses.
• Indexes on date columns for log tables to speed up pruning.
• Check that the standard indexes for your installed WordPress version are intact. Treat a composite index on postmeta’s post_id and meta_key columns as a workload-specific candidate, not a required core index; inspect existing indexes and query plans before adding one.

Index design is a deep topic, but even a few targeted indexes on big custom tables can dramatically reduce query time and CPU usage.

3. Tune MySQL for Your Hosting Plan

Database cleanup and MySQL tuning address different parts of the workload. After measuring the effects of cleanup, review these configuration areas where you have administrative access:

• Allocate a more efficient innodb_buffer_pool_size so that hot data fits in RAM.
• MySQL query cache was deprecated in 5.7.20 and removed in 8.0.3. Do not add query-cache settings to current MySQL. For a legacy installation, consult its exact version documentation rather than treating query_cache as a configuration variable. MariaDB has its own version-specific behavior.
• Optimize connection limits and temporary table sizes based on your actual workload.

For a VPS or dedicated server, verify that the plan gives you administrative control over MySQL settings before planning database-side, PHP-FPM and cache tuning. For larger WooCommerce or content-heavy sites, compare resource limits and measured workload performance rather than assuming that a VPS or dedicated server will outperform shared hosting.

Ongoing Maintenance and Hosting-Side Strategy

1. Automate Regular Cleanup

Manual cleanups once every few years are better than nothing, but the best results come from small, regular maintenance tasks:

• Scheduled expired-transient cleanup (via wp-cron or real cron jobs).
• Regular deletion of old logs and statistics beyond your needed retention period.
• Limiting revisions and automatic trash deletion periods.

Many of these can be scheduled with cron, which we covered practically in our article about automating backups, reports and maintenance with cron jobs on cPanel and DirectAdmin. Use those scheduling patterns only for cleanup tasks whose deletion criteria and retention periods you have validated on staging; do not schedule the guide’s SQL statements indiscriminately.

2. Monitor Growth Over Time

Instead of discovering a 5 GB database during a crisis, track table sizes periodically. Simple approaches include:

• A small script or cron job that queries information_schema.TABLES and logs sizes.
• Server monitoring (Prometheus, Grafana, etc.) watching MySQL metrics and disk usage.
• Regular manual checks for smaller projects.

Watch especially for sudden jumps in wp_options, wp_postmeta and any log/stat tables. Compare these jumps with plugin updates, new features and traffic changes before attributing the growth to a particular cause.

3. When Cleanup Is Not Enough: Scaling the Database

A clean, well-indexed database cannot solve every performance problem. If measurements show resource saturation on a high-traffic WooCommerce store or content platform, you may need more CPU, RAM, faster storage (such as NVMe), or dedicated database and cache servers.

Signs to investigate before scaling—these can also reflect query, transaction or connection-management problems:

• Slow queries remain slow even after cleanup and indexing.
• MySQL CPU and IO are saturated during peak hours.
• You frequently hit connection limits or lock contention under load.

Depending on the measured bottleneck, options to evaluate include:

• Moving from shared hosting to a VPS with enough RAM and NVMe storage.
• For very busy stores, separating database and application servers.
• Adding Redis with a WordPress persistent object-cache integration, plus full-page caching where safe.

Use your traffic profile and peak resource measurements to size VPS resources, compare VPS and dedicated servers, and decide whether high-availability database architecture is warranted.

Summary and Practical Next Steps

A database bottleneck is one possible cause of slow WordPress requests, alongside hosting limits, theme or plugin behavior and PHP configuration. Heavy autoloaded options in wp_options can add work to requests that execute WordPress, while large wp_postmeta and log tables can increase query and maintenance costs depending on how they are used. Measure those costs, distinguish removable data from legitimate growth, and validate both the benefit and operational risk of each change.

Your practical action plan looks like this:

• Ensure you have reliable backups and test restores.
• Set up staging and validate changes there; keep the unbounded DELETE demonstrations confined to small, validated staging datasets.
• Measure table sizes, autoload volume and slow queries to identify candidates rather than assuming that the largest table is the bottleneck.
• Review expired transients, confirmed unused plugin options, verified orphaned metadata and logs against ownership and retention requirements.
• For large production cleanup, use a separately reviewed keyed-batch procedure with commits between batches, affected-row and duration checks, resource monitoring and stop criteria.
• Consider OPTIMIZE or ANALYZE only where appropriate; verify temporary and rebuild disk capacity before any rebuild, and assess storage-engine changes separately.
• Automate only validated housekeeping, monitor growth and compare performance before and after changes under similar load.

Database cleanup can complement PHP-FPM tuning, Redis, full-page caching and a CDN, but the benefit depends on the actual bottleneck. Choose a hosting configuration based on measured CPU, memory, storage and administrative-access needs, alongside the database practices outlined here. Compare admin responsiveness, TTFB and overall user experience before and after changes under similar load to determine whether they helped.

Primary Sources

• WordPress: autoload values
• WordPress: autoload API
• WP-CLI: transient deletion
• WordPress: revision retention
• WordPress: comment deletion
• MySQL 8.0: DELETE
• MySQL 8.0: OPTIMIZE TABLE
• MySQL 8.0: ANALYZE TABLE
• MySQL 8.0: online DDL space
• MySQL 8.0: InnoDB conversion