29.4.6 按线程预过滤
The threads
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:
-
The
thread_instrumentation
consumer in thesetup_consumers
table must beYES
. -
The
threads.INSTRUMENTED
column must beYES
. -
Monitoring occurs only for those thread events produced from instruments that are enabled in the
setup_instruments
table.
The threads
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_history
events_waits_history_long
events_stages_history
events_stages_history_long
events_statements_history
events_statements_history_long
events_transactions_history
events_transactions_history_long
For historical event logging to occur, these things must be true:
-
The appropriate history-related consumers in the
setup_consumers
table must be enabled. For example, wait event logging in theevents_waits_history
andevents_waits_history_long
tables requires the correspondingevents_waits_history
andevents_waits_history_long
consumers to beYES
. -
The
threads.HISTORY
column must beYES
. -
Logging occurs only for those thread events produced from instruments that are enabled in the
setup_instruments
table.
For foreground threads (resulting from client connections), the initial values of the INSTRUMENTED
and HISTORY
columns in threads
table rows are determined by whether the user account associated with a thread matches any row in the setup_actors
table. The values come from the ENABLED
and HISTORY
columns of the matching setup_actors
table row.
For background threads, there is no associated user. INSTRUMENTED
and HISTORY
are YES
by default and setup_actors
is not consulted.
The initial setup_actors
contents look like this:
mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| % | % | % | YES | YES |
+------+------+------+---------+---------+
The HOST
and USER
columns should contain a literal host or user name, or '%'
to match any name.
The ENABLED
and HISTORY
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 in setup_actors
, it tries to find more specific matches first, using the USER
and HOST
columns (ROLE
is unused):
-
Rows with
USER='
andliteral
'HOST='
.literal
' -
Rows with
USER='
andliteral
'HOST='%'
. -
Rows with
USER='%'
andHOST='
.literal
' -
Rows with
USER='%'
andHOST='%'
.
The order in which matching occurs matters because different matching setup_actors
rows can have different USER
and HOST
values. This enables instrumenting and historical event logging to be applied selectively per host, user, or account (user and host combination), based on the ENABLED
and HISTORY
column values:
-
When the best match is a row with
ENABLED=YES
, theINSTRUMENTED
value for the thread becomesYES
. When the best match is a row withHISTORY=YES
, theHISTORY
value for the thread becomesYES
. -
When the best match is a row with
ENABLED=NO
, theINSTRUMENTED
value for the thread becomesNO
. When the best match is a row withHISTORY=NO
, theHISTORY
value for the thread becomesNO
. -
When no match is found, the
INSTRUMENTED
andHISTORY
values for the thread becomeNO
.
The ENABLED
and HISTORY
columns in setup_actors
rows can be set to YES
or NO
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 the setup_actors
table initially contains a row with '%'
for both HOST
and USER
. 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 specific HOST
/USER
combinations.
Suppose that you modify setup_actors
as follows:
UPDATE performance_schema.setup_actors
SET 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');
The UPDATE
statement changes the default match to disable instrumentation and historical event collection. The INSERT
statements add rows for more specific matches.
Now the Performance Schema determines how to set the INSTRUMENTED
and HISTORY
values for new connection threads as follows:
-
If
joe
connects from the local host, the connection matches the first inserted row. TheINSTRUMENTED
andHISTORY
values for the thread becomeYES
. -
If
joe
connects fromhosta.example.com
, the connection matches the second inserted row. TheINSTRUMENTED
value for the thread becomesYES
and theHISTORY
value becomesNO
. -
If
joe
connects from any other host, there is no match. TheINSTRUMENTED
andHISTORY
values for the thread becomeNO
. -
If
sam
connects from any host, the connection matches the third inserted row. TheINSTRUMENTED
value for the thread becomesNO
and theHISTORY
value becomesYES
. -
For any other connection, the row with
HOST
andUSER
set to'%'
matches. This row now hasENABLED
andHISTORY
set toNO
, so theINSTRUMENTED
andHISTORY
values for the thread becomeNO
.
Modifications to the setup_actors
table affect only foreground threads created subsequent to the modification, not existing threads. To affect existing threads, modify the INSTRUMENTED
and HISTORY
columns of threads
table rows.