When a WordPress page loads slowly, most people start with caching plugins, image compression, or CDN setup. These are all worthwhile. But there is a category of performance problem they do not fully solve: slow database queries.
Every WordPress page load triggers multiple queries to your MySQL database - fetching posts, widgets, options, plugin settings, and more. On a well-optimized site, all of these complete in milliseconds. On a site with the wrong plugins, unindexed queries, or years of accumulated data, individual queries can take hundreds of milliseconds, adding up to a Time to First Byte (TTFB) of two seconds or more even before the browser has downloaded a single image.
Identifying Slow Queries with Query Monitor
Query Monitor is a free WordPress plugin that logs every database query executed during a page load and highlights the slow ones. It is the essential diagnostic tool for this type of performance investigation.
Install and activate it, then load a page on your site. A new admin bar item appears showing the total number of queries and total query time. Click it to open the Query Monitor panel.
Under the Database Queries tab, you can see every query, how long it took, and which plugin or theme triggered it. Query Monitor flags slow queries - typically anything over 0.05 seconds - in orange or red. Sort by duration to see the worst offenders immediately.
The Duplicate Queries section is equally important. If the same query runs 40 times on a single page load, that is an N+1 query pattern in a plugin, and it is costing you in aggregate even if each individual query is fast.
Common Culprits
Unindexed queries: WordPress's core tables are well-indexed, but plugins that add their own tables sometimes do it poorly. A query scanning an entire table without an index gets slower as the table grows. This shows up in Query Monitor as a slow query with high "Rows Examined" relative to "Rows Returned." Fixing this requires adding a database index - something your developer or hosting support can help with.
N+1 query patterns: This is when a loop in a plugin executes one query per item in a list instead of fetching all items in one query. A plugin that runs a separate database query for each product, each comment, or each post meta field multiplies your query count. The fix is in the plugin's code - either update to a newer version, switch plugins, or (if you are a developer) refactor the query.
Large wp_options with uncached autoloaded data: WordPress loads certain options on every page request - this is the autoload mechanism. When plugins abuse it, you end up with megabytes of data being loaded from the database on every single page, even when most of it is never used. Run this query in phpMyAdmin or using WP-CLI to see your autoloaded data:
SELECT option_name, length(option_value) AS option_value_length
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_value_length DESC
LIMIT 20;
If any row is over 100KB, investigate. Deactivating and deleting the responsible plugin is the cleanest fix; otherwise, you can disable autoload on specific options using a plugin like WP Optimize or Advanced Database Cleaner.
When to Add a Redis Object Cache
WordPress generates the same database queries repeatedly across page loads. An object cache stores query results in memory so that repeated queries are served from RAM instead of MySQL.
Redis is the most capable object cache for WordPress. Once Redis is available on your server (contact your host to check - many plans include it), install the Redis Object Cache plugin, configure it to connect, and enable the object cache. Subsequent queries that were previously hitting MySQL are now served from Redis in microseconds.
Redis is particularly effective for high-traffic sites, WooCommerce stores (which generate heavy database activity), and sites with slow wp_options autoload. For lower-traffic sites, a transients-based object cache (built into WordPress) is often sufficient.
The right sequence is: identify slow queries with Query Monitor first, fix the obvious problems (bad plugins, autoload bloat), then add Redis if you need the additional performance headroom. Do not add Redis to avoid investigating - use it after you understand what is slow and why.
