At a glance
The ten query patterns consuming the most total time on your MySQL instance over the last 24 hours, ranked by aggregate latency. Each row is a normalised statement digest (literals stripped, so SELECT ... WHERE id = ? collapses thousands of individual executions into one pattern) with its call count, total time, and average time per call. This is the single most useful starting point for a DBA asking “where is my database spending its time?”
What it tracks
The card reads from the Performance Schemaevents_statements_summary_by_digest table (or the sys.statement_analysis view that wraps it), which aggregates every statement MySQL has executed since the last digest reset, grouped by normalised digest. Rows are ranked by SUM_TIMER_WAIT (total accumulated execution time) and the top ten are surfaced, broken down by row with the digest text, execution count, total latency, average latency, and rows examined per call.
Total time matters more than average time: a query averaging 8 ms but called 2 million times a day costs far more wall-clock than a 4-second report run twice. Sorting by total time exposes the queries that, if optimised, would free the most capacity. A digest with a high rows-examined-to-rows-sent ratio is the classic signature of a missing or unused index. The 24h window means the list reflects a full daily traffic cycle rather than a momentary snapshot.
Reconciling against the source
Reconcile against MySQL directly withSELECT * FROM sys.statement_analysis ORDER BY total_latency DESC LIMIT 10;, or query performance_schema.events_statements_summary_by_digest ordered by SUM_TIMER_WAIT DESC. On managed services use Performance Insights (RDS / Aurora) or Query Insights (Cloud SQL), which present the same digest-level ranking. Note that digest counters reset on instance restart or an explicit TRUNCATE performance_schema.events_statements_summary_by_digest, so a freshly restarted instance shows a shorter history than the 24h window implies.