事前フィルタリングは、パフォーマンススキーマによって行われ、すべてのユーザーに適用されるグローバルな効果を持ちます。事前フィルタリングは、イベント処理のプロデューサまたはコンシューマステージに適用できます。
-
プロデューサステージで事前フィルタリングを構成するには、いくつかのテーブルを使用できます。
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
にリセットすることで、行を削除することではありません。
次のセクションでは、特定のテーブルを使用して、パフォーマンススキーマの事前フィルタリングを制御する方法について説明します。
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';
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
はテーブル内の一部の行に一致するオブジェクトのモニタリングを有効にするためにのみ使用されます。テーブルによるインストゥルメンテーションを明示的に無効にする方法はありません。
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
テーブルへの変更は既存のスレッドに影響しません。
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
テーブルへのステートメントイベントの収集を無効または有効にします。
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
_currentevents_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
_currentxxx
はwaits
、stages
、statements
ですテーブル
setup_actors
カラム
threads.instrumented
先述の構成に関連して保守される追加の出力テーブル:
events_
。ここでxxx
_summary_by_yyy
_by_event_namexxx
は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
_historyxxx
はwaits
、stages
、statements
ですコンシューマ
events_
。ここでxxx
_history_longxxx
はwaits
、stages
、statements
です
先述の構成に関連して保守される追加の出力テーブル:
events_
。ここでxxx
_currentxxx
はwaits
、stages
、statements
です
グローバル、スレッド、現在のイベント、およびイベント履歴インストゥルメンテーション
events_
および xxx
_historyevents_
コンシューマは無効にされているため、先述の構成はイベント履歴を収集しません。それらのコンシューマは個別またはまとめて有効にして、スレッドごと、グローバルに、またはその両方でイベント履歴を収集できます。
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
_historyxxx
は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_longxxx
は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
_historyxxx
はwaits
、stages
、statements
ですevents_
。ここでxxx
_history_longxxx
はwaits
、stages
、statements
です