In addition to the traditional MySQL configuration options that can be set with SET PERSIST_ONLY or in a configuration file, the Performance Schema also features its own unique dynamic configuration through setup tables. This section explains how the dynamic configuration works.
Table 5-4 lists the setup tables available in MySQL 8. For the tables that allow inserts and deletes, all columns can be changed, but only the non-key columns are listed for settable columns.
Table 5-3. (continued) Table Type Description Connections
and threads
Various tables with information about the connections and threads. This includes the threads, session_account_connect_attrs, session_connect_attrs, accounts, host_cache, hosts, and users tables.
replication Information about the replication configuration and status both for traditional asynchronous replication and Group replication. All the table names except log_
status start with replication_.
Lock This group includes three tables with information about data and metadata locks:
data_locks, data_lock_waits, and metadata_locks.
Variable The variable tables contain information about system and status variables (both for the global and session scopes) and user variables. All the table names include the word variables or status.
Clone Information about the status and progress when using the clone plugin. The tables include clone_progress and clone_status.
miscellaneous The keyring_keys and performance_timers tables.
98
For the tables with a HISTORY column, the history can only be recorded if instrumentation is also enabled. In the same way for the TIMED column, it only is
relevant if the instrument or object is enabled. For setup_instruments, note that not all instruments support being timed in which case the TIMED column is always NULL.
The setup_actors and setup_objects tables are special among the setup tables as you can insert and delete rows for them. This includes using the TRUNCATE TABLE statement to remove all rows. Since the tables are stored in memory, you cannot freely insert as many rows as you want. Instead, the maximum number of rows is defined by the performance_schema_setup_actors_size and performance_schema_setup_
objects_size configuration options. Both options are autosized by default. It requires restarting MySQL for a change to the table sizes to take effect.
Table 5-4. Performance Schema setup tables
Setup Table Key Columns Settable Columns Description setup_
actors
HOST USER ROLE
ENABLED HISTORY
This table is used to determine whether foreground threads are instrumented and has history collected by default based on the account. The ROLE column is currently unused.
You can insert rows into and delete rows from this table.
setup_
consumers
NAME ENABLED This table defines which consumers are enabled.
setup_
instruments
NAME ENABLED
TIMED
This table defines which instruments are enabled and timed.
setup_
objects
OBJECT_TYPE OBJECT_SCHEMA OBJECT_NAME`
ENABLED TIMED
This table defines which schema objects are enabled and timed.
You can insert rows into and delete rows from this table.
setup_
threads
NAME ENABLED
HISTORY
This table defines which thread types are instrumented and have history collected by default.
ChAPTEr 5 ThE PErfOrmAnCE SChEmA
You use regular UPDATE statements to manipulate the configuration. For the setup_
actors and setup_objects tables, you can also use INSERT, DELETE, and TRUNCATE TABLE. An example of enabling the events_statements_history_long consumer is mysql> UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME = 'events_statements_history_long';
Query OK, 1 row affected (0.2674 sec) Rows matched: 1 Changed: 1 Warnings: 0
This configuration is not persistent when restarting MySQL, so if you want to change the configuration of these tables for the cases where there are no configuration options, add the SQL statements required to an init file and execute it through the init_file option.
That concludes the introduction to the Performance Schema, but you will see many examples of using the tables in the remainder of the book.
Summary
This chapter has covered the most important concepts of the Performance Schema.
MySQL is a multi-threaded process, and the Performance Schema includes information for all threads, both foreground threads (connections) and background threads.
The instruments correspond to the instrumented code points in the source code and thus determine which data is collected. When an instrument is enabled, it can optionally also be timed with the exception of memory and error instruments.
The consumers take the data collected by the instruments and process it and make it available through the Performance Schema tables. Twelve of the consumers represent the four event types with three scopes for each type.
The four event types are transactions, statements, stages, and waits which cover different detail levels. The three event scopes are current for the current or last
completed events, history for the ten last events for each thread that still exists, and the last 10,000 events irrespective of the thread generating them. Events can trigger other events, so they form a tree.
100
An important concept is also the digests which allow MySQL to aggregate data grouping by the normalized queries. This is a feature that will prove particularly useful when you will be looking for candidates for query tuning.
At the end, the various types of tables in the Performance Schema were summarized.
The most commonly used group of tables is the summary tables which are essentially reports that make it easy to access aggregate data from the Performance Schema.
Another example of reports based on the Performance Schema – and in several cases of summary tables – is the information made available in the sys schema which is the topic of the next chapter.
ChAPTEr 5 ThE PErfOrmAnCE SChEmA