Statement Sampling FROM performance_schema.setup_instruments WHERE NAME LIKE ’memory/performance_schema/%.tokens’; +----------------------------------------------------------------------+ | NAME | +----------------------------------------------------------------------+ | memory/performance_schema/events_statements_history.tokens | | memory/performance_schema/events_statements_current.tokens | | memory/performance_schema/events_statements_summary_by_digest.tokens | | memory/performance_schema/events_statements_history_long.tokens | +----------------------------------------------------------------------+ Statement Sampling The Performance Schema uses statement sampling to collect representative statements that produce each digest value in the  events_statements_summary_by_digest  table. These columns store sample statement information:  QUERY_SAMPLE_TEXT  (the text of the statement),  QUERY_SAMPLE_SEEN  (when the statement was seen), and  QUERY_SAMPLE_TIMER_WAIT  (the statement wait or execution time). The Performance Schema updates all three columns each time it chooses a sample statement. When a new table row is inserted, the statement that produced the row digest value is stored as the current sample statement associated with the digest. Thereafter, when the server sees other statements with the same digest value, it determines whether to use the new statement to replace the current sample statement (that is, whether to resample). Resampling policy is based on the comparative wait times of the current sample statement and new statement and, optionally, the age of the current sample statement: By default,  performance_schema_max_digest_sample_age  is 60 seconds (1 minute). To change how quickly sample statements “expire”  due to age, increase or decrease the value. To disable the age- based part of the resampling policy, set  performance_schema_max_digest_sample_age  to 0. The name of the  performance_schema  database is lowercase, as are the names of tables within it. Queries should specify the names in lowercase. Many tables in the  performance_schema  database are read only and cannot be modified: Some of the setup tables have columns that can be modified to affect Performance Schema operation; some also permit rows to be inserted or deleted. Truncation is permitted to clear collected events, so TRUNCATE TABLE  can be used on tables containing those kinds of information, such as tables named with a prefix of  events_waits_ . Summary tables can be truncated with  TRUNCATE TABLE . Generally, the effect is to reset the summary columns to 0 or  NULL , not to remove rows. This enables you to clear collected values and restart aggregation. That might be useful, for example, after you have made a runtime configuration change. Exceptions to this truncation behavior are noted in individual summary table sections. Privileges are as for other databases and tables: 4938 mysql>  TRUNCATE TABLE performance_schema.setup_instruments; ERROR 1683 (HY000): Invalid performance_schema usage. 27.11 Performance Schema General Table Characteristics •Resampling based on wait times: If the new statement wait time has a wait time greater than that of the current sample statement, it becomes the current sample statement. •Resampling based on age: If the  performance_schema_max_digest_sample_age  system variable has a value greater than zero and the current sample statement is more than that many seconds old, the current statement is considered “too old”  and the new statement replaces it. This occurs even if the new statement wait time is less than that of the current sample statement.