Movatterモバイル変換

Thethreads table contains a row for each server thread. Each row contains information about a thread and indicates whether monitoring is enabled for it. For the Performance Schema to monitor a thread, these things must be true:

Thethreads table also indicates for each server thread whether to perform historical event logging. This includes wait, stage, statement, and transaction events and affects logging to these tables:

events_waits_historyevents_waits_history_longevents_stages_historyevents_stages_history_longevents_statements_historyevents_statements_history_longevents_transactions_historyevents_transactions_history_long

For historical event logging to occur, these things must be true:

For foreground threads (resulting from client connections), the initial values of theINSTRUMENTED andHISTORY columns inthreads table rows are determined by whether the user account associated with a thread matches any row in thesetup_actors table. The values come from theENABLED andHISTORY columns of the matchingsetup_actors table row.

For background threads, there is no associated user.INSTRUMENTED andHISTORY areYES by default andsetup_actors is not consulted.

The initialsetup_actors contents look like this:

mysql> SELECT * FROM performance_schema.setup_actors;+------+------+------+---------+---------+| HOST | USER | ROLE | ENABLED | HISTORY |+------+------+------+---------+---------+| %    | %    | %    | YES     | YES     |+------+------+------+---------+---------+

TheHOST andUSER columns should contain a literal host or user name, or'%' to match any name.

TheENABLED andHISTORY columns indicate whether to enable instrumentation and historical event logging for matching threads, subject to the other conditions described previously.

When the Performance Schema checks for a match for each new foreground thread insetup_actors, it tries to find more specific matches first, using theUSER andHOST columns (ROLE is unused):

The order in which matching occurs matters because different matchingsetup_actors rows can have differentUSER andHOST values. This enables instrumenting and historical event logging to be applied selectively per host, user, or account (user and host combination), based on theENABLED andHISTORY column values:

TheENABLED andHISTORY columns insetup_actors rows can be set toYES orNO independent of one another. This means you can enable instrumentation separately from whether you collect historical events.

By default, monitoring and historical event collection are enabled for all new foreground threads because thesetup_actors table initially contains a row with'%' for bothHOST andUSER. To perform more limited matching such as to enable monitoring only for some foreground threads, you must change this row because it matches any connection, and add rows for more specificHOST/USER combinations.

Suppose that you modifysetup_actors as follows:

UPDATE performance_schema.setup_actorsSET ENABLED = 'NO', HISTORY = 'NO'WHERE HOST = '%' AND USER = '%';INSERT INTO performance_schema.setup_actors(HOST,USER,ROLE,ENABLED,HISTORY)VALUES('localhost','joe','%','YES','YES');INSERT INTO performance_schema.setup_actors(HOST,USER,ROLE,ENABLED,HISTORY)VALUES('hosta.example.com','joe','%','YES','NO');INSERT INTO performance_schema.setup_actors(HOST,USER,ROLE,ENABLED,HISTORY)VALUES('%','sam','%','NO','YES');

TheUPDATE statement changes the default match to disable instrumentation and historical event collection. TheINSERT statements add rows for more specific matches.

Now the Performance Schema determines how to set theINSTRUMENTED andHISTORY values for new connection threads as follows:

Modifications to thesetup_actors table affect only foreground threads created subsequent to the modification, not existing threads. To affect existing threads, modify theINSTRUMENTED andHISTORY columns ofthreads table rows.