25.4.2 性能架构事件过滤

事件以生产者/Consumer 方式处理:

  • 工具代码是事件的来源,并产生要收集的事件。 setup_instrumentstable 列出了可为其收集事件的工具,是否已启用事件以及(对于已启用的工具)是否收集计时信息:
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_instrumentstable 提供了对事件产生的最基本控制形式。为了根据正在监视的对象或线程的类型进一步完善事件的产生,可以使用其他 table,如第 25.4.3 节“事件预过滤”中所述。

  • 性能架构 table 是事件和消费事件的目标。 setup_consumerstable 列出了可以向其发送事件信息的使用者类型以及是否启用了这些信息:
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     |
+----------------------------------+---------+

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

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

使用预过滤的原因:

  • 减少开销。即使启用了所有工具,性能架构开销也应该最小,但是也许您想进一步降低它。或者您不关心定时事件,而是想禁用定时代码以消除定时开销。

    • 为了避免用您不感兴趣的事件来填充当前事件或历史记录 table。对于已启用的仪器类型的行实例,预过滤为这些 table 留出更多“空间”。如果仅启用具有预过滤功能的文件工具,则不会为非文件工具收集任何行。使用后过滤,将收集非文件事件,从而为文件事件保留更少的行。

    • 为了避免维护某些事件 table。如果禁用使用者,则服务器不会花费时间维护该使用者的目的地。例如,如果您不关心事件历史记录,则可以禁用历史记录 table 使用者以提高性能。

  • 后期过滤. 这涉及在查询中使用WHERE子句,这些子句从 Performance Schematable 中选择信息,以指定要查看的可用事件。后过滤是基于每个用户执行的,因为单个用户会选择感兴趣的可用事件。

使用后过滤的原因:

  • 为了避免针对单个用户做出有关哪些事件信息的决策。

    • 当预先不知道使用预过滤施加的限制时,要使用性能架构来调查性能问题。

以下各节提供有关预过滤的更多详细信息,并提供在过滤操作中命名工具或使用者的准则。有关编写查询以检索信息(后过滤)的信息,请参见第 25.5 节“性能模式查询”