MySQL :: MySQL 8.4 参考手册 :: 29.4.2 性能模式事件过滤

版本 8.4

8.0 日语

MySQL 8.4 参考手册 / ... / 性能模式事件过滤

29.4.2 性能模式事件过滤

事件以生产者/消费者的方式进行处理。

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

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 表列出了可以向其发送事件信息的 Consumer 类型以及它们是否已启用。

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     |
+----------------------------------+---------+

过滤可以在性能监控的不同阶段完成：

预过滤。 这是通过修改性能模式配置来完成的，以便只从生产者收集某些类型的事件，并且收集的事件只更新某些 Consumer。为此，请启用或禁用 Instrument 或 Consumer。预过滤由性能模式完成，并且具有适用于所有用户的全局效果。
使用预过滤的原因：
- 为了减少开销。即使启用了所有 Instrument，性能模式的开销也应该很小，但您可能希望进一步减少它。或者，您不关心计时事件，并且希望禁用计时代码以消除计时开销。
- 为了避免用您不感兴趣的事件填充当前事件表或历史表。预过滤为已启用的 Instrument 类型的行实例在这些表中留出了更多“空间”。如果仅使用预过滤启用文件 Instrument，则不会为非文件 Instrument 收集任何行。使用后过滤，会收集非文件事件，从而为文件事件留下的行更少。
- 为了避免维护某些类型的事件表。如果禁用 Consumer，服务器就不会花时间维护该 Consumer 的目标。例如，如果您不关心事件历史记录，则可以禁用历史表 Consumer 以提高性能。
后过滤。 这涉及在从性能模式表中选择信息的查询中使用WHERE 子句，以指定要查看哪些可用事件。后过滤是针对每个用户执行的，因为每个用户都会选择哪些可用事件是感兴趣的。
使用后过滤的原因：
- 为了避免为单个用户决定哪些事件信息是感兴趣的。
- 为了在预先不知道使用预过滤施加的限制时使用性能模式调查性能问题。

以下部分提供了有关预过滤的更多详细信息，并提供了在过滤操作中命名 Instrument 或 Consumer 的指南。有关编写查询以检索信息（后过滤）的信息，请参见第 29.5 节，“性能模式查询”。