Performance Schema setup tables contain information about monitoring configuration:
mysql>SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLESWHERE TABLE_SCHEMA = 'performance_schema'AND TABLE_NAME LIKE 'setup%';+-------------------+ | TABLE_NAME | +-------------------+ | setup_consumers | | setup_instruments | | setup_timers | +-------------------+
You can examine the contents of these tables to obtain information
about Performance Schema monitoring characteristics. If you have
the UPDATE privilege, you can
change Performance Schema operation by modifying setup tables to
affect how monitoring occurs. For additional details about these
tables, see Section 22.8.2, “Performance Schema Setup Tables”.
To see which event timer is selected, query the
setup_timers tables:
mysql> SELECT * FROM setup_timers;
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE |
+------+------------+
The NAME value indicates the type of instrument
to which the timer applies, and TIMER_NAME
indicates which timer applies to those instruments. The timer
applies to instruments where their name begins with a component
matching the NAME value. There are only
“wait” instruments, so this table has only one row
and the timer applies to all instruments.
To change the timer, update the NAME value. For
example, to use the NANOSECOND timer:
mysql>UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND'WHERE NAME = 'wait';mysql>SELECT * FROM setup_timers;+------+------------+ | NAME | TIMER_NAME | +------+------------+ | wait | NANOSECOND | +------+------------+
For discussion of timers, see Section 22.3.1, “Performance Schema Event Timing”.
The setup_instruments and
setup_consumers tables list the
instruments for which events can be collected and the types of
consumers for which event information actually is collected,
respectively. Section 22.3.2, “Performance Schema Event Filtering”,
discusses how you can modify these tables to affect event
collection.
If there are Performance Schema configuration changes that must be
made at runtime using SQL statements and you would like these
changes to take effect each time the server starts, put the
statements in a file and start the server with the
--init-file=
option. This strategy can also be useful if you have multiple
monitoring configurations, each tailored to produce a different
kind of monitoring, such as casual server health monitoring,
incident investigation, application behavior troubleshooting, and
so forth. Put the statements for each monitoring configuration
into their own file and specify the appropriate file as the
file_name--init-file argument when you start
the server.