Profile slow WordPress database queries

When a WordPress page feels unresponsive and the server CPU is high, the bottleneck is often a handful of database queries, not the PHP code itself. A single missing index on a large table can turn a 5 millisecond lookup into a 500 millisecond scan. Profiling the queries tells you which plugin and which posts or options table access is responsible, so you fix the right thing instead of guessing.

Spot the symptom

Slow-query symptoms overlap with general slowness: pages take seconds in the admin, the dashboard spinner never clears, or a front-end list view crawls. Because WordPress fires hundreds of queries per page render, the problem may be many store-bought queries rather than one obvious monster. Correlate the slowness with a location: a product archive, the admin screen, or after a specific plugin update.

Find the query

The fastest path is a Query Monitor style plugin. It hooks into wpdb and lists every query for the page you are viewing, with the call stack that fired it, how many times it ran, and how long it took. The useful signals are:

• Slow single query. Sort by time. Look for SELECT statements without a useful index, or a query run thousands of times on one render (the "duplicate" count column).
• Wrong table. Abnormally heavy scans usually land on wp_options, wp_postmeta, or wp_posts. A transient that is never deleted grows wp_options; metadata stored for lazy loading can bloat wp_postmeta.
• N+1 pattern. A loop that queries once per item shows up as the same query repeated with different ID values.

For a server-level view you do not need a plugin. Enable the MySQL slow query log and set a threshold such as 2 seconds:

slow_query_log = ON
long_query_time = 2
slow_query_log_file = /var/log/mysql/mysql-slow.log

Then inspect entries and match their SQL to a theme template or plugin file. A query in the log that reads wp_posts on every request is often fixable with a plugin hook, not a server change.

Fix and prevent

The durable fixes are: add the index a slow WHERE needs (check wp_options and wp_postmeta lookup columns), load object caching so repeated reads hit Redis or Memcached instead of MySQL, and reduce the number of queries a page fires by enabling partial or full-page caching. Review what each plugin adds on load and drop ones whose queries you can prove are wasteful. After changes, re-run Query Monitor on the same page and compare total query count and time before and after.

Set a routine: profile a handful of representative pages after a theme or plugin update, and keep the slow query log threshold low enough to catch regressions. Right-sized indexes and an object cache prevent the most common database-driven slowdowns from reaching your users at all.

When to involve a professional

High wp_options bloat, multi-second scans on wp_postmeta, and queries from a commercial plugin you cannot modify are all cases where a performance-aware developer can restructure the data or replace the eager-loading logic. Editing core or a paid plugin directly is rarely wise, so get help for those instead of shipping a fragile patch.

Related references

The classic package for WP-CLI users is to export and inspect queries and objects from the command line. If diagnostics point to repeated lookups, the object cache guide covers offloading reads to a fast cache tier.