At a glance
Query Latency p50 (ms) is the median statement execution time on the instance: half of all queries in the window finished faster than this figure, half slower. It is the “typical experience” latency, the number that tells a DBA whether the everyday query path is healthy, in contrast to the tail percentiles that surface the worst cases. A stable, low p50 means the common queries are being served from the buffer pool and indexes are doing their job.
What it tracks
The card reports Query Latency p50 (ms) for the selected period, computed as the median of statement execution times rather than a mean, so a few very slow queries cannot drag the headline up. The figure is read from MariaDB’s statement timing instrumentation (theperformance_schema statement-latency summaries, reported in picoseconds and converted to milliseconds) over the RT/5m window: a live reading backed by a rolling five-minute distribution. Because it is the median, p50 moves only when the bulk of the workload slows down, which usually points to a broad cause such as buffer-pool pressure, a missing index on a hot table, or general resource contention, rather than a single rogue query. The card carries no alert threshold; p50 is read against its own baseline and alongside the tail percentiles (p95 and p99). A p50 that rises while p95 stays flat means the whole workload has shifted slower; a flat p50 with a rising p95 means the typical query is fine but the tail is suffering.
Reconciling against the source
Confirm against MariaDB’s own timing data withSELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY AVG_TIMER_WAIT DESC, which gives per-query timing, or read the latency distribution from sys.statement_analysis. On a managed service, compare against the provider’s query-latency metric on the managed-database console. Small differences are expected from window alignment and the median-versus-mean distinction.