插桩代码是事件的来源并生成要收集的事件。该 setup_instruments表列出了可以为其收集事件的仪器，它们是否已启用，以及（对于已启用的仪器）是否收集计时信息：

mysql> SELECT * FROM performance_schema.setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME                                              | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock        | YES     | YES   |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES     | YES   |
| wait/synch/mutex/sql/LOCK_lock_db                 | YES     | YES   |
| wait/synch/mutex/sql/LOCK_manager                 | YES     | YES   |
...

该setup_instruments表提供了对事件生成的最基本控制形式。为了根据正在监视的对象或线程的类型进一步细化事件生成，可以使用其他表，如 第 25.4.3 节，“事件预过滤”中所述。

Performance Schema 表是事件和消费事件的目的地。该 setup_consumers表列出了事件信息可以发送到的消费者类型以及它们是否已启用：

mysql> SELECT * FROM performance_schema.setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| events_stages_current            | NO      |
| events_stages_history            | NO      |
| events_stages_history_long       | NO      |
| events_statements_current        | YES     |
| events_statements_history        | YES     |
| events_statements_history_long   | NO      |
| events_transactions_current      | NO      |
| events_transactions_history      | NO      |
| events_transactions_history_long | NO      |
| events_waits_current             | NO      |
| events_waits_history             | NO      |
| events_waits_history_long        | NO      |
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| statements_digest                | YES     |
+----------------------------------+---------+

预过滤。  这是通过修改 Performance Schema 配置来完成的，以便仅从生产者收集某些类型的事件，并且收集的事件仅更新某些消费者。为此，启用或禁用仪器或消费者。预过滤由性能模式完成，具有适用于所有用户的全局效果。

使用预过滤的原因：

过滤后。  这涉及在WHERE从性能模式表中选择信息的查询中使用子句，以指定您想要查看哪些可用事件。后过滤是在每个用户的基础上执行的，因为各个用户选择感兴趣的可用事件。

使用后置过滤的原因：