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

版本 9.0

8.4 当前
8.0
5.7

8.0 日语

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

29.4.2 性能模式事件过滤

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

受监控的代码是事件的来源，并生成要收集的事件。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     |
+----------------------------------+---------+

可以在性能监控的不同阶段进行过滤。

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

以下部分将详细介绍预过滤，并提供在过滤操作中命名监测器或消费者的指南。有关编写查询以检索信息（后过滤）的信息，请参见第 29.5 节，“性能模式查询”。