WordPress slow query surge — correlating the spike with the hook that triggered it

1. Problem

At 14:07 your monitoring pings you because MySQL CPU jumped from 12% to 78% in a minute. By 14:09 it is back at 12%. Five minutes later it does it again. The WordPress admin is sluggish, but only on certain page loads. You searched "wordpress database slow random spikes" and "wordpress sudden mysql cpu spike correlate plugin" because the pattern is unmistakable: short bursts of database hell, then quiet, then another burst.

Your slow query log shows hundreds of entries crowded into a 30-second window:

# Query_time: 4.812  Lock_time: 0.001  Rows_sent: 1  Rows_examined: 184312
SELECT post_id FROM wp_postmeta WHERE meta_key = '_visibility' AND meta_value = 'visible';
# Query_time: 4.611  Lock_time: 0.001  Rows_sent: 1  Rows_examined: 184312
SELECT post_id FROM wp_postmeta WHERE meta_key = '_visibility' AND meta_value = 'visible';

The same query, hundreds of times. This surfaces as a wp_db_slow_queries_total rate spike. You can see what is slow, but not who called it. By the time MySQL logged the query, the WordPress hook stack that fired it is gone. A search for the SQL fingerprint matches twelve plugins and your theme.

This guide closes that gap — using wp_db_slow_queries_total as the surge marker and wp_hook_timing_ms from the same time window as the witness that names the responsible hook.

2. Impact

A query storm is not "a slow page." It is a 90-second outage that the hosting dashboard barely catches.

• Connection pool saturation. With max_connections = 150, 200 requests spawning 10 sub-queries each exhaust the pool. The next 50 requests get Error establishing a database connection.
• PHP-FPM worker starvation. A 30-second storm with 4-second queries ties up every FPM worker, queues nginx upstreams, and returns 502s to actual visitors.
• Cascading checkout failures. WooCommerce checkouts during the storm window time out at the payment gateway. The customer sees "payment failed" even though Stripe charged the card.
• Scheduled posts and cron events miss. Cron jobs queued during a storm block behind the slow request. Posts scheduled for 14:08 publish at 14:14.
• You blame the wrong layer. Teams without per-hook attribution upgrade the database, scale horizontally, or panic-install object cache. None fix the unindexed meta_query one plugin is firing on admin_init.

Concrete cost: a single 30-second storm during peak admin traffic on an editorial site is roughly 200 lost editor-actions (drafts that won't save, posts that won't update). On WooCommerce, the same 30 seconds during US lunchtime is double-digit abandoned carts. And it happens every five minutes until you find the hook.

3. Why It’s Hard to Spot

Query storms are the most-misdiagnosed category of WordPress performance failure because every dashboard either misses them or shows them too late.

1. The burst is shorter than the polling interval. CloudWatch metrics on RDS poll at 60-second resolution. A 25-second storm averaged across 60 seconds looks like a small bump. Site monitors hit /health.php once a minute and almost never land inside the storm window.
2. The slow log has everything but the caller. MySQL records the SQL, the duration, the row scan count — and nothing about which PHP request fired it. Every query is from "wordpress" the user, regardless of which plugin or hook constructed it.
3. Multiple plugins share the same SQL shape. Three plugins could each register a callback on pre_get_posts running a meta_query. The slow log shows the SQL but cannot say which callback built it.
4. Anonymous closures hide ownership. A plugin registers add_action('admin_init', function() { ... });. The only artifact is a closure with no name.
5. It looks like "the database is just slow today." Operators see CPU spikes on RDS and scale the instance. The storm continues because the bottleneck is a full table scan, not capacity.
6. Cache warms hide it. A cached page never runs the slow code path during business hours. At night a cron event triggers it on every iteration and floods the slow log when nobody is looking.

Teams treat query storms as a database problem when the database is the witness, not the suspect.

4. Cause

wp_db_slow_queries_total is a counter the Logystera WordPress plugin increments whenever a single SQL query exceeds a configured slow threshold (default: 500ms). Each increment carries labels: query_fingerprint (normalized SQL shape with literals collapsed), table (dominant table touched), and the request URI.

The companion signal wp_hook_timing_ms is a histogram recording, for every WordPress hook fired during the request, the wall-clock time the hook held the call stack. Labels include hook (pre_get_posts, admin_init, wp_loaded, save_post) and where attribution is possible the callback (class::method, function name, or closure file:line).

The cross-signal join is the entire diagnostic. When wp_db_slow_queries_total spikes, the slow query was running inside some hook callback. Take the time window of the spike — say [14:07:12, 14:07:42] — and ask "what hooks were active in that same window with elevated wp_hook_timing_ms?" You collapse the search from "which of 4,000 lines of plugin code" to "this specific hook fired this specific SQL."

Supporting signals add volumetric context. wp_db_query_count is total queries per request — a 60-query baseline jumping to 600 means an N+1 pattern unfolded inside one hook. wp_db_query_time_ms is total DB time per request — when it matches wp_hook_timing_ms for a single hook, that hook is DB-bound, not CPU-bound. That is what makes the join precise.

The detection rule: when rate(wp_db_slow_queries_total[1m]) exceeds 5x its trailing 1-hour baseline AND a specific hook value in wp_hook_timing_ms shows elevated p95 in the same window, the storm has a name.

5. Solution

6. Root causes and fixes — the three patterns

Match the signal pattern to the cause; do not match the SQL to a plugin name.

1. admin_init query storm from a plugin that boots eagerly.

Signal pattern: wp_hook_timing_ms elevated on admin_init with db_time_ms ≈ duration_ms, wp_db_query_count 5–10x baseline, dominant wp_db_slow_queries_total fingerprint touches wp_postmeta or a custom plugin table. Storm fires every time a logged-in admin loads any wp-admin page, so the rate correlates to editorial activity, not site traffic.

Why it happens: a plugin uses admin_init to warm caches, sync remote inventory, rebuild a custom index, or check license validity — on every admin page load instead of once per hour via cron. With 8 editors clicking around, that is 200 invocations an hour.

Fix: move the work to wp-cron (wp_schedule_event(time(), 'hourly', ...)) and gate the boot path with a transient (if (get_transient('plugin_synced_at')) return;).

2. wp_loaded over-query from a REST aggregator.

Signal pattern: wp_hook_timing_ms elevated on wp_loaded for /wp-json/... requests, wp_db_query_count extremely high (300+), wp_db_slow_queries_total fingerprint is a WHERE post_id IN (...) against wp_postmeta repeated per row. A frontend SPA polling every 30 seconds amplifies the storm.

Why it happens: a custom REST endpoint iterates over many posts and runs get_post_meta() per post inside the loop with no update_post_meta_cache() priming. Each row triggers a query.

Fix: prime the cache with update_post_meta_cache($post_ids) before the loop, or rewrite the endpoint to single-query the meta table with WHERE post_id IN (...) and group in PHP.

3. save_post storm from autosave-heavy editors.

Signal pattern: wp_hook_timing_ms elevated on save_post and transition_post_status, wp_db_slow_queries_total storm fires every 60 seconds (Gutenberg autosave cadence), correlates one-to-one with active editor sessions. wp_db_query_time_ms dominated by UPDATE wp_postmeta on a meta key rewritten on every save.

Why it happens: a plugin (SEO, sitemap, related-posts indexer, image-CDN sync) hooks save_post and rebuilds a derived dataset on every save — including autosaves. Every 60 seconds per editor is a query storm.

Fix: short-circuit autosaves: if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return; at the top of the callback. Or queue the rebuild to a deferred job and debounce.

6. How to Catch This Early

Fixing it is straightforward once you know the cause. The hard part is knowing it happened at all. This issue surfaces as wp_db_slow_queries_total.

Everything you just did manually — pin the storm window, find the dominant query fingerprint, list active hooks in the same window, do the cross-signal join, attribute to a callback — Logystera does automatically. The same wp_db_slow_queries_total you just searched for is detected, charted, and aligned against wp_hook_timing_ms in real time.

The dashboard panel for wp_db_slow_queries_total shows the rate over time with the dominant query_fingerprint and the dominant hook from wp_hook_timing_ms overlaid. When the storm lights up at 14:07, the panel shows the spike and shows that admin_init was the hook holding the call stack while it ran. The join is pre-rendered.

!Logystera dashboard — wp_db_slow_queries_total over time wp_db_slow_queries_total 30-second storm at 14:07, overlaid with wp_hook_timing_ms spike on admin_init — the hook that fired it.

The alert names the storm window, the dominant SQL fingerprint, the responsible hook, and the most expensive callback within that hook. You do not get "MySQL CPU high" — you get "slow query storm on admin_init, callback Some_Catalog_Plugin\Boot\register, fingerprint SELECT post_id FROM wp_postmeta WHERE meta_key = ?, started 14:07:12, 184 events in 30s."

!Logystera alert — slow query storm correlated to hook Critical alert fires within 60s of the slow query storm, naming the hook and callback responsible.

The fix is a one-line if (DOING_AUTOSAVE) return;, a missing update_post_meta_cache(), or a transient gate on admin_init. Trivial, once you know. The hard part is collapsing "MySQL CPU spiked" into "this specific hook fired this specific SQL during this specific 30-second window." Logystera turns that from a 45-minute manual cross-grep into a 60-second notification with the join already done.

7. Related Silent Failures

• wp_php_fatal / Allowed memory size exhausted — a storm that returns 400+ rows pushes the request over WP_MEMORY_LIMIT. The fatal is the visible artifact; the storm is the cause. Same chain — pin the window, join wp_hook_timing_ms against wp_php_fatal.
• wp_db_connection_lost / MySQL server has gone away — storm queries exceed wait_timeout and the connection drops mid-checkout. Correlated with the same hook one or two minutes later.
• http.request 504 timeouts during a storm window — PHP-FPM workers stuck in slow queries cause upstream timeouts at nginx. Surfaces as 504s without any PHP error, masking the storm as an infrastructure problem.
• wp.cron / missed_schedule — cron events queued behind a storm-bound request miss their tick. Scheduled posts and email digests fail on storm days even though no individual job failed.
• wp_php_warning_spike — a slow query inside save_post that returns a malformed row triggers downstream Undefined array key warnings on every save. The warning rate is a follow-on signal of the storm.