MySQL 8.4 Release Notes
事件以生产者/消费者方式处理：Events are processed in a producer/consumer fashion:
插装代码是事件的来源，并生成要收集的事件。
setup_instruments表列出了可以收集事件的仪器，它们是否已启用，以及（对于已启用的仪器）是否收集时间信息：Instrumented code is the source for events and produces events to be collected. Thesetup_instrumentstable lists the instruments for which events can be collected, whether they are enabled, and (for enabled instruments) whether to collect timing information:mysql>
SELECT NAME, ENABLED, TIMEDFROM 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 节，“事件预过滤”中所述。Thesetup_instrumentstable provides the most basic form of control over event production. To further refine event production based on the type of object or thread being monitored, other tables may be used as described in Section 29.4.3, “Event Pre-Filtering”.Performance Schema 表是事件的目标和事件的使用者。
setup_consumers表列出了可以接收事件信息的消费者类型，以及它们是否启用：Performance Schema tables are the destinations for events and consume events. Thesetup_consumerstable lists the types of consumers to which event information can be sent and whether they are enabled: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 | +----------------------------------+---------+
在性能监控的不同阶段可以进行过滤：Filtering can be done at different stages of performance monitoring:
预过滤。 这是通过修改 Performance Schema 配置来完成的，以便仅从生产者收集某些类型的事件，并且所收集的事件仅更新特定的消费者。为此，可以启用或禁用仪器或消费者。预过滤由 Performance Schema 执行，并具有适用于所有用户的全局效果。Pre-filtering. This is done by modifying Performance Schema configuration so that only certain types of events are collected from producers, and collected events update only certain consumers. To do this, enable or disable instruments or consumers. Pre-filtering is done by the Performance Schema and has a global effect that applies to all users.
使用预过滤的原因：Reasons to use pre-filtering:
为了减少开销。即使启用了所有仪器，性能模式的开销也应最小，但也许您想进一步减少开销。或者您不关心时间事件，并且希望禁用计时代码以消除计时开销。To reduce overhead. Performance Schema overhead should be minimal even with all instruments enabled, but perhaps you want to reduce it further. Or you do not care about timing events and want to disable the timing code to eliminate timing overhead.
To avoid filling the current-events or history tables with events in which you have no interest. Pre-filtering leaves more “room” in these tables for instances of rows for enabled instrument types. If you enable only file instruments with pre-filtering, no rows are collected for nonfile instruments. With post-filtering, nonfile events are collected, leaving fewer rows for file events.
为了避免维护某些类型的事件表。如果你禁用一个消费者，服务器就不会花时间为该消费者维护目标。例如，如果你不关心事件历史，你可以禁用历史表的消费者以提高性能。To avoid maintaining some kinds of event tables. If you disable a consumer, the server does not spend time maintaining destinations for that consumer. For example, if you do not care about event histories, you can disable the history table consumers to improve performance.
后过滤。 这涉及在从性能模式表中选择信息的查询中使用
WHERE子句，以指定你想要查看的可用事件。后过滤是按用户执行的，因为每个用户选择他们感兴趣的可用事件。Post-filtering. This involves the use ofWHEREclauses in queries that select information from Performance Schema tables, to specify which of the available events you want to see. Post-filtering is performed on a per-user basis because individual users select which of the available events are of interest.使用后过滤的原因：Reasons to use post-filtering:
为了避免为每个用户决定哪些事件信息是有兴趣的。To avoid making decisions for individual users about which event information is of interest.
在使用预过滤施加限制之前不知道的情况下，使用性能模式调查性能问题。To use the Performance Schema to investigate a performance issue when the restrictions to impose using pre-filtering are not known in advance.
以下部分提供了有关预过滤的更多详细信息，并提供了在过滤操作中命名仪器或消费者的指南。有关编写查询以检索信息（过滤后）的信息，请参见 第 29.5 节，“性能模式查询”。The following sections provide more detail about pre-filtering and provide guidelines for naming instruments or consumers in filtering operations. For information about writing queries to retrieve information (post-filtering), see Section 29.5, “Performance Schema Queries”.