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

親イベントの詳細を取得するには、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 */
  )

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

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

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

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

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

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

セッション 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 テーブルを使用してさらにデータを表示することもできます (トランザクションを除く)。