データロック待機
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の詳細情報。4 キー情報セクションを参照してください。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が表示されず、削除されたテーブルのキー情報ではtable_name 、 db_id 、 db_name 、 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"の悲観的ロックを取得しようとしているが、このキーのロックは ID 426790590082449409のトランザクションによって保持されていることを示しています。