22.2.3.3 イベントの事前フィルタリング

[+/-]

22.2.3.3.1 インストゥルメントによる事前フィルタリング

22.2.3.3.2 オブジェクトによる事前フィルタリング

22.2.3.3.3 スレッドによる事前フィルタリング

22.2.3.3.4 コンシューマによる事前フィルタリング

22.2.3.3.5 コンシューマ構成の例

事前フィルタリングは、パフォーマンススキーマによって行われ、すべてのユーザーに適用されるグローバルな効果を持ちます。事前フィルタリングは、イベント処理のプロデューサまたはコンシューマステージに適用できます。

• プロデューサステージで事前フィルタリングを構成するには、いくつかのテーブルを使用できます。

  • setup_instruments は使用可能なインストゥルメントを示します。このテーブルで無効にされているインストゥルメントは、ほかの生成関連セットアップテーブルの内容に関係なく、イベントを生成しません。このテーブルで有効にされているインストゥルメントは、イベントの生成が許可され、ほかのテーブルの内容に依存します。

  • setup_objects は、パフォーマンススキーマが特定のテーブルオブジェクトをモニターするかどうかを制御します。

  • threads スレッドは各サーバースレッドでモニタリングが有効にされているかどうかを示します。

  • setup_actors は、新しいフォアグラウンドスレッドの初期モニタリング状態を決定します。

• コンシューマステージで事前フィルタリングを構成するには、setup_consumers テーブルを変更します。これによって、イベントの送信先が決まります。setup_consumers はイベント生成にも暗黙的に影響します。特定のイベントがどの宛先にも送信されない (つまり消費されない) 場合、パフォーマンススキーマはそれを生成しません。

これらのいずれかのテーブルの変更は、setup_actors を除いて、ただちにモニタリングに影響します。setup_actors の変更は、変更後に作成されるフォアグラウンドスレッドにのみ影響します。

モニタリング構成を変更すると、パフォーマンススキーマは履歴テーブルをフラッシュしません。すでに収集されたイベントは、新しいイベントによって置き換えられるまで、現在のイベントと履歴テーブルに残ります。インストゥルメントを無効にする場合、それらのイベントが関心のある新しいイベントによって置き換えられるまで、しばらく待つ必要がある場合があります。または、TRUNCATE TABLE を使用して、履歴テーブルを空にします。

インストゥルメンテーションを変更したら、サマリーテーブルを切り捨てて、以前に収集されたイベントの集計情報をクリアする必要がある場合があります。events_statements_summary_by_digest を除き、サマリーテーブルの TRUNCATE TABLE の効果は、サマリーカラムを 0 または NULL にリセットすることで、行を削除することではありません。

次のセクションでは、特定のテーブルを使用して、パフォーマンススキーマの事前フィルタリングを制御する方法について説明します。

22.2.3.3.1 インストゥルメントによる事前フィルタリング

setup_instruments テーブルは使用可能なインストゥルメントを一覧表示します。

mysql> SELECT * FROM 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   |
...
| wait/synch/rwlock/sql/LOCK_grant                           | YES     | YES   |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger                  | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_connect                | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_slave                  | YES     | YES   |
...
| wait/io/file/sql/binlog                                    | YES     | YES   |
| wait/io/file/sql/binlog_index                              | YES     | YES   |
| wait/io/file/sql/casetest                                  | YES     | YES   |
| wait/io/file/sql/dbopt                                     | YES     | YES   |
...

インストゥルメントを有効にするかどうかを制御するには、その ENABLED カラムを YES または NO に設定します。有効にされたインストゥルメントのタイミング情報を収集するかどうかを構成するには、その TIMED 値を YES または NO に設定します。TIMED カラムを設定すると、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」に説明するように、パフォーマンススキーマテーブルの内容に影響します。

setup_instruments テーブルへの変更はただちにモニタリングに影響します。

setup_instruments テーブルはイベント生成のもっとも基本的な制御の形式を提供します。モニターされるオブジェクトやスレッドの種類に基づいて、イベント生成をさらに絞り込むには、セクション22.2.3.3「イベントの事前フィルタリング」に説明するように、ほかのテーブルを使用できます。

次の例に、setup_instruments テーブルへの可能な操作を示します。ほかの事前フィルタリング操作と同様に、これらの変更はすべてのユーザーに影響します。これらの一部のクエリーでは、LIKE 演算子とパターンマッチインストゥルメント名を使用しています。インストゥルメントを選択するためのパターンの指定に関する追加情報については、セクション22.2.3.4「フィルタリング操作のインストゥルメントまたはコンシューマの指定」を参照してください。

• すべてのインストゥルメントを無効にします。

  mysql> UPDATE setup_instruments SET ENABLED = 'NO';

  これでイベントが収集されなくなります。

• すべてのインストゥルメントを無効にし、それらを現在の無効にされているインストゥルメントのセットに追加します。

  mysql> UPDATE setup_instruments SET ENABLED = 'NO'
      -> WHERE NAME LIKE 'wait/io/file/%';

• ファイルインストゥルメントのみを無効にし、ほかのすべてのインストゥルメントを有効にします。

  mysql> UPDATE setup_instruments
      -> SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');

• mysys ライブラリ内のインストゥルメントを除くすべてのインストゥルメントを有効にします。

  mysql> UPDATE setup_instruments
      -> SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;

• 特定のインストゥルメントを無効にします。

  mysql> UPDATE setup_instruments SET ENABLED = 'NO'
      -> WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';

• インストゥルメントの状態を切り替えるには、その ENABLED 値を「反転」します。

  mysql> UPDATE setup_instruments
      -> SET ENABLED = IF(ENABLED = 'YES', 'NO', 'YES')
      -> WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';

• すべてのイベントのタイミングを無効にします。

  mysql> UPDATE setup_instruments SET TIMED = 'NO';

22.2.3.3.2 オブジェクトによる事前フィルタリング

setup_objects テーブルは、パフォーマンススキーマが特定のテーブルオブジェクトをモニターするかどうかを制御します。初期 setup_objects の内容は次のように見えます。

mysql> SELECT * FROM setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| TABLE       | mysql              | %           | NO      | NO    |
| TABLE       | performance_schema | %           | NO      | NO    |
| TABLE       | information_schema | %           | NO      | NO    |
| TABLE       | %                  | %           | YES     | YES   |
+-------------+--------------------+-------------+---------+-------+

setup_objects テーブルへの変更はただちにオブジェクトモニタリングに影響します。

OBJECT_TYPE カラムは行が適用されるオブジェクトの種類を示します。TABLE フィルタリングはテーブル I/O イベント (wait/io/table/sql/handler インストゥルメント) およびテーブルロックイベント (wait/lock/table/sql/handler インストゥルメント) に影響します。

OBJECT_SCHEMA および OBJECT_NAME カラムにはリテラルのスキーマまたはテーブル名、または任意の名前に一致する '%' が格納されているべきです。

ENABLED カラムは一致するオブジェクトがモニターされているかどうかを示し、TIMED はタイミング情報を収集するかどうかを示します。

デフォルトのオブジェクト構成の効果は、mysql、INFORMATION_SCHEMA、および performance_schema データベースのテーブルを除くすべてのテーブルをインストゥルメントすることです。(INFORMATION_SCHEMA データベース内のテーブルは、setup_objects の内容に関係なくインストゥルメントされず、information_schema.% の行は単にこのデフォルトを明示します。)

パフォーマンススキーマは、setup_objects の一致をチェックする場合、まずより詳細な一致を見つけようとします。たとえば、テーブル db1.t1 では、'db1' と 't1'、次に 'db1' と '%'、次に '%' と '%' の一致を検索します。さまざまな一致する setup_objects 行はさまざまな ENABLED 値と TIMED 値を持つ可能性があるため、一致が発生する順序が重要です。

テーブル関連イベントの場合、パフォーマンススキーマは setup_objects の内容と setup_instruments を組み合わせて、インストゥルメントを有効にするかどうか、および有効にされているインストゥルメントの時間を測定するかどうかを判断します。

• setup_objects 内の行に一致するテーブルでは、テーブルインストゥルメントは、setup_instruments と setup_objects の両方で、ENABLED が YES である場合にのみイベントを生成します。

• 両方の値が YES の場合にのみ、タイミング情報が収集されるように、2 つのテーブル内の TIMED 値が組み合わされます。

setup_objects には、db1、db2、および db3 に適用される次の行が含まれるとします。

+-------------+---------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+---------------+-------------+---------+-------+
| TABLE       | db1           | t1          | YES     | YES   |
| TABLE       | db1           | t2          | NO      | NO    |
| TABLE       | db2           | %           | YES     | YES   |
| TABLE       | db3           | %           | NO      | NO    |
| TABLE       | %             | %           | YES     | YES   |
+-------------+---------------+-------------+---------+-------+

setup_instruments のテーブル関連インストゥルメントに NO の ENABLED 値がある場合、オブジェクトのイベントはモニターされません。ENABLED 値が YES の場合、イベントモニタリングは、関連 setup_objects 行内の ENABLED 値に従って行われます。

• db1.t1 イベントはモニターされます

• db1.t2 イベントはモニターされません

• db2.t3 イベントはモニターされます

• db3.t4 イベントはモニターされません

• db4.t5 イベントはモニターされます

setup_instruments および setup_objects テーブルの TIMED カラムを組み合わせて、イベントタイミング情報を収集するかどうかを判断する場合も同様のロジックが当てはまります。

永続的テーブルと一時テーブルが同じ名前を持つ場合、setup_objects 行に対する照合が両方に対して同様に行われます。一方のテーブルのモニタリングを有効にして、他方を有効にしないことはできません。ただし、各テーブルは個別にインストゥルメントされます。

ENABLED カラムは MySQL 5.6.3 で追加されました。ENABLED カラムがない初期バージョンでは、setup_objects はテーブル内の一部の行に一致するオブジェクトのモニタリングを有効にするためにのみ使用されます。テーブルによるインストゥルメンテーションを明示的に無効にする方法はありません。

22.2.3.3.3 スレッドによる事前フィルタリング

threads テーブルは各サーバースレッドの行を格納します。各行は、スレッドに関する情報を格納し、それに対するモニタリングが有効にされているかどうかを示します。スレッドをモニターするパフォーマンススキーマの場合、これらのことが当てはまる必要があります。

• setup_consumers テーブル内の thread_instrumentation コンシューマは YES である必要があります。

• thread.INSTRUMENTED カラムは YES である必要があります。

• setup_instruments テーブル内で有効にされているインストゥルメントから生成されたスレッドイベントに対してのみ、モニタリングが行われます。

threads テーブルの INSTRUMENTED カラムは各スレッドのモニタリング状態を示します。フォアグラウンドスレッド (クライアント接続の結果) では、初期 INSTRUMENTED 値は、スレッドに関連付けられているユーザーアカウントが setup_actors テーブル内のいずれかの行に一致するかどうかによって決定されます。バックグラウンドスレッドの場合、INSTRUMENTED はデフォルトで YES で、バックグラウンドスレッドに関連付けられたユーザーはないため、setup_actors は参照されません。どのスレッドでも、スレッドの有効期間の間にその INSTRUMENTED 値が変更されることがあります。

初期 setup_actors の内容は次のように見えます。

mysql> SELECT * FROM setup_actors;
+------+------+------+
| HOST | USER | ROLE |
+------+------+------+
| %    | %    | %    |
+------+------+------+

パフォーマンススキーマは HOST および USER カラムを使用し、新しい各フォアグラウンドスレッドと照合します。(ROLE は使用されません。)いずれかの行が一致した場合、スレッドの INSTRUMENTED 値は YES になり、それ以外の場合 NO になります。これにより、ホスト、ユーザー、またはホストとユーザーの組み合わせごとに、インストゥルメントが選択して適用されます。

HOST および USER カラムにはリテラルのホストまたはユーザー名、または任意の名前に一致する '%' が格納されているべきです。setup_actors テーブルには最初に HOST と USER のどちらにも '%' を含む行が格納されるため、デフォルトで、モニタリングはすべての新しいフォアグラウンドスレッドに対して有効にされます。一部のフォアグラウンドスレッドにのみモニタリングを有効にするなど、限定された照合を実行するには、この行はいずれかの接続に一致するため、これを削除する必要があります。

次のように setup_actors を変更するとします。

DELETE FROM setup_actors;

現在 setup_actors は空であるため、着信接続に一致する可能性のある行はありません。したがって、パフォーマンススキーマは、新しいすべてのフォアグラウンドスレッドの INSTRUMENTED カラムを NO に設定します。

さらに setup_actors を変更するとします。

INSERT INTO setup_actors (HOST,USER,ROLE) VALUES('localhost','joe','%');
INSERT INTO setup_actors (HOST,USER,ROLE) VALUES('%','sam','%');

ここで、パフォーマンススキーマは、次のように新しい接続スレッドの INSTRUMENTED 値の設定方法を判断します。

• joe がローカルホストから接続する場合、接続は最初に挿入された行に一致します。

• joe がほかのすべてのホストから接続する場合、一致はありません。

• sam が任意のホストから接続する場合、接続は 2 番目に挿入された行に一致します。

• ほかのすべての接続の場合、一致はありません。

setup_actors テーブルへの変更は既存のスレッドに影響しません。

22.2.3.3.4 コンシューマによる事前フィルタリング

setup_consumers テーブルは使用可能なコンシューマの種類とどれが有効にされているかを一覧表示します。

mysql> SELECT * FROM setup_consumers;
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| events_stages_current          | NO      |
| events_stages_history          | NO      |
| events_stages_history_long     | NO      |
| events_statements_current      | YES     |
| events_statements_history      | NO      |
| events_statements_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     |
+--------------------------------+---------+

コンシューマステージで、事前フィルタリングに影響するように、setup_consumers テーブルを変更し、イベントの送信先を決定します。コンシューマを有効または無効にするには、その ENABLED 値を YES または NO に設定します。

setup_consumers テーブルへの変更はただちにモニタリングに影響します。

コンシューマを無効にすると、サーバーはそのコンシューマの宛先の保守に時間を費やさなくなります。たとえば、履歴イベント情報に関心がない場合、履歴コンシューマを無効にします。

mysql> UPDATE setup_consumers
    -> SET ENABLED = 'NO' WHERE NAME LIKE '%history%';

setup_consumers テーブル内のコンシューマ設定は、高いレベルから低いレベルまでの階層を形成します。次の原則が当てはまります。

• パフォーマンススキーマがコンシューマをチェックし、コンシューマが有効にされていないかぎり、コンシューマに関連付けられている宛先はイベントを受信しません。

• コンシューマは、それが依存するすべてのコンシューマ (ある場合) が有効にされている場合にのみチェックされます。

• コンシューマがチェックされていない場合、またはチェックされているが無効にされている場合、それに依存するほかのコンシューマはチェックされません。

• 依存コンシューマには独自の依存コンシューマがあることがあります。

• イベントがどの宛先にも送信されない場合、パフォーマンススキーマはそれを生成しません。

次のリストに、使用可能なコンシューマ値を説明します。いくつかの代表的なコンシューマ構成とそれらのインストゥルメンテーションへの効果については、セクション22.2.3.3.5「コンシューマ構成の例」を参照してください。

グローバルおよびスレッドコンシューマ

• global_instrumentation は最高レベルのコンシューマです。global_instrumentation が NO の場合、それはグローバルインストゥルメンテーションを無効にします。ほかのすべての設定は低いレベルで、チェックされず、何が設定されているかは重要でありません。グローバルまたはスレッドごとに情報が保守されず、個々のイベントが現在のイベントまたはイベント履歴テーブルに収集されません。global_instrumentation が YES の場合、パフォーマンススキーマはグローバル状態の情報を保守し、thread_instrumentation コンシューマもチェックします。

• thread_instrumentation は global_instrumentation が YES の場合のみチェックされます。そうでなければ、thread_instrumentation が NO の場合、スレッド固有のインストゥルメンテーションが無効になり、すべての低レベル設定が無視されます。スレッドごとに情報が保守されず、個々のイベントが現在のイベントまたはイベント履歴テーブルに収集されません。thread_instrumentation が YES の場合、パフォーマンススキーマはスレッド固有の情報を保守し、events_xxx_current コンシューマもチェックします。

ステートメントダイジェストコンシューマ

このコンシューマは global_instrumentation が YES である必要があり、そうでないとそれはチェックされません。ステートメントイベントコンシューマへの依存関係がないため、events_statements_current に統計を収集する必要なく、ダイジェストごとに統計を取得することができ、これはオーバーヘッドの点で有利です。逆に、ダイジェストなしで、events_statements_current で詳細ステートメントを取得できます (DIGEST および DIGEST_TEXT カラムは NULL になります)。

待機イベントコンシューマ

これらのコンシューマには global_instrumentation と thread_instrumentation の両方が YES である必要があり、そうでないと、それらはチェックされません。チェックされた場合、それらは次のように動作します。

• events_waits_currentは NO の場合、events_waits_current テーブル内の個々の待機イベントの収集を無効にします。YES の場合、待機イベント収集を有効にし、パフォーマンススキーマは events_waits_history および events_waits_history_long コンシューマをチェックします。

• events_waits_history は event_waits_current が NO の場合にチェックされません。そうでない場合、NO または YES の events_waits_history 値は、events_waits_history テーブルへの待機イベントの収集を無効または有効にします。

• events_waits_history_long は event_waits_current が NO の場合にチェックされません。そうでない場合、NO または YES の events_waits_history_long 値は、events_waits_history_long テーブルへの待機イベントの収集を無効または有効にします。

ステージイベントコンシューマ

これらのコンシューマには global_instrumentation と thread_instrumentation の両方が YES である必要があり、そうでないと、それらはチェックされません。チェックされた場合、それらは次のように動作します。

• events_stages_currentは、NO の場合に、events_stages_current テーブルへの個々のステージイベントの収集を無効にします。YES の場合、ステージイベント収集を有効にし、パフォーマンススキーマは events_stages_history および events_stages_history_long コンシューマをチェックします。

• events_stages_history は event_stages_current が NO の場合にチェックされません。そうでない場合、NO または YES の events_stages_history 値は、events_stages_history テーブルへのステージイベントの収集を無効または有効にします。

• events_stages_history_long は event_stages_current が NO の場合にチェックされません。そうでない場合、NO または YES の events_stages_history_long 値は、events_stages_history_long テーブルへのステージイベントの収集を無効または有効にします。

ステートメントイベントコンシューマ

これらのコンシューマには global_instrumentation と thread_instrumentation の両方が YES である必要があり、そうでないと、それらはチェックされません。チェックされた場合、それらは次のように動作します。

• events_statements_currentは NO の場合、events_statements_current テーブルへの個々のステートメントイベントの収集を無効にします。YES の場合、ステートメントイベント収集を有効にし、パフォーマンススキーマは events_statements_history および events_statements_history_long コンシューマをチェックします。

• events_statements_history は events_statements_current が NO の場合にチェックされません。そうでない場合、NO または YES の events_statements_history 値は、events_statements_history テーブルへのステートメントイベントの収集を無効または有効にします。

• events_statements_history_long は events_statements_current が NO の場合にチェックされません。そうでない場合、NO または YES の events_statements_history_long 値は、events_statements_history_long テーブルへのステートメントイベントの収集を無効または有効にします。

22.2.3.3.5 コンシューマ構成の例

setup_consumers テーブル内のコンシューマ設定は、高いレベルから低いレベルまでの階層を形成します。次の説明では、コンシューマのしくみを説明し、コンシューマ設定が高から低に段階に有効にされたときの特定の構成とそれらの効果を示します。示されているコンシューマ値は代表的なものです。ここで説明する一般原則は、使用可能なほかのコンシューマ値に当てはまります。

構成の説明は、機能とオーバーヘッドが増加する順番で示しています。低レベルの設定を有効にして提供される情報が必要でない場合は、それらを無効にすると、パフォーマンススキーマがユーザーのために実行するコードが少なくなり、ユーザーが取捨選択する情報が少なくなります。

setup_consumers テーブルには次の値の階層が格納されます。

global_instrumentation
 thread_instrumentation
   events_waits_current
     events_waits_history
     events_waits_history_long
   events_stages_current
     events_stages_history
     events_stages_history_long
   events_statements_current
     events_statements_history
     events_statements_history_long
 statements_digest

注記

コンシューマ階層で、待機、ステージ、およびステートメントのコンシューマはすべて同じレベルになります。これは、待機イベントがステージイベント内にネストし、ステージイベントがステートメントイベント内にネストするイベントネスト階層とは異なります。

特定のコンシューマ設定が NO の場合、パフォーマンススキーマはコンシューマに関連付けられたインストゥルメンテーションを無効にし、すべての低レベルの設定を無視します。特定の設定が YES の場合、パフォーマンススキーマはそれに関連付けられたインストゥルメンテーションを有効にし、次の最低レベルの設定をチェックします。各コンシューマのルールの説明については、セクション22.2.3.3.4「コンシューマによる事前フィルタリング」を参照してください。

たとえば、global_instrumentation が有効にされている場合、thread_instrumentation がチェックされます。thread_instrumentation が有効にされている場合、events_xxx_current コンシューマがチェックされます。これらのうち events_waits_current が有効にされている場合、events_waits_history および events_waits_history_long がチェックされます。

次の構成の各説明は、パフォーマンススキーマがチェックするセットアップ要素と、それが保守する出力テーブル (つまり、それが情報を収集するテーブル) を示します。

インストゥルメンテーションなし

サーバー構成の状態:

mysql> SELECT * FROM setup_consumers;
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| global_instrumentation    | NO      |
...
+---------------------------+---------+

この構成では、何もインストゥルメントされません。

チェックされるセットアップ要素:

• テーブル setup_consumers、コンシューマ global_instrumentation

保守される出力テーブル:

• なし

グローバルインストゥルメンテーションのみ

サーバー構成の状態:

mysql> SELECT * FROM setup_consumers;
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| global_instrumentation    | YES     |
| thread_instrumentation    | NO      |
...
+---------------------------+---------+

この構成では、インストゥルメンテーションがグローバル状態に対してのみ保守されます。スレッドごとのインストゥルメンテーションは無効にされます。

先述の構成に関連して、チェックされる追加のセットアップ要素:

• テーブル setup_consumers、コンシューマ thread_instrumentation

• テーブル setup_instruments

• テーブル setup_objects

• テーブル setup_timers

先述の構成に関連して保守される追加の出力テーブル:

• mutex_instances

• rwlock_instances

• cond_instances

• file_instances

• users

• hosts

• accounts

• socket_summary_by_event_name

• file_summary_by_instance

• file_summary_by_event_name

• objects_summary_global_by_type

• table_lock_waits_summary_by_table

• table_io_waits_summary_by_index_usage

• table_io_waits_summary_by_table

• events_waits_summary_by_instance

• events_waits_summary_global_by_event_name

• events_stages_summary_global_by_event_name

• events_statements_summary_global_by_event_name

グローバルおよびスレッドインストゥルメンテーションのみ

サーバー構成の状態:

mysql> SELECT * FROM setup_consumers;
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| global_instrumentation         | YES     |
| thread_instrumentation         | YES     |
| events_waits_current           | NO      |
...
| events_stages_current          | NO      |
...
| events_statements_current      | YES     |
...
+--------------------------------+---------+

この構成では、インストゥルメンテーションがグローバルおよびスレッドごとに保守されます。現在のイベントまたはイベント履歴テーブルで、個々のイベントは収集されません。

先述の構成に関連して、チェックされる追加のセットアップ要素:

• テーブル setup_consumers、コンシューマ events_xxx_current。ここで xxx は waits、stages、statements です

• テーブル setup_actors

• カラム threads.instrumented

先述の構成に関連して保守される追加の出力テーブル:

• events_xxx_summary_by_yyy_by_event_name。ここで xxx は waits、stages、statements で、および yyy は thread、user、host、account です

グローバル、スレッド、および現在のイベントインストゥルメンテーション

サーバー構成の状態:

mysql> SELECT * FROM setup_consumers;
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| global_instrumentation         | YES     |
| thread_instrumentation         | YES     |
| events_waits_current           | YES     |
| events_waits_history           | NO      |
| events_waits_history_long      | NO      |
| events_stages_current          | YES     |
| events_stages_history          | NO      |
| events_stages_history_long     | NO      |
| events_statements_current      | YES     |
| events_statements_history      | NO      |
| events_statements_history_long | NO      |
...
+--------------------------------+---------+

この構成では、インストゥルメンテーションがグローバルおよびスレッドごとに保守されます。個々のイベントが現在のイベントテーブルに収集されますが、イベント履歴テーブルには収集されません。

先述の構成に関連して、チェックされる追加のセットアップ要素:

• コンシューマ events_xxx_history。ここで xxx は waits、stages、statements です

• コンシューマ events_xxx_history_long。ここで xxx は waits、stages、statements です

先述の構成に関連して保守される追加の出力テーブル:

• events_xxx_current。ここで xxx は waits、stages、statements です

グローバル、スレッド、現在のイベント、およびイベント履歴インストゥルメンテーション

events_xxx_history および events_xxx_history_long コンシューマは無効にされているため、先述の構成はイベント履歴を収集しません。それらのコンシューマは個別またはまとめて有効にして、スレッドごと、グローバルに、またはその両方でイベント履歴を収集できます。

この構成はスレッドごとにイベントを収集しますが、グローバルには収集しません。

mysql> SELECT * FROM setup_consumers;
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| global_instrumentation         | YES     |
| thread_instrumentation         | YES     |
| events_waits_current           | YES     |
| events_waits_history           | YES     |
| events_waits_history_long      | NO      |
| events_stages_current          | YES     |
| events_stages_history          | YES     |
| events_stages_history_long     | NO      |
| events_statements_current      | YES     |
| events_statements_history      | YES     |
| events_statements_history_long | NO      |
...
+--------------------------------+---------+

この構成で保守されるイベント履歴テーブル:

• events_xxx_history。ここで xxx は waits、stages、statements です

この構成はグローバルにイベント履歴を収集しますが、スレッドごとには収集しません。

mysql> SELECT * FROM setup_consumers;
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| global_instrumentation         | YES     |
| thread_instrumentation         | YES     |
| events_waits_current           | YES     |
| events_waits_history           | NO      |
| events_waits_history_long      | YES     |
| events_stages_current          | YES     |
| events_stages_history          | NO      |
| events_stages_history_long     | YES     |
| events_statements_current      | YES     |
| events_statements_history      | NO      |
| events_statements_history_long | YES     |
...
+--------------------------------+---------+

この構成で保守されるイベント履歴テーブル:

• events_xxx_history_long。ここで xxx は waits、stages、statements です

この構成はスレッドごとおよびグローバルにイベントを収集します。

mysql> SELECT * FROM setup_consumers;
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| global_instrumentation         | YES     |
| thread_instrumentation         | YES     |
| events_waits_current           | YES     |
| events_waits_history           | YES     |
| events_waits_history_long      | YES     |
| events_stages_current          | YES     |
| events_stages_history          | YES     |
| events_stages_history_long     | YES     |
| events_statements_current      | YES     |
| events_statements_history      | YES     |
| events_statements_history_long | YES     |
...
+--------------------------------+---------+

この構成で保守されるイベント履歴テーブル:

• events_xxx_history。ここで xxx は waits、stages、statements です

• events_xxx_history_long。ここで xxx は waits、stages、statements です