Documentation Home
MySQL 9.4 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 41.2Mb
PDF (A4) - 41.3Mb
Man Pages (TGZ) - 262.8Kb
Man Pages (Zip) - 368.8Kb
Info (Gzip) - 4.1Mb
Info (Zip) - 4.1Mb


29.12.20.3 Statement Summary Tables

The Performance Schema maintains tables for collecting current and recent statement events, and aggregates that information in summary tables.Section 29.12.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 historical statement event tables, and how to control statement event collection, which is partially disabled by default.

Example statement event summary information:

mysql> SELECT *       FROM performance_schema.events_statements_summary_global_by_event_name\G*************************** 1. row ***************************                 EVENT_NAME: statement/sql/select                 COUNT_STAR: 54             SUM_TIMER_WAIT: 38860400000             MIN_TIMER_WAIT: 52400000             AVG_TIMER_WAIT: 719600000             MAX_TIMER_WAIT: 12631800000              SUM_LOCK_TIME: 88000000                 SUM_ERRORS: 0               SUM_WARNINGS: 0          SUM_ROWS_AFFECTED: 0              SUM_ROWS_SENT: 60          SUM_ROWS_EXAMINED: 120SUM_CREATED_TMP_DISK_TABLES: 0     SUM_CREATED_TMP_TABLES: 21       SUM_SELECT_FULL_JOIN: 16 SUM_SELECT_FULL_RANGE_JOIN: 0           SUM_SELECT_RANGE: 0     SUM_SELECT_RANGE_CHECK: 0            SUM_SELECT_SCAN: 41      SUM_SORT_MERGE_PASSES: 0             SUM_SORT_RANGE: 0              SUM_SORT_ROWS: 0              SUM_SORT_SCAN: 0          SUM_NO_INDEX_USED: 22     SUM_NO_GOOD_INDEX_USED: 0               SUM_CPU_TIME: 0      MAX_CONTROLLED_MEMORY: 2028360           MAX_TOTAL_MEMORY: 2853429            COUNT_SECONDARY: 0...

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 thesetup_instruments table:

Each statement summary table has these summary columns containing aggregated values (with exceptions as noted):

  • COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT

    These columns are analogous to the columns of the same names in the wait event summary tables (seeSection 29.12.20.1, “Wait Event Summary Tables”), except that the statement summary tables aggregate events fromevents_statements_current rather thanevents_waits_current.

    Theprepared_statements_instances table does not have these columns.

  • SUM_xxx

    The aggregate of the correspondingxxx column in theevents_statements_current table. For example, theSUM_LOCK_TIME andSUM_ERRORS columns in statement summary tables are the aggregates of theLOCK_TIME andERRORS columns inevents_statements_current table.

  • MAX_CONTROLLED_MEMORY

    Reports the maximum amount of controlled memory used by a statement during execution.

  • MAX_TOTAL_MEMORY

    Reports the maximum amount of memory used by a statement during execution.

  • COUNT_SECONDARY

    The number of times a query was processed on theSECONDARY engine. For use with MySQL HeatWave Service and MySQL HeatWave, where thePRIMARY engine isInnoDB and theSECONDARY engine is MySQL HeatWave (RAPID). For MySQL Community Edition Server, MySQL Enterprise Edition Server (on-premise), and MySQL HeatWave Service without MySQL HeatWave, queries are always processed on thePRIMARY engine, which means the value is always 0 on these MySQL Servers.

Theevents_statements_summary_by_digest table has these additional summary columns:

  • FIRST_SEEN,LAST_SEEN

    Timestamps indicating when statements with the given digest value were first seen and most recently seen.

  • QUANTILE_95: The 95th percentile of the statement latency, in picoseconds. This percentile is a high estimate, computed from the histogram data collected. In other words, for a given digest, 95% of the statements measured have a latency lower thanQUANTILE_95.

    For access to the histogram data, use the tables described inSection 29.12.20.4, “Statement Histogram Summary Tables”.

  • QUANTILE_99: Similar toQUANTILE_95, but for the 99th percentile.

  • QUANTILE_999: Similar toQUANTILE_95, but for the 99.9th percentile.

Theevents_statements_summary_by_digest table contains the following columns. These are neither grouping nor summary columns; they support statement sampling:

  • QUERY_SAMPLE_TEXT

    A sample SQL statement that produces the digest value in the row. This column enables applications to access, for a given digest value, a statement actually seen by the server that produces that digest. One use for this might be to runEXPLAIN on the statement to examine the execution plan for a representative statement associated with a frequently occurring digest.

    When theQUERY_SAMPLE_TEXT column is assigned a value, theQUERY_SAMPLE_SEEN andQUERY_SAMPLE_TIMER_WAIT columns are assigned values as well.

    The maximum space available for statement display is 1024 bytes by default. To change this value, set theperformance_schema_max_sql_text_length system variable at server startup. (Changing this value affects columns in other Performance Schema tables as well. SeeSection 29.10, “Performance Schema Statement Digests and Sampling”.)

    For information about statement sampling, seeSection 29.10, “Performance Schema Statement Digests and Sampling”.

  • QUERY_SAMPLE_SEEN

    A timestamp indicating when the statement in theQUERY_SAMPLE_TEXT column was seen.

  • QUERY_SAMPLE_TIMER_WAIT

    The wait time for the sample statement in theQUERY_SAMPLE_TEXT column.

Theevents_statements_summary_by_program table has these additional summary columns:

  • COUNT_STATEMENTS,SUM_STATEMENTS_WAIT,MIN_STATEMENTS_WAIT,AVG_STATEMENTS_WAIT,MAX_STATEMENTS_WAIT

    Statistics about nested statements invoked during stored program execution.

Theprepared_statements_instances table has these additional summary columns:

  • COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE

    Aggregated statistics for executions of the prepared statement.

The statement summary tables have these indexes:

TRUNCATE TABLE is permitted for statement summary tables. It has these effects:

  • Forevents_statements_summary_by_digest, it removes the rows.

  • For other summary tables not aggregated by account, host, or user, truncation resets the summary columns to zero rather than removing rows.

  • For other summary tables aggregated by account, host, or user, truncation removes rows for accounts, hosts, or users with no connections, and resets the summary columns to zero for the remaining rows.

In addition, each statement summary table that is aggregated by account, host, user, or thread is implicitly truncated by truncation of the connection table on which it depends, or truncation ofevents_statements_summary_global_by_event_name. For details, seeSection 29.12.8, “Performance Schema Connection Tables”.

In addition, truncatingevents_statements_summary_by_digest implicitly truncatesevents_statements_histogram_by_digest, and truncatingevents_statements_summary_global_by_event_name implicitly truncatesevents_statements_histogram_global.

Statement Digest Aggregation Rules

If thestatements_digest consumer is enabled, aggregation intoevents_statements_summary_by_digest occurs as follows when a statement completes. Aggregation is based on theDIGEST value computed for the statement.

  • If aevents_statements_summary_by_digest row already exists with the digest value for the statement that just completed, statistics for the statement are aggregated to that row. TheLAST_SEEN column 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. TheFIRST_SEEN andLAST_SEEN columns 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 specialcatch-all row withDIGEST =NULL, which is created if necessary. If the row is created, theFIRST_SEEN andLAST_SEEN columns are initialized with the current time. Otherwise, theLAST_SEEN column is updated with the current time.

The row withDIGEST =NULL is maintained because Performance Schema tables have a maximum size due to memory constraints. TheDIGEST =NULL row permits digests that do not match other rows to be counted even if the summary table is full, using a commonother bucket. This row helps you estimate whether the digest summary is representative:

  • ADIGEST =NULL row that has aCOUNT_STAR value that represents 5% of all digests shows that the digest summary table is very representative; the other rows cover 95% of the statements seen.

  • ADIGEST =NULL row that has aCOUNT_STAR value 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 theDIGEST =NULL row would be counted using more specific rows instead. By default, the table is autosized, but if this size is too small, set theperformance_schema_digests_size system variable to a larger value at server startup.

Stored Program Instrumentation Behavior

For stored program types for which instrumentation is enabled in thesetup_objects table,events_statements_summary_by_program maintains statistics for stored programs as follows:

  • A row is added for an object when it is first used in the server.

  • The row for an object is removed when the object is dropped.

  • Statistics are aggregated in the row for an object as it executes.

See alsoSection 29.4.3, “Event Pre-Filtering”.