threads テーブルは各サーバースレッドの行を格納します。 各行は、スレッドに関する情報を格納し、それに対するモニタリングが有効にされているかどうかを示します。 スレッドをモニターするパフォーマンススキーマの場合、これらのことが当てはまる必要があります。
setup_consumersテーブル内のthread_instrumentationコンシューマはYESである必要があります。threads.INSTRUMENTEDカラムはYESである必要があります。setup_instrumentsテーブル内で有効にされているインストゥルメントから生成されたスレッドイベントに対してのみ、モニタリングが行われます。
threads テーブルには、履歴イベントロギングを実行するかどうかもサーバースレッドごとに示されます。 これには待機イベント、ステージイベント、ステートメントイベントおよびトランザクションイベントが含まれ、次のテーブルへのロギングに影響します:
events_waits_history
events_waits_history_long
events_stages_history
events_stages_history_long
events_statements_history
events_statements_history_long
events_transactions_history
events_transactions_history_long履歴イベントロギングを実行するには、次のことが当てはまる必要があります:
setup_consumersテーブルの適切な履歴関連コンシューマを有効にする必要があります。 たとえば、events_waits_historyおよびevents_waits_history_longテーブルの待機イベントロギングでは、対応するevents_waits_historyおよびevents_waits_history_longコンシューマがYESである必要があります。threads.HISTORYカラムはYESである必要があります。ロギングは、
setup_instrumentsテーブルで有効になっているインストゥルメントから生成されたスレッドイベントに対してのみ行われます。
フォアグラウンドスレッド (クライアント接続の結果) の場合、threads テーブルの行の INSTRUMENTED および HISTORY カラムの初期値は、スレッドに関連付けられたユーザーアカウントが setup_actors テーブルのいずれかの行と一致するかどうかによって決まります。 値は、一致する setup_actors テーブルの行の ENABLED カラムおよび HISTORY カラムから取得されます。
バックグラウンドスレッドの場合、関連付けられたユーザーはありません。 INSTRUMENTED および HISTORY はデフォルトで YES であり、setup_actors は参照されません。
初期 setup_actors の内容は次のように見えます。
mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| % | % | % | YES | YES |
+------+------+------+---------+---------+
HOST および USER カラムにはリテラルのホストまたはユーザー名、または任意の名前に一致する '%' が格納されているべきです。
ENABLED および HISTORY のカラムは、前述の他の条件に従って、一致するスレッドのインストゥルメンテーションおよび履歴イベントロギングを有効にするかどうかを示します。
パフォーマンススキーマは、setup_actors の新しいフォアグラウンドスレッドごとに一致をチェックするときに、USER および HOST カラムを使用して、より具体的な一致を最初に見つけようとします (ROLE は使用されません):
USER='およびliteral'HOST='を含む行。literal'USER='およびliteral'HOST='%'を含む行。USER='%'およびHOST='を含む行。literal'USER='%'およびHOST='%'を含む行。
一致する setup_actors 行が異なると USER 値と HOST 値が異なる可能性があるため、一致が発生する順序は重要です。 これにより、ENABLED および HISTORY のカラム値に基づいて、インスツルメント処理および履歴イベントロギングをホスト、ユーザーまたはアカウント (ユーザーとホストの組合せ) ごとに選択的に適用できます:
最適な一致が
ENABLED=YESの行である場合、スレッドのINSTRUMENTED値はYESになります。 最適な一致がHISTORY=YESの行である場合、スレッドのHISTORY値はYESになります。最適な一致が
ENABLED=NOの行である場合、スレッドのINSTRUMENTED値はNOになります。 最適な一致がHISTORY=NOの行である場合、スレッドのHISTORY値はNOになります。一致するものが見つからない場合、スレッドの
INSTRUMENTEDおよびHISTORYの値はNOになります。
setup_actors 行の ENABLED カラムと HISTORY カラムは、互いに独立して YES または NO に設定できます。 つまり、履歴イベントを収集するかどうかとは別にインストゥルメンテーションを有効にできます。
デフォルトでは、監視および履歴イベント収集はすべての新しいフォアグラウンドスレッドに対して有効になっています。これは、setup_actors テーブルには、HOST と USER の両方の'%'を含む行が最初に含まれているためです。 一部のフォアグラウンドスレッドに対してのみ監視を有効にするなど、より限定的な照合を実行するには、この行が任意の接続に一致するため、この行を変更し、より具体的な HOST/USER の組合せに対して行を追加する必要があります。
次のように setup_actors を変更するとします。
UPDATE performance_schema.setup_actors
SET ENABLED = 'NO', HISTORY = 'NO'
WHERE HOST = '%' AND USER = '%';
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('localhost','joe','%','YES','YES');
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('hosta.example.com','joe','%','YES','NO');
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('%','sam','%','NO','YES');
UPDATE ステートメントは、インストゥルメンテーションおよび履歴イベント収集を無効にするようにデフォルトの一致を変更します。 INSERT ステートメントは、より具体的な一致のために行を追加します。
パフォーマンススキーマは、新しい接続スレッドの INSTRUMENTED および HISTORY の値を次のように設定する方法を決定します:
joeがローカルホストから接続する場合、接続は最初に挿入された行に一致します。 スレッドのINSTRUMENTEDおよびHISTORYの値はYESになります。joeがhosta.example.comから接続する場合、接続は挿入された 2 番目の行と一致します。 スレッドのINSTRUMENTED値はYESになり、HISTORY値はNOになります。joeがほかのすべてのホストから接続する場合、一致はありません。 スレッドのINSTRUMENTEDおよびHISTORYの値はNOになります。samがいずれかのホストから接続する場合、接続は 3 番目に挿入された行と一致します。 スレッドのINSTRUMENTED値はNOになり、HISTORY値はYESになります。その他の接続では、
HOSTおよびUSERが'%'に設定されている行が一致します。 この行のENABLEDおよびHISTORYはNOに設定されているため、スレッドのINSTRUMENTEDおよびHISTORYの値はNOになります。
setup_actors テーブルの変更は、変更後に作成されたフォアグラウンドスレッドにのみ影響し、既存のスレッドには影響しません。 既存のスレッドに影響を与えるには、threads テーブルの行の INSTRUMENTED および HISTORY カラムを変更します。