重要

古いバージョンの TiDB データベース (TiDB {{ curdocVersion }}) のドキュメントを表示しています。

TiDBデータベースの最新の安定バージョンを使用することをお勧めします。
重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

DATA_LOCK_WAITS

DATA_LOCK_WAITSの表は、クラスタのすべてのTiKVノードで待機している進行中の悲観的ロックを示しています。

USE information_schema;
DESC data_lock_waits;
+------------------------+---------------------+------+------+---------+-------+
| Field                  | Type                | Null | Key  | Default | Extra |
+------------------------+---------------------+------+------+---------+-------+
| KEY                    | text                | NO   |      | NULL    |       |
| KEY_INFO               | text                | YES  |      | NULL    |       |
| TRX_ID                 | bigint(21) unsigned | NO   |      | NULL    |       |
| CURRENT_HOLDING_TRX_ID | bigint(21) unsigned | NO   |      | NULL    |       |
| SQL_DIGEST             | varchar(64)         | YES  |      | NULL    |       |
| SQL_DIGEST_TEXT        | text                | YES  |      | NULL    |       |
+------------------------+---------------------+------+------+---------+-------+

DATA_LOCK_WAITSテーブルの各列フィールドの意味は次のとおりです。

  • KEY :ロックを待機している16進形式のキー。
  • KEY_INFOKEYの詳細情報。 KEY_INFOのセクションを参照してください。
  • TRX_ID :ロックを待機しているトランザクションのID。このIDはトランザクションのstart_tsでもあります。
  • CURRENT_HOLDING_TRX_ID :現在ロックを保持しているトランザクションのID。このIDはトランザクションのstart_tsでもあります。
  • SQL_DIGEST :ロック待機トランザクションで現在ブロックされているSQLステートメントのダイジェスト。
  • SQL_DIGEST_TEXT :ロック待機トランザクションで現在ブロックされている正規化されたSQLステートメント(引数と形式のないSQLステートメント)。 SQL_DIGESTに対応します。
警告
  • このテーブルをクエリできるのは、 処理するの特権を持つユーザーのみです。
  • 現在、テーブルは悲観的なロック待機情報のみを記録できます。楽観的トランザクション(自動コミットトランザクションなど)がペシミスティックロックによってブロックされている場合、このテーブルには対応するロック待機情報は表示されません。
  • DATA_LOCK_WAITSテーブルの情報は、クエリ中にすべてのTiKVノードからリアルタイムで取得されます。現在、クエリにWHEREの条件がある場合でも、情報収集はすべてのTiKVノードで実行されます。クラスタが大きく、負荷が高い場合、このテーブルをクエリすると、パフォーマンスジッターの潜在的なリスクが発生する可能性があります。したがって、実際の状況に応じて使用してください。
  • 異なるTiKVノードからの情報は、同時にスナップショットであるとは限りません。
  • SQL_DIGEST列の情報(SQLダイジェスト)は、正規化されたSQLステートメントから計算されたハッシュ値です。 SQL_DIGEST_TEXT列の情報は、ステートメントの要約テーブルから内部的に照会されるため、対応するステートメントが内部で見つからない可能性があります。 SQLダイジェストとステートメントの要約テーブルの詳細については、 ステートメント要約表を参照してください。

KEY_INFO

KEY_INFO列は、 KEY列の詳細情報を示しています。情報はJSON形式で表示されます。各フィールドの説明は次のとおりです。

  • "db_id" :キーが属するスキーマのID。
  • "db_name" :キーが属するスキーマの名前。
  • "table_id" :キーが属するテーブルのID。
  • "table_name" :キーが属するテーブルの名前。
  • "partition_id" :キーが配置されているパーティションのID。
  • "partition_name" :キーが配置されているパーティションの名前。
  • "handle_type" :行キー(つまり、データの行を格納するキー)のハンドルタイプ。可能な値は次のとおりです:
    • "int" :ハンドルタイプはintです。これは、ハンドルが行IDであることを意味します。
    • "common" :ハンドルタイプはint64ではありません。このタイプは、クラスター化インデックスが有効になっている場合、非int主キーに表示されます。
    • "unknown" :ハンドルタイプは現在サポートされていません。
  • "handle_value" :ハンドル値。
  • "index_id" :インデックスキー(インデックスを格納するキー)が属するインデックスID。
  • "index_name" :インデックスキーが属するインデックスの名前。
  • "index_values" :インデックスキーのインデックス値。

上記のフィールドで、フィールドの情報が適用できないか、現在利用できない場合、そのフィールドはクエリ結果で省略されます。たとえば、行キー情報にはindex_id 、およびindex_nameは含まれてindex_valuesません。インデックスキーにはhandle_typehandle_valueが含まれていません。パーティション化されていないテーブルはpartition_idpartition_nameを表示しません。削除されたテーブルのdb_name情報は、 table_nameなどのdb_id情報を取得できず、テーブルがindex_nameテーブルであるかどうかを区別できません。

ノート:

キーがパーティション化が有効になっているテーブルからのものであり、クエリ中に何らかの理由(たとえば、キーが属するテーブルが削除された)のために、キーが属するスキーマの情報をクエリできない場合、IDキーが属するパーティションのtable_idフィールドに表示される場合があります。これは、TiDBが複数の独立したテーブルのキーをエンコードするのと同じ方法で、異なるパーティションのキーをエンコードするためです。したがって、スキーマ情報が欠落している場合、TiDBは、キーがパーティション化されていないテーブルに属しているのか、テーブルの1つのパーティションに属しているのかを確認できません。

select * from information_schema.data_lock_waits\G
*************************** 1. row ***************************
                   KEY: 7480000000000000355F728000000000000001
              KEY_INFO: {"db_id":1,"db_name":"test","table_id":53,"table_name":"t","handle_type":"int","handle_value":"1"}
                TRX_ID: 426790594290122753
CURRENT_HOLDING_TRX_ID: 426790590082449409
            SQL_DIGEST: 38b03afa5debbdf0326a014dbe5012a62c51957f1982b3093e748460f8b00821
       SQL_DIGEST_TEXT: update `t` set `v` = `v` + ? where `id` = ?
1 row in set (0.01 sec)

上記のクエリ結果は、ID 426790594290122753のトランザクションが、ダイジェスト"38b03afa5debbdf0326a014dbe5012a62c51957f1982b3093e748460f8b00821"を持ち、 update `t` set `v` = `v` + ? where `id` = ?の形式のステートメントを実行するときに、キー"7480000000000000355F728000000000000001"の悲観的なロックを取得しようとしているが、このキーのロックはトランザクションによって保持されていることを示しています。 426790590082449409の。

このページの内容