At a glance
Query Latency p50 (ms) is the median statement execution time: half of all queries in the window finish faster than this number, half slower. It is the “typical experience” latency, the steady baseline against which the tail percentiles (p95, p99) are read. A stable, low p50 means the common path is healthy; a rising p50 means the whole workload is slowing down, not just the outliers.
What it tracks
The card reports the median query latency in milliseconds over a real-time, 5-minute view (RT/5m). It is derived from statement timing in MySQL’s Performance Schema, principally events_statements_summary_by_digest, where each digest carries timing buckets that the engine aggregates into a percentile distribution. The p50 is the 50th-percentile point of that distribution across all statements executed in the window.
Read p50 as the baseline of the workload. Because it is the median, it is resistant to a handful of slow outliers: one runaway report does not move it. That is exactly why it pairs with the tail cards. If p50 is flat but Query Latency p95 (ms) and Query Latency p99 (ms) are climbing, the problem is in the tail (lock waits, a few un-indexed paths). If p50 itself rises, the common path has degraded and the cause is usually systemic: buffer-pool pressure, disk saturation, or a sustained throughput surge. This card carries no alert threshold; the tail cards hold the alerting, and p50 supplies the baseline that makes their movement interpretable.
Reconciling against the source
Confirm on the instance withSELECT AVG_TIMER_WAIT/1000000000 AS avg_ms, DIGEST_TEXT FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC; (timer values are in picoseconds, so divide by 1e9 for milliseconds), or use sys.statement_analysis for a friendlier view. On Amazon RDS, Performance Insights surfaces per-digest latency; on Cloud SQL and Azure, read the equivalent Performance Schema views directly.