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_INFO：KEYの詳細情報。 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に対応します。
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_typeとhandle_valueが含まれていません。パーティション化されていないテーブルはpartition_idとpartition_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の。