How to Optimize WordPress Database Queries for Large Sites

When a WordPress site grows past a few thousand posts, you start noticing something: pages that loaded in 200ms now take 2-3 seconds. The culprit is almost always the database. WordPress meta tables, taxonomy queries, and WP_Query can become serious bottlenecks at scale.

Find the Slow Queries First

Before optimizing anything, you need to know what is actually slow. I use the Query Monitor plugin during development, but for production, enable the MySQL slow query log:

# In my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

This logs any query taking longer than 1 second. After a day of traffic, you will have a clear picture of your worst queries.

The Meta Query Problem

The biggest performance killer I see in WordPress is unindexed meta queries. The wp_postmeta table has a composite index on (post_id, meta_key), but if you are querying by meta_value, there is no index to help:

// This is slow on large sites
$query = new WP_Query([
    "meta_key"   => "price",
    "meta_value" => 100,
    "meta_compare" => "<=",
    "meta_type"  => "NUMERIC",
]);

The fix is to add a custom index:

ALTER TABLE wp_postmeta ADD INDEX meta_value_index (meta_value(191));

Use Taxonomy Queries Instead of Meta

Whenever possible, I convert meta queries to taxonomy queries. Taxonomies use lookup tables with proper indexes, making them significantly faster for filtering. Instead of storing a “color” meta value, create a “color” taxonomy. The query performance difference on a 50,000-post site can be 10x or more.

Object Caching Is Non-Negotiable

For any site with more than a few hundred posts, persistent object caching with Redis or Memcached is essential. WordPress makes hundreds of database queries per page load by default. Object caching stores the results in memory, so repeated queries never hit the database:

# Install Redis object cache
wp plugin install redis-cache --activate
wp redis enable

On one client site, enabling Redis dropped the average page load from 1.8 seconds to 0.4 seconds — without changing a single line of application code.