tencent cloud

TDSQL Boundless

Release Notes
Product Introduction
Overview
Scenarios
Product Architecture
Instance Types
Compatibility Notes
Kernel Features
Kernel Overview
Kernel Version Release Notes
Functionality Features
Performance Features
Billing
Billing Overview
Purchase Method
Pricing Details
Renewal
Overdue Payments
Refund
Getting Started
Creating an Instance
Connect to Instances
User Guide
Data Migration
Data Subscription
Instance Management
Configuration Change
Parameter Configuration
Account Management
Security Group
Backup and Restoration
Database Auditing
Tag Management
Use Cases
Technical Evolution and Usage Practices of Online DDL
Lock Mechanism Analysis and Troubleshooting Practices
Data Intelligent Scheduling and Related Practices for Performance Optimization
TDSQL Boundless Selection Guide and Practical Tutorial
Developer Guide
Developer Guide (MySQL Compatibility Mode)
Developer Guide (HBase Compatibility Mode)
Performance Tuning
Performance Tuning Overview
SQL Tuning
DDL Tuning
Performance White Paper
Performance Overview
TPC-C Test
Sysbench Test
API Documentation
History
Introduction
API Category
Making API Requests
Instance APIs
Security Group APIs
Task APIs
Backup APIs
Rollback APIs
Parameter APIs
Database APIs
Data Types
Error Codes
General Reference
System Architecture
SQL Reference
Database Parameter Description
TPC-H benchmark data model reference
Error Code Information
Security and Compliance
FAQs
Agreements
Service Level Agreement
Terms of Service
Privacy Policy
Data Processing And Security Agreement
Contact Us
Glossary

DATA_LOCKS

PDF
포커스 모드
폰트 크기
마지막 업데이트 시간: 2026-03-26 14:35:17

Feature

PERFORMANCE_SCHEMA.DATA_LOCKS is used to display information about all successfully locked pessimistic locks on the TDStore of all hybrid nodes in the cluster.
When users do not query the DATA_LOCKS table, DATA_LOCKS does not incur additional overhead. Users do not need to set the performance_schema system variable to ON to query the DATA_LOCKS table.

Field Description

Field Name
Type
Description
ENGINE
varchar(32)
Indicates the storage engine. For TDStore, it is RocksDB.
ENGINE_LOCK_ID
varchar(128)
Indicates the unique identifier of a pessimistic lock. For TDStore, its format is <ID of the transaction holding the lock>_<lock scope>. The format of <lock scope> is:
If the lock scope is a single key, then lock scope is the hexadecimal representation of the key. For example: the lock identifier 28673778183569468_00002797 indicates that the transaction with ID 28673778183569468 has placed a pessimistic lock on the key with hexadecimal code 00002797 .
If the lock scope is a key range, then <lock scope> is formatted as [<hex_start_key>,<hex_end_key>) (left-closed and right-open) or (<hex_start_key>,<hex_end_key>) (open interval). For example: the lock identifier 28673778183569468_[00002797,00002798) indicates that the transaction with ID 28673778183569468 has placed a pessimistic lock on the range [00002797,00002798) .
When the hexadecimal code of a key is too long, it may not be fully represented within 128 characters. In such cases, the last two characters of the field value will be set to .., indicating that this is not a complete lock identifier. In this situation, when users query information about pessimistic locks through ENGINE_LOCK_ID, they also need to use field values containing .. for the query.
ENGINE_TRANSACTION_ID
bigint unsigned
Indicates the unique identifier of the transaction holding the pessimistic lock. If the pessimistic lock is a read lock held by multiple transactions, only the unique identifier of one transaction will be displayed.
THREAD_ID
bigint unsigned
The internal thread ID of Performance Schema, which is unique throughout the lifecycle of Performance Schema, can be used to reliably correlate various event tables in Performance Schema.
EVENT_ID
bigint unsigned
Indicates the ID of the Performance Schema event that caused the lock. For TDStore, it is NULL.
OBJECT_SCHEMA
varchar(64)
Indicates the database name corresponding to the pessimistic lock.
OBJECT_NAME
varchar(64)
Indicates the table name corresponding to the pessimistic lock.
PARTITION_NAME
varchar(64)
Indicates the partition name corresponding to the pessimistic lock. For TDStore, it is NULL.
SUBPARTITION_NAME
varchar(64)
Indicates the sub-partition name corresponding to the pessimistic lock. For TDStore, it is NULL.
INDEX_NAME
varchar(64)
Indicates the index name corresponding to the pessimistic lock. For TDStore, it is NULL.
OBJECT_INSTANCE_BEGIN
bigint unsigned
Indicates the address of the pessimistic lock in memory.
LOCK_TYPE
varchar(32)
Indicates the types of pessimistic locks. For TDStore, the KEY value represents locking a single key and the PRE_RANGE value represents locking a key interval.
LOCK_MODE
varchar(32)
Indicates the read-write mode of the pessimistic lock. For TDStore, the Write value represents adding a write lock and the Read value represents adding a read lock.
LOCK_STATUS
varchar(32)
Indicates the status of the pessimistic lock. For TDStore, the value is GRANTED, indicating a successful lock. Locks being added are not displayed in the data_locks table. This information can be obtained by querying the data_lock_waits table.
LOCK_DATA
varchar(8192)
Indicates additional information, with values determined by each storage engine. For TDStore, the value is NULL.
START_KEY
varchar(128)
For locks on a single key, the value is NULL. For locks on a key interval, the value represents the hexadecimal code of the left boundary of the key interval.
END_KEY
varchar(128)
For locks on a single key, the value represents the hexadecimal code of the key. For locks on a key interval, the value represents the hexadecimal code of the right boundary of the key interval.
EXCLUDE_START_KEY
tinyint(1)
The value is 1 if and only if the scope of the pessimistic lock is a key interval and the interval is open; otherwise, the value is 0.
BLOCKING_TRANSACTION_NUM
bigint unsigned
Indicates the number of transactions waiting to be locked on this pessimistic lock.
BLOCKING_CHECK_READ_TRANSACTION_NUM
bigint unsigned
Indicates the number of transactions waiting for a snapshot read on this pessimistic lock. When a transaction holding a pessimistic lock enters the submission process, the pessimistic lock will block requests for snapshot reads.
READ_LOCKED_NUM
bigint unsigned
Indicates the number of read locks on this pessimistic lock.
TINDEX_ID
int unsigned
Indicates the tindex ID corresponding to the pessimistic lock. With the value of this field, we can execute SELECT * FROM information_schema.statistics WHERE tindex_id=... to obtain the table information corresponding to the tindex ID from the system table.
DATA_SPACE_TYPE
varchar(32)
Indicates the data space corresponding to the pessimistic lock. The DATA_SPACE_TYPE_USER value represents locking part of the data in user tables. The DATA_SPACE_TYPE_SYSTEM value represents locking part of the data in system tables.
REPLICATION_GROUP_ID
bigint unsigned
Indicates the replication group ID corresponding to the pessimistic lock.
KEY_RANGE_REGION_ID
bigint unsigned
Indicates the ID of the key range region corresponding to the pessimistic lock.
PROCESSLIST_ID
bigint unsigned
Indicates the ID of the session connection (session) that initiated the transaction.
NODE_ID
bigint unsigned
Indicates the ID of the SQLEngine node that initiated the transaction.
NODE_NAME
varchar(64)
Indicates the name of the SQLEngine node that initiated the transaction.
Note:
TDSQL Boundless does not currently support directly displaying information such as database names and table names in the data_locks table. If you need to view table information, you can directly query the information_schema.statistics table based on the value of the TINDEX_ID field.

Examples

Output example:
tdsql [(none)]> SELECT * FROM performance_schema.data_locks \\G
*************************** 1. row ***************************
ENGINE: RocksDB
ENGINE_LOCK_ID: 28681376014270466_(0000279780000006,00002798)
ENGINE_TRANSACTION_ID: 28681376014270466
THREAD_ID: 44
EVENT_ID: NULL
OBJECT_SCHEMA: testdb
OBJECT_NAME: test
PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
INDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 140502282795216
LOCK_TYPE: PRE_RANGE
LOCK_MODE: Write
LOCK_STATUS: GRANTED
LOCK_DATA: NULL
START_KEY: 0000279780000006
END_KEY: 00002798
EXCLUDE_START_KEY: 1
BLOCKING_TRANSACTION_NUM: 0
BLOCKING_CHECK_READ_TRANSACTION_NUM: 0
READ_LOCKED_NUM: 0
TINDEX_ID: 10135
DATA_SPACE_TYPE: DATA_SPACE_TYPE_USER
REPLICATION_GROUP_ID: 257
KEY_RANGE_REGION_ID: 7312
PROCESSLIST_ID: 2097282
NODE_ID: 2
NODE_NAME: node-1-002
*************************** 2. row ***************************
ENGINE: RocksDB
ENGINE_LOCK_ID: 28681376014270466_0000279780000006
ENGINE_TRANSACTION_ID: 28681376014270466
THREAD_ID: 44
EVENT_ID: NULL
OBJECT_SCHEMA: testdb
OBJECT_NAME: test
PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
INDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 140507882943448
LOCK_TYPE: KEY
LOCK_MODE: Write
LOCK_STATUS: GRANTED
LOCK_DATA: NULL
START_KEY: NULL
END_KEY: 0000279780000006
EXCLUDE_START_KEY: 0
BLOCKING_TRANSACTION_NUM: 0
BLOCKING_CHECK_READ_TRANSACTION_NUM: 0
READ_LOCKED_NUM: 0
TINDEX_ID: 10135
DATA_SPACE_TYPE: DATA_SPACE_TYPE_USER
REPLICATION_GROUP_ID: 257
KEY_RANGE_REGION_ID: 7312
PROCESSLIST_ID: 1048704
NODE_ID: 1
NODE_NAME: node-1-001
Query Example:
-- Query the number of pessimistic locks on all nodes
SELECT COUNT(*) FROM performance_schema.data_locks \\G

-- Query all pessimistic lock information for key range region 7312 in replication group 257 across all nodes (querying by specifying only key_range_region_id is possible, though inefficient as it cannot leverage indexes to accelerate the query)
SELECT * FROM performance_schema.data_locks WHERE replication_group_id = 257 AND key_range_region_id = 7312 \\G

-- Query all pessimistic locks on all nodes that intersect with [0000279780000003, 0000279780000004].
SET @left = "0000279780000003";
SET @right = "0000279780000004";
SELECT * FROM performance_schema.data_locks WHERE
(lock_type = 'KEY' AND @left <= end_key AND end_key <= @right) OR -- If it is a pessimistic lock on a single key, the corresponding key is stored in the end_key field; it is considered valid as long as end_key falls within the interval
(lock_type = 'PRE_RANGE' AND @left < end_key AND (start_key < @right OR (NOT exclude_start_key and start_key = @right))) \\G -- If it is a pessimistic lock on a key interval, you need to judge whether [start_key, end_key) or (start_key, end_key) intersects with the interval based on exclude_start_key.

-- Query information about all pessimistic locks on the testdb.test table across all nodes.
-- First step: Obtain the tindex_id of testdb.test.
SELECT tindex_id FROM information_schema.statistics WHERE table_schema = 'testdb' AND table_name = 'test';
-- Second step: Use the tindex_id obtained in the first step to query lock information.
SELECT * FROM performance_schema.data_locks WHERE tindex_id = 12345;

-- Or directly use tableName databaseName to query the relevant pessimistic lock information
SELECT * FROM performance_schema.data_locks WHERE OBJECT_SCHEMA = 'testdb' AND OBJECT_NAME = 'test';

-- Query information about all pessimistic locks held by transaction 28681535313936395 on all nodes.
SELECT * FROM performance_schema.data_locks WHERE engine_transaction_id = 28681535313936395 \\G

-- Query information about all pessimistic locks on all nodes that are blocking transactions.
SELECT * FROM performance_schema.data_locks WHERE blocking_transaction_num > 0 OR blocking_check_read_transaction_num > 0
Display information about blocked participants:
Three concurrently executed sessions are displayed below. In this example, the query statements of session B and session C will be blocked by the range pessimistic lock imposed by session A on table t.
session A:
BEGIN;
SELECT a FROM t FOR UPDATE;
SELECT SLEEP(100);
session B:
SELECT b FROM t FOR UPDATE;
session C:
SELECT c FROM t FOR UPDATE;
At this moment, use the following query statements to check which transactions are waiting and which transactions are blocking them.
SELECT blocking_engine_transaction_id, blocking_engine_lock_id, requesting_engine_transaction_id, requesting_engine_lock_id, tindex_id, replication_group_id, key_range_region_id FROM performance_schema.data_lock_waits \\G
The results are as follows:
blocking_engine_transaction_id
blocking_engine_lock_id
requesting_engine_transaction_id
requesting_engine_lock_id
tindex_id
replication_group_id
key_range_region_id
28687218495193155
28687218495193155_[00002819,0000281A)
28687218897846327
28687218897846327_[00002819,0000281A)
10265
257
103181
28687218495193155
28687218495193155_[00002819,0000281A)
28687218746851349
28687218746851349_[00002819,0000281A)
10265
257
103181

도움말 및 지원

문제 해결에 도움이 되었나요?

피드백