事前フィルタリングは収集されるイベント情報を制限し、特定のユーザーと関係ありません。 対照的に、事後フィルタリングは、各ユーザーが、事前フィルタリングの適用後に使用可能なイベントから選択するイベント情報を制限する、適切な WHERE 句でクエリーを使用することによって実行されます。

セクション27.4.3「イベントの事前フィルタリング」で、ファイルインストゥルメントの事前フィルタリング方法の例を示しました。 イベントテーブルにファイルと非ファイルの両方の情報が格納されている場合、事後フィルタリングはファイルイベントのみの情報を表示するもう 1 つの方法です。 イベント選択を適切に制限するには、クエリーに WHERE 句を追加します。

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 スキーマビューなど、関連するオブジェクトのパフォーマンスも向上します。 詳細は、セクション8.2.4「パフォーマンススキーマクエリーの最適化」を参照してください。