预过滤限制了收集哪些事件信息，并且独立于任何特定用户。相比之下，后过滤是由各个用户通过使用带有适当WHERE子句的查询来执行的，这些子句限制了从预过滤应用后可用的事件中选择哪些事件信息。Pre-filtering limits which event information is collected and is independent of any particular user. By contrast, post-filtering is performed by individual users through the use of queries with appropriate WHERE clauses that restrict what event information to select from the events available after pre-filtering has been applied.

在第 29.4.3 节，“事件预过滤”中，举了一个如何为文件工具进行预过滤的例子。如果事件表同时包含文件和非文件信息，后过滤是另一种仅查看文件事件信息的方法。在查询中添加WHERE子句以适当限制事件选择：In Section 29.4.3, “Event Pre-Filtering”, an example showed how to pre-filter for file instruments. If the event tables contain both file and nonfile information, post-filtering is another way to see information only for file events. Add a WHERE clause to queries to restrict event selection appropriately:

mysql> SELECT THREAD_ID, NUMBER_OF_BYTES
       FROM performance_schema.events_waits_history
       WHERE EVENT_NAME LIKE 'wait/io/file/%'
       AND NUMBER_OF_BYTES IS NOT NULL;
+-----------+-----------------+
| THREAD_ID | NUMBER_OF_BYTES |
+-----------+-----------------+
|        11 |              66 |
|        11 |              47 |
|        11 |             139 |
|         5 |              24 |
|         5 |             834 |
+-----------+-----------------+

大多数性能模式表都有索引，这使优化器能够使用除全表扫描之外的执行计划。这些索引还可以提高相关对象的性能，例如使用这些表的 sys 模式视图。欲了解更多信息，请参见 第 10.2.4 节，“优化性能模式查询”。Most Performance Schema tables have indexes, which gives the optimizer access to execution plans other than full table scans. These indexes also improve performance for related objects, such as sys schema views that use those tables. For more information, see Section 10.2.4, “Optimizing Performance Schema Queries”.