MySQL 8.0 リファレンスマニュアル

27.12.4.1 events_waits_current テーブル

events_waits_current テーブルには、現在の待機イベントが含まれます。 テーブルには、スレッドごとに最新の監視対象待機イベントの現在のステータスを示す 1 行が格納されるため、テーブルサイズを構成するためのシステム変数はありません。

待機イベント行を格納するテーブルのうち、events_waits_current はもっとも基本的です。 待機イベント行を格納するほかのテーブルは論理的に現在のイベントから派生します。 たとえば、events_waits_history テーブルと events_waits_history_long テーブルは、終了した最新の待機イベントのコレクションで、スレッド当たりの最大行数まで、およびすべてのスレッドにわたってグローバルに終了します。

3 つの待機イベントテーブル間の関係の詳細は、セクション27.9「現在および過去のイベントのパフォーマンススキーマテーブル」 を参照してください。

待機イベントを収集するかどうかの構成の詳細は、セクション27.12.4「パフォーマンススキーマ待機イベントテーブル」 を参照してください。

events_waits_current テーブルにはこれらのカラムがあります。

  • THREAD_ID、EVENT_ID

    イベントに関連付けられたスレッドとイベントの起動時のスレッドの現在のイベント番号。 ともに取得される THREAD_ID と EVENT_ID の値によって、行が一意に識別されます。 同じ値のペアを持つ行は 2 つありません。

  • END_EVENT_ID

    このカラムは、イベントの起動時に NULL に設定され、イベントの終了時にスレッドの現在のイベント番号に更新されます。

  • EVENT_NAME

    イベントを生成したインストゥルメントの名前。 これは setup_instruments テーブルからの NAME 値です。 セクション27.6「パフォーマンススキーマインストゥルメント命名規則」に説明するように、インストゥルメント名には複数の部分があり、階層を形成することがあります。

  • SOURCE

    イベントを生成した、インストゥルメントされたコードを格納するソースファイルの名前と、インストゥルメンテーションが行われたファイルの行番号。 これにより、ソースをチェックして、コードに含まれるものを正確に判断することができます。 たとえば、相互排他ロックまたはロックがブロックされた場合、これが発生するコンテキストをチェックできます。

  • TIMER_START、TIMER_END、TIMER_WAIT

    イベントのタイミング情報。 これらの値の単位はピコ秒 (秒の 1 兆分の 1) です。 TIMER_START および TIMER_END 値は、イベントのタイミングが開始されたときと終了したときを示します。 TIMER_WAIT はイベントの経過時間 (期間) です。

    イベントが終了していない場合、TIMER_END は現在のタイマー値で、TIMER_WAIT はこれまでに経過した時間です (TIMER_END - TIMER_START)。

    イベントが TIMED = NO のインストゥルメントから生成されている場合、タイミング情報は収集されず、TIMER_START、TIMER_END、および TIMER_WAIT はすべて NULL になります。

    イベント時間の単位としてのピコ秒および時間値に影響する要因については、セクション27.4.1「パフォーマンススキーマイベントタイミング」を参照してください。

  • SPINS

    相互排他ロックの場合、スピンラウンドの数。 値が NULL の場合、コードはスピンラウンドを使用しないか、スピニングがインストゥルメントされません。

  • OBJECT_SCHEMA、OBJECT_NAME、OBJECT_TYPE、OBJECT_INSTANCE_BEGIN

    これらのカラムは「作用している」オブジェクトを識別します。 その意味は、オブジェクトの種類によって異なります。

    同期オブジェクト (cond、mutex、および rwlock) の場合:

    • OBJECT_SCHEMA、OBJECT_NAME、および OBJECT_TYPE は NULL です。

    • OBJECT_INSTANCE_BEGIN はメモリー内の同期オブジェクトのアドレスです。

    ファイル I/O オブジェクトの場合:

    • OBJECT_SCHEMA は NULL です。

    • OBJECT_NAME はファイル名です。

    • OBJECT_TYPE は FILE です。

    • OBJECT_INSTANCE_BEGIN はメモリー内のアドレスです。

    ソケットオブジェクトの場合:

    • OBJECT_NAME はソケットの IP:PORT 値です。

    • OBJECT_INSTANCE_BEGIN はメモリー内のアドレスです。

    テーブル I/O オブジェクトの場合:

    • OBJECT_SCHEMA はテーブルを格納するスキーマの名前です。

    • OBJECT_NAME はテーブル名です。

    • OBJECT_TYPE は永続的ベーステーブルの TABLE または一時テーブルの TEMPORARY TABLE です。

    • OBJECT_INSTANCE_BEGIN はメモリー内のアドレスです。

    OBJECT_INSTANCE_BEGIN 値自体には、さまざまな値がさまざまなオブジェクトを示すことを除いて、意味がありません。 OBJECT_INSTANCE_BEGIN はデバッグに使用できます。 たとえば、それを GROUP BY OBJECT_INSTANCE_BEGIN で使用して、1,000 相互排他ロック (つまり、データの 1,000 ページまたはブロックを保護する) の負荷が均等に広がっているか、または少数のボトルネックだけに関わっているかを確認できます。 これにより、ログファイルやほかのデバッグまたはパフォーマンスツールで同じオブジェクトアドレスが見られた場合に、情報のほかのソースと関連付けることができます。

  • INDEX_NAME

    使用されるインデックスの名前。 PRIMARY はテーブルプライマリインデックスを示します。 NULL はインデックスが使用されなかったことを意味します。

  • NESTING_EVENT_ID

    このイベントが中にネストされているイベントの EVENT_ID 値。

  • NESTING_EVENT_TYPE

    ネストしているイベントの種類。 値は TRANSACTION, STATEMENT, STAGE または WAIT です。

  • OPERATION

    lock、read、または write などの実行される操作の種類。

  • NUMBER_OF_BYTES

    操作によって読み取りまたは書き込まれるバイト数。 テーブル I/O 待機 (wait/io/table/sql/handler インストゥルメントのイベント) の場合、NUMBER_OF_BYTES は行数を示します。 値が 1 より大きい場合、イベントはバッチ I/O 操作用です。 次の説明では、単一行レポートとバッチ I/O を反映するレポートの違いについて説明します。

    MySQL は、ネステッドループ実装を使用して結合を実行します。 パフォーマンススキーマインストゥルメンテーションのジョブは、結合内のテーブルごとに行数と累積実行時間を提供することです。 t1, t2, t3 のテーブル結合順序を使用して実行される次の形式の結合クエリーを想定します: 

    SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...

    テーブル「「ファンアウト」」は、結合処理中にテーブルを追加する行数の増減です。 テーブル t3 のファンアウトが 1 より大きい場合、行フェッチ操作の大部分はそのテーブルに対するものです。 結合が t1 から 10 行、t1 から t2 から 20 行、テーブル t2 の行ごとに t3 から 30 行にアクセスするとします。 単一行レポートでは、インストゥルメントされた操作の合計数は次のとおりです: 

    10 + (10 * 20) + (10 * 20 * 30) = 6210

    インスツルメント処理される操作の数は、スキャンごと (つまり、t1 と t2 の行の一意の組合せごと) に集計することで大幅に削減できます。 バッチ I/O レポートでは、パフォーマンススキーマは各行ではなくもっとも内側のテーブル t3 のスキャンごとにイベントを生成し、計測される行操作の数は次のように減少します: 

    10 + (10 * 20) + (10 * 20) = 410

    これは 93% の削減であり、レポートコールの数を減らすことで、バッチレポート戦略によってテーブル I/O のパフォーマンススキーマのオーバーヘッドが大幅に削減される方法を示しています。 トレードオフは、イベントタイミングの精度が低くなります。 バッチ I/O のタイミングには、行ごとのレポートのように個々の行操作の時間ではなく、結合バッファリング、集計、クライアントへの行の戻しなどの操作に費やされる時間が含まれます。

    バッチ I/O レポートを実行するには、次の条件が満たされている必要があります:

    • クエリー実行は、クエリーブロックの最も内側のテーブルにアクセスします (単一テーブルクエリーの場合、そのテーブルは最も内側としてカウントされます)

    • クエリーの実行では、テーブルの単一行は要求されません (たとえば、eq_ref アクセスではバッチレポートを使用できません)

    • クエリーの実行では、テーブルに対するテーブルアクセスを含むサブクエリーは評価されません

  • FLAGS

    将来使用するために予約されています。

events_waits_current テーブルには次のインデックスがあります:

  • 主キー (THREAD_ID、EVENT_ID)

TRUNCATE TABLE は events_waits_current テーブルに対して許可されています。 行が削除されます。


関連キーワード: 　テーブル, イベント, パフォーマンス, スキーマ, events, OBJECT, 待機, waits, TIMER, オブジェクト
PREV   HOME   UP   NEXT