パフォーマンススキーマインストゥルメントはステートメントの実行を計測します。 ステートメントイベントは、イベント階層の上位レベルで発生します。 イベント階層内では、待機イベントはステージイベント内にネストされ、ステージイベントはステートメントイベント内にネストされ、ステートメントイベントはトランザクションイベント内にネストされます。
これらのテーブルはステートメントイベントを格納します。
events_statements_current: 各スレッドの現在のステートメントイベント。events_statements_history: スレッドごとに終了した最新のステートメントイベント。events_statements_history_long: グローバルに (すべてのスレッドで) 終了した最新のステートメントイベント。prepared_statements_instances: プリペアドステートメントのインスタンスおよび統計
次の各セクションでは、ステートメントイベントテーブルについて説明します。 ステートメントイベントに関する情報を集計するサマリーテーブルもあります。セクション27.12.18.3「ステートメントサマリーテーブル」を参照してください。
3 つの events_statements_ イベントテーブル間の関係の詳細は、セクション27.9「現在および過去のイベントのパフォーマンススキーマテーブル」 を参照してください。
xxx
ステートメントイベント収集の構成
ステートメントイベントを収集するかどうかを制御するには、関連するインストゥルメントおよびコンシューマの状態を設定します:
setup_instrumentsテーブルには、statementで始まる名前を持つインストゥルメントが格納されます。 これらのインストゥルメントを使用して、個々のステートメントイベントクラスの収集を有効または無効にします。setup_consumersテーブルには、現在および過去のステートメントイベントテーブル名に対応する名前を持つコンシューマ値と、ステートメントダイジェストコンシューマが含まれます。 これらのコンシューマを使用して、ステートメントイベントおよびステートメントダイジェストのコレクションをフィルタします。
ステートメントインストゥルメントはデフォルトで有効になっており、events_statements_current、events_statements_history および statements_digest ステートメントコンシューマはデフォルトで有効になっています:
mysql> SELECT NAME, ENABLED, TIMED
FROM performance_schema.setup_instruments
WHERE NAME LIKE 'statement/%';
+---------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------+---------+-------+
| statement/sql/select | YES | YES |
| statement/sql/create_table | YES | YES |
| statement/sql/create_index | YES | YES |
...
| statement/sp/stmt | YES | YES |
| statement/sp/set | YES | YES |
| statement/sp/set_trigger_field | YES | YES |
| statement/scheduler/event | YES | YES |
| statement/com/Sleep | YES | YES |
| statement/com/Quit | YES | YES |
| statement/com/Init DB | YES | YES |
...
| statement/abstract/Query | YES | YES |
| statement/abstract/new_packet | YES | YES |
| statement/abstract/relay_log | YES | YES |
+---------------------------------------------+---------+-------+mysql> SELECT *
FROM performance_schema.setup_consumers
WHERE NAME LIKE '%statements%';
+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| statements_digest | YES |
+--------------------------------+---------+
サーバー起動時のステートメントイベント収集を制御するには、my.cnf ファイルで次のような行を使用します:
-
有効化:
[mysqld] performance-schema-instrument='statement/%=ON' performance-schema-consumer-events-statements-current=ON performance-schema-consumer-events-statements-history=ON performance-schema-consumer-events-statements-history-long=ON performance-schema-consumer-statements-digest=ON -
無効化:
[mysqld] performance-schema-instrument='statement/%=OFF' performance-schema-consumer-events-statements-current=OFF performance-schema-consumer-events-statements-history=OFF performance-schema-consumer-events-statements-history-long=OFF performance-schema-consumer-statements-digest=OFF
実行時にステートメントイベント収集を制御するには、setup_instruments テーブルおよび setup_consumers テーブルを更新します:
-
有効化:
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/%'; UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%statements%'; -
無効化:
UPDATE performance_schema.setup_instruments SET ENABLED = 'NO', TIMED = 'NO' WHERE NAME LIKE 'statement/%'; UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME LIKE '%statements%';
特定のステートメントイベントのみを収集するには、対応するステートメントインストゥルメントのみを有効にします。 特定のステートメントイベントテーブルについてのみステートメントイベントを収集するには、ステートメントインストゥルメントを有効にしますが、目的のテーブルに対応するステートメントコンシューマのみを有効にします。
イベント収集の構成の詳細は、セクション27.3「パフォーマンススキーマ起動構成」 および セクション27.4「パフォーマンススキーマ実行時構成」 を参照してください。
ステートメントモニタリング
ステートメントのモニタリングは、サーバーがスレッドに対してアクティビティーがリクエストされていることを確認した時点から、すべてのアクティビティーが終了した時点までに開始されます。 一般に、これはサーバーがクライアントから最初のパケットを受け取ったときから、サーバーが応答の送信を終了したときまでを意味します。 ストアドプログラム内のステートメントは、ほかのステートメントと同様にモニターされます。
パフォーマンススキーマがリクエスト (サーバーコマンドまたは SQL ステートメント) をインストゥルメントする場合、最終的なインストゥルメント名に到達するまで、より一般的 (または「抽象的」) から、より具体的へと段階を追って進むインストゥルメント名を使用します。
最終インストゥルメント名はサーバーコマンドと SQL ステートメントに対応します。
サーバーコマンドは
mysql_com.hヘッダーファイルに定義され、sql/sql_parse.ccで処理されるCOM_に対応します。 例はxxxcodesCOM_PINGとCOM_QUITです。 コマンドのインストゥルメントは、statement/com/Pingやstatement/com/Quitなどのstatement/comから始まる名前を持ちます。SQL ステートメントは
DELETE FROM t1またはSELECT * FROM t2などのテキストとして表されます。 SQL ステートメントのインストゥルメントは、statement/sql/deleteやstatement/sql/selectなどのstatement/sqlから始まる名前を持ちます。
いくつかの最終インストゥルメント名はエラー処理に固有です。
statement/com/Errorは帯域外のサーバーによって受信されたメッセージから構成されます。 これはサーバーが理解しないクライアントによって送信されたコマンドを検出するために使用できます。 これは、構成が誤っているか、サーバーよりも新しい MySQL のバージョンを使用しているクライアントや、サーバーへの攻撃を試みているクライアントの識別などの目的で役に立つことがあります。statement/sql/errorは解析に失敗した SQL ステートメントから構成されます。 これはクライアントによって送信された不正な形式のクエリーを検出するために使用できます。 解析に失敗するクエリーは、解析するが、実行中のエラーのために失敗するクエリーと異なります。 たとえば、SELECT * FROMは不正な形式で、statement/sql/errorインストゥルメントが使用されます。 対照的にSELECT *は解析しますが、「表が指定されていません」エラーを伴って失敗します。 この場合、statement/sql/selectが使用され、ステートメントイベントにはエラーの性質を示す情報が含まれます。
リクエストはこれらの任意のソースから取得できます。
リクエストをパケットとして送信するクライアントからのコマンドまたはステートメントリクエストとして
レプリカのリレーログから読み取られたステートメント文字列として
イベントスケジューラのイベントとして
リクエストの詳細は最初は不明で、パフォーマンススキーマはリクエストのソースに依存する順序で、抽象から特定のインストゥルメント名に進みます。
クライアントから受信したリクエストの場合:
サーバーがソケットレベルで新しいパケットを検出すると、新しいステートメントが
statement/abstract/new_packetの抽象インストゥルメント名で開始されます。サーバーはパケット番号を読み取ると、受信したリクエストの種類について詳しく知り、パフォーマンススキーマがインストゥルメント名を絞り込みます。 たとえば、リクエストが
COM_PINGパケットの場合、インストゥルメント名はstatement/com/Pingになり、それが最終名になります。 リクエストがCOM_QUERYパケットの場合、特定のタイプのステートメントではなく SQL ステートメントに対応することがわかっています。 この場合、インストゥルメントはある抽象名から、やや具体的だが、まだ抽象名であるstatement/abstract/Queryに変更され、リクエストはさらに分類する必要があります。リクエストがステートメントである場合、ステートメントテキストが読み取られ、パーサーに提供されます。 解析後、正確なステートメントの種類が認識されます。 リクエストがたとえば
INSERTステートメントの場合、パフォーマンススキーマはインストゥルメント名をstatement/abstract/Queryから最終名であるstatement/sql/insertに絞り込みます。
レプリカのリレーログからステートメントとして読み取られたリクエストの場合:
リレーログ内のステートメントはテキストとして保存され、そのように読み取られます。 ネットワークプロトコルはないため、
statement/abstract/new_packetインストゥルメントは使用されません。 代わりに、初期インストゥルメントはstatement/abstract/relay_logになります。ステートメントが解析されると、正確なステートメントの種類が認識されます。 リクエストがたとえば
INSERTステートメントの場合、パフォーマンススキーマはインストゥルメント名をstatement/abstract/Queryから最終名であるstatement/sql/insertに絞り込みます。
先述の説明はステートメントベースのレプリケーションにのみ適用されます。 行ベースレプリケーションの場合、行の変更を処理するレプリカで実行されるテーブル I/O は計測できますが、リレーログ内の行イベントは個別のステートメントとして表示されません。
イベントスケジューラから受信したリクエストの場合:
イベント実行は、statement/scheduler/event という名前を使用してインストゥルメントされます。 これは最終名です。
イベント本体内で実行されるステートメントは、前の抽象インストゥルメントを使用せずに、statement/sql/* 名を使用してインストゥルメントされます。 イベントはストアドプログラムであり、ストアドプログラムは実行前にメモリー内でプリコンパイルされます。 したがって、実行時に解析は行われず、各ステートメントのタイプは実行時に認識されます。
イベント本体内で実行されるステートメントは子ステートメントです。 たとえば、イベントが INSERT ステートメントを実行する場合、イベント自体の実行は親で、statement/scheduler/event を使用してインスツルメント処理され、INSERT は statement/sql/insert を使用してインスツルメント処理された子です。 親子関係には、between の個別のインストゥルメントされた操作が保持されます。 これは、範囲内で単一のインストゥルメント操作が発生する絞込みのシーケンスとは異なり、抽象インストゥルメント名から最終インストゥルメント名まで異なります。
ステートメントに対して収集される統計の場合、各ステートメントの種類に使用される最終 statement/sql/* インストゥルメントを有効にするだけでは十分ではありません。 抽象 statement/abstract/* インストゥルメントも有効にする必要があります。 すべてのステートメントインストゥルメントがデフォルトで有効にされるため、これは通常問題にならないはずです。 ただし、ステートメントインストゥルメントを選択して有効または無効にするアプリケーションは、抽象インストゥルメントを無効にすると、個々のステートメントインストゥルメントの統計収集も無効になることを考慮する必要があります。 たとえば、INSERT ステートメントの統計を収集するには、statement/sql/insert を有効にする必要がありますが、statement/abstract/new_packet と statement/abstract/Query も有効にする必要があります。 同様に、レプリケートされたステートメントをインストゥルメントするには、statement/abstract/relay_log が有効にされている必要があります。
ステートメントが最終ステートメント名として抽象インストゥルメントに分類されることはないため、statement/abstract/Query などの抽象インストゥルメントに対して統計は集計されません。