Pre-Filtering by Thread | 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=’ literal ’  and  HOST=’ literal ’ . •Rows with  USER=’ literal ’  and  HOST=’%’ . •Rows with  USER=’%’  and  HOST=’ literal ’ . •Rows with  USER=’%’  and  HOST=’%’ . 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 , the  INSTRUMENTED  value for the thread becomes YES . When the best match is a row with  HISTORY=YES , the  HISTORY  value for the thread becomes YES . •When the best match is a row with  ENABLED=NO , the  INSTRUMENTED  value for the thread becomes  NO . When the best match is a row with  HISTORY=NO , the  HISTORY  value for the thread becomes  NO . •When no match is found, the  INSTRUMENTED  and  HISTORY  values for the thread become  NO . 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. 4914