MySQL :: MySQL 8.4 Reference Manual :: 29.4.2 Performance Schema Event Filtering

version 8.4

8.0 current
5.7

8.0 Japanese

MySQL 8.4 Reference Manual / ... / Performance Schema Event Filtering

29.4.2 性能模式事件过滤

事件在生产者/消费者模式下处理:

已instrument的代码是事件源，并将事件发送到收集。 setup_instruments 表列出了可以收集事件的工具，以及它们是否启用，并且（对于已启用的工具）是否收集时间信息:

mysql> SELECT NAME, ENABLED, TIMED
       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 表提供了事件生产的最基本形式控制。为了进一步根据被监控对象或线程类型来精细化事件生产，可能会使用其他表，如第29.4.3节，“事件预过滤” 中描述的那样。

性能模式表是事件的目的地，消费事件。 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_cpu            | NO      |
| events_statements_current        | YES     |
| events_statements_history        | YES     |
| events_statements_history_long   | NO      |
| events_transactions_current      | YES     |
| events_transactions_history      | YES     |
| 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配置以便只收集特定类型的事件，并且收集到的事件更新特定的消费者。为了这样做，启用或禁用工具或消费者。预过滤由性能模式执行，对所有用户都有全局影响。

使用预过滤的原因:
- 减少开销。即使所有工具都被启用，Performance Schema的开销也应该是最小的，但或许你想要进一步减少它。或者，你不关心时间事件，并且想要禁用时间代码以消除时间开销。
- 避免将无关事件填充到当前事件或历史表中。预过滤留下了更多 “空间” 用于启用的工具类型的行。如果你只启用文件工具进行预过滤，那么不会收集非文件工具的行。使用后过滤时，非文件事件被收集，留下了更少的文件事件行。
- 避免维护某些事件表。如果你禁用一个消费者，服务器就不再花时间维护该消费者的目的地。例如，如果你对事件历史不感兴趣，你可以禁用历史表的消费者以提高性能。
后过滤。 这涉及使用 WHERE 子句在查询中选择Performance Schema表中的信息，以指定你想要看到的可用事件。后过滤是按用户进行的，因为每个用户都可以选择哪些可用事件对他们有兴趣。

使用后过滤的原因:
- 避免为单个用户决定哪些事件信息是感兴趣的。
- 在性能问题调查中使用Performance Schema，当预先知道要施加的限制时，无法提前确定。

以下部分提供了关于预过滤的更多细节，并为过滤操作中的工具或消费者命名提供指导。有关编写查询以检索信息（后过滤）的详细信息，请参阅第29.5节，“性能模式查询”。

PREV HOME UP NEXT