Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb


このページは機械翻訳したものです。

27.19.2 親イベント情報の取得

data_locks テーブルには、保持およびリクエストされたデータロックが表示されます。 このテーブルの行には、ロックを所有するセッションのスレッド ID を示す THREAD_ID カラムと、ロックの原因となったパフォーマンススキーマイベントを示す EVENT_ID カラムがあります。 (THREAD_IDEVENT_ID) 値のタプルは、他の「パフォーマンススキーマ」テーブルの親イベントを暗黙的に識別します:

  • events_waits_xxx テーブルの親待機イベント

  • events_stages_xxx テーブルの親ステージイベント

  • events_statements_xxx テーブルの親ステートメントイベント

  • events_transactions_current テーブルの親トランザクションイベント

親イベントの詳細を取得するには、THREAD_ID カラムと EVENT_ID カラムを適切な親イベントテーブルの同名のカラムと結合します。 リレーションはネストされたセットデータモデルに基づいているため、結合には複数の句があります。 parent および child でそれぞれ表される親テーブルと子テーブルの場合、結合は次のようになります:

WHERE
  parent.THREAD_ID = child.THREAD_ID        /* 1 */
  AND parent.EVENT_ID < child.EVENT_ID      /* 2 */
  AND (
    child.EVENT_ID <= parent.END_EVENT_ID   /* 3a */
    OR parent.END_EVENT_ID IS NULL          /* 3b */
  )

結合の条件は次のとおりです:

  1. 親イベントと子イベントは同じスレッド内にあります。

  2. 子イベントは親イベントの後に開始されるため、その EVENT_ID 値は親の値より大きくなります。

  3. 親イベントが完了したか、まだ実行中です。

ロック情報を検索するために、data_locks は子イベントを含むテーブルです。

data_locks テーブルには既存のロックのみが表示されるため、親イベントを含むテーブルに関して次の考慮事項が適用されます:

  • トランザクションの場合、唯一の選択肢は events_transactions_current です。 トランザクションが完了した場合、そのトランザクションはトランザクション履歴テーブルにある可能性がありますが、ロックはすでに解除されています。

  • ステートメントの場合、ロックを取得したステートメントがすでに完了したトランザクション内のステートメントであるか (events_statements_history を使用)、ステートメントがまだ実行中であるか (events_statements_current を使用)、によって異なります。

  • ステージの場合、ロジックはステートメントのロジックと似ています。events_stages_history または events_stages_current を使用します。

  • 待機の場合、ロジックはステートメントのロジックと似ています。events_waits_history または events_waits_current を使用します。 ただし、多くの待機が記録されるため、ロックの原因となった待機はすでに履歴テーブルからなくなっている可能性があります。

待機イベント、ステージイベントおよびステートメントイベントは、履歴からすぐに消えます。 長時間前に実行されたステートメントがロックを取得したが、まだオープンしているトランザクションにある場合、ステートメントを見つけることはできない可能性がありますが、トランザクションを見つけることはできます。

このため、ネストされたセットデータモデルは親イベントの検索に適しています。 中間ノードがすでに履歴テーブルから削除されている場合、親/子関係の次のリンク (データロック ->親待機 ->親ステージ ->親トランザクション) は適切に機能しません。

次のシナリオは、ロックが取得されたステートメントの親トランザクションを検索する方法を示しています:

セッション A:

[1] START TRANSACTION;
[2] SELECT * FROM t1 WHERE pk = 1;
[3] SELECT 'Hello, world';

セッション B:

SELECT ...
FROM performance_schema.events_transactions_current AS parent
  INNER JOIN performance_schema.data_locks AS child
WHERE
  parent.THREAD_ID = child.THREAD_ID
  AND parent.EVENT_ID < child.EVENT_ID
  AND (
    child.EVENT_ID <= parent.END_EVENT_ID
    OR parent.END_EVENT_ID IS NULL
  );

セッション B のクエリーでは、pk=1 を使用してレコードのデータロックを所有しているステートメント[2]を表示する必要があります。

セッション A がさらにステートメントを実行すると、[2]は履歴テーブルからフェードアウトします。

クエリーでは、実行されたステートメント、ステージまたは待機の数に関係なく、[1]で開始されたトランザクションが表示されます。

サーバーで他のクエリーが実行されないことを前提として (履歴が保持されるように)、events_xxx_history_long テーブルを使用してさらにデータを表示することもできます (トランザクションを除く)。