Query Latency p95 (ms), MySQL

​

At a glance

Query Latency p95 (ms) is the 95th-percentile statement execution time: 95% of queries in the window finish faster than this number, the slowest 5% take longer. It is the metric that best tracks real user pain, because the median (p50) hides the tail and the maximum is too noisy to act on. When p95 climbs, the slow 5% is getting slower, and at storefront volumes that 5% is thousands of shoppers hitting a sluggish page load, a laggy search, or a checkout that stalls. This is a Hero sensitivity card with a 200ms alert: for an OLTP primary, a p95 above 200ms means the tail of the workload has crossed from “fast enough” into “noticeably slow”.

​

Calculation

Query Latency p95 = value below which 95% of statement execution times fall, over the 5m window

• It is execution time, not round-trip time. Performance Schema times the statement inside the server, from parse to result generation. Network transit between the application and the database is not included, so a client-observed latency may be higher than the card by the network round-trip cost.
• It is a percentile, not an average. This is the whole point of p95. An average is dragged around by both extremes; the 95th percentile isolates the tail experience while staying stable against a single freak query. It is the standard “how bad is it for the unlucky few?” measure.

​

Worked example

SELECT DIGEST_TEXT,
       COUNT_STAR,
       AVG_TIMER_WAIT/1000000000 AS avg_ms,
       SUM_ROWS_EXAMINED/COUNT_STAR AS avg_rows_examined
FROM performance_schema.events_statements_summary_by_digest
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 5;

DIGEST_TEXT                                  avg_ms  avg_rows_examined
SELECT * FROM orders WHERE customer_email=?  310     842,000   <- full scan
SELECT * FROM products WHERE title LIKE ?    140     410,000   <- LIKE scan
...

1. Add the missing index. ALTER TABLE orders ADD INDEX idx_customer_email (customer_email); turns an 842,000-row scan into an index seek. On a large table, build it during a low-traffic window or use an online DDL path to avoid blocking.
2. Confirm it is a tail problem, not a systemic one. Because p50 stayed flat, the buffer pool and disk are healthy; this is a small number of expensive queries, not a server-wide slowdown. Cross-check InnoDB Buffer Pool Hit Rate %; if it were dropping, the story would be different.
3. Watch p99 as the leading edge. p99 spiked to 690ms before p95 crossed the line. The deepest tail moves first; p99 is the early-warning version of this card.

Why p95, not average:
  - Average latency this window: ~22ms (looks fine)
  - p95: 260ms (the slow 5% is genuinely slow)
  - At 9,000 statements/sec, 5% = 450 statements/sec running slow
  - The average hides them; p95 exposes them.

1. The p50-to-p95 gap is the diagnosis. A small gap means uniform performance; a widening gap (flat p50, rising p95) means a tail problem, typically a few un-indexed or contended queries.
2. p95 is the user-pain metric. Averages flatter the operator and hide the unlucky shoppers. The 95th percentile is what a meaningful slice of real sessions actually experiences.
3. The tail moves before the median. Watch p99 and p95 together; the deepest percentile crosses first and gives you a head start before the broader slowdown arrives.

​

Sibling cards

​

Reconciling against the source

SELECT * FROM performance_schema.events_statements_histogram_global; for the global latency histogram the percentile is read from. SELECT DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT/1000000000 AS avg_ms, MAX_TIMER_WAIT/1000000000 AS max_ms FROM performance_schema.events_statements_summary_by_digest ORDER BY AVG_TIMER_WAIT DESC; to find the digests driving the tail. SELECT * FROM sys.statement_analysis ORDER BY avg_latency DESC; for the sys-schema friendly view with latency already formatted. The slow query log (when slow_query_log is on) for the actual slow statements, captured with their full parameters.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre