Slow-Query Rate %, MySQL

​

At a glance

Slow-Query Rate % is the share of statements that exceeded long_query_time and were logged as slow, expressed as a percentage of all statements run. It answers “what proportion of my workload is slow?” in a single number. A low percentile-latency reading can still hide a creeping slow-query rate, and vice versa: this card is the volume view of slowness, where the latency percentiles are the severity view. A rising rate is the earliest sign that a missing index, a stale plan, or a saturated buffer pool is starting to bite across real traffic.

​

Calculation

slow_delta      = Slow_queries(now)  - Slow_queries(15m ago)
questions_delta = Questions(now)     - Questions(15m ago)

slow_query_rate_pct = (slow_delta / questions_delta) * 100

1. Deltas, not absolutes. Both counters are cumulative since server start. Reading them once gives the all-time rate, which is meaningless for “right now”. The engine differences two samples so the number reflects the trailing 15 minutes only.
2. The threshold is long_query_time. A statement is “slow” only relative to the server’s long_query_time setting (default 10 seconds, often tuned down to 1 or 2 seconds in production). If long_query_time is set very low, almost everything counts as slow and the rate inflates; if it is high, real problems hide. The rate is only as meaningful as the threshold behind it.
3. Questions vs Queries. The engine uses Questions (client-issued statements) as the denominator, not Queries (which also counts statements executed inside stored programs). This keeps the rate aligned with the workload your application actually sends.

​

Worked example

slow_query_rate_pct = (15,300 / 230,000) * 100 = 6.65%

1. 6.65% means roughly one statement in fifteen is running over a second. That is a lot of long-held connections during the evening peak, exactly when connection pool saturation is already tightest.
2. They open Top 10 Slowest Queries. Two digests dominate the slow log: an order-history lookup joining orders to order_items without a covering index, and a reporting query an internal dashboard runs on a tight loop.
3. They confirm against latency. p95 has risen to 240ms and p99 to 1.4s, so the slow rate is real, not an artefact of a too-low long_query_time. The slowness is genuinely spread across many executions of those two digests.

Connection-pressure framing during the peak:
  - Statements in window: 230,000
  - Slow statements (>1s): 15,300
  - Each slow statement holds its connection ~10x longer than a fast one
  - Effective extra connection-seconds consumed: large enough to push the pool toward 90%

1. Rate and latency answer different questions. Rate is “how much of my traffic is slow”; the percentiles are “how slow is the slow part”. A red rate with healthy percentiles usually means long_query_time is too aggressive; a red rate with a fat tail is a real regression.
2. A high slow rate is a connection-pressure multiplier. Slow statements hold connections, so a rising rate quietly pushes you toward pool exhaustion well before the pool card turns red. Treat the two as linked.
3. Two digests usually explain most of it. Slowness is rarely uniform; a handful of digests dominate the slow log. Top 10 Slowest Queries almost always names the fix.

​

Sibling cards

​

Reconciling against the source

SHOW GLOBAL STATUS for the raw counters this card differences:

SHOW GLOBAL STATUS WHERE Variable_name IN ('Slow_queries', 'Questions');

long_query_time to confirm the threshold the rate is measured against:

SHOW VARIABLES LIKE 'long_query_time';

The slow query log for the actual slow statements (enable with slow_query_log = ON and a sensible long_query_time). pt-query-digest (Percona Toolkit) to aggregate the slow log into ranked digests. Managed-service consoles: Amazon RDS / Aurora Performance Insights and the slow-query-log export to CloudWatch Logs give the same statements; RDS publishes a Questions metric you can cross-check.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre