As of MySQL 5.6.3, the Performance Schema maintains tables for collecting current and recent statement events, and aggregates that information in summary tables. Section 22.9.6, “Performance Schema Statement Event Tables” describes the events on which statement summaries are based. See that discussion for information about the content of statement events, the current and recent statement event tables, and how to control statement event collection.
Each statement summary table has one or more grouping columns
to indicate how the table aggregates events. Event names refer
to names of event instruments in the
DIGESTcolumns. Each row summarizes events for given schema/digest values. (The
DIGEST_TEXTcolumn contains the corresponding normalized statement digest text, but is neither a grouping nor summary column.)
This table was added in 5.6.5. Before MySQL 5.6.9, there is no
SCHEMA_NAMEcolumn and grouping is based on
EVENT_NAMEcolumns. Each row summarizes events for a given thread and event name.
EVENT_NAMEcolumn. Each row summarizes events for a given event name.
Each statement summary table has these summary columns containing aggregated values:
These columns are analogous to the columns of the same names in the event wait summary tables (see Section 126.96.36.199, “Event Wait Summary Tables”), except that the statement summary tables aggregate events from
The aggregate of the corresponding
xxxcolumn in the
events_statements_currenttable. For example, the
SUM_ERRORScolumns in statement summary tables are the aggregates of the
table has these additional summary columns:
The times at which a statement with the given digest value were first seen and most recently seen.
Example statement event summary information:
SELECT * FROM events_statements_summary_global_by_event_name\G*************************** 1. row *************************** EVENT_NAME: statement/sql/select COUNT_STAR: 25 SUM_TIMER_WAIT: 1535983999000 MIN_TIMER_WAIT: 209823000 AVG_TIMER_WAIT: 61439359000 MAX_TIMER_WAIT: 1363397650000 SUM_LOCK_TIME: 20186000000 SUM_ERRORS: 0 SUM_WARNINGS: 0 SUM_ROWS_AFFECTED: 0 SUM_ROWS_SENT: 388 SUM_ROWS_EXAMINED: 370 SUM_CREATED_TMP_DISK_TABLES: 0 SUM_CREATED_TMP_TABLES: 0 SUM_SELECT_FULL_JOIN: 0 SUM_SELECT_FULL_RANGE_JOIN: 0 SUM_SELECT_RANGE: 0 SUM_SELECT_RANGE_CHECK: 0 SUM_SELECT_SCAN: 6 SUM_SORT_MERGE_PASSES: 0 SUM_SORT_RANGE: 0 SUM_SORT_ROWS: 0 SUM_SORT_SCAN: 0 SUM_NO_INDEX_USED: 6 SUM_NO_GOOD_INDEX_USED: 0 ...
TRUNCATE TABLE is permitted for
statement summary tables. For
it empties the table. For the other statement summary tables,
it resets the summary columns to zero rather than removing
statement_digest consumer is
enabled, aggregation into
occurs as follows when a statement completes. Aggregation is
based on the
DIGEST value computed for the
events_statements_summary_by_digestrow already exists with the digest value for the statement that just completed, statistics for the statement are aggregated to that row. The
LAST_SEENcolumn is updated to the current time.
If no row has the digest value for the statement that just completed, and the table is not full, a new row is created for the statement. The
LAST_SEENcolumns are initialized with the current time.
If no row has the statement digest value for the statement that just completed, and the table is full, the statistics for the statement that just completed are added to a special “catch-all” row with
NULL, which is created if necessary. If the row is created, the
LAST_SEENcolumns are initialized with the current time. Otherwise, the
LAST_SEENcolumn is updated with the current time.
The row with
NULL is maintained because Performance
Schema tables have a maximum size due to memory constraints.
permits digests that do not match other rows to be counted
even if the summary table is full, using a common
“other” bucket. This row helps you estimate
whether the digest summary is representative:
NULLrow that has a
COUNT_STARvalue that represents 5% of all digests shows that the digest summary table is very representative; the other rows cover 95% of the statements seen.
NULLrow that has a
COUNT_STARvalue that represents 50% of all digests shows that the digest summary table is not very representative; the other rows cover only half the statements seen. Most likely the DBA should increase the maximum table size so that more of the rows counted in the
NULLrow would be counted using more specific rows instead. To do this, set the
performance_schema_digests_sizesystem variable to a larger value at server startup. The default size is 200.