Skip to content

Commit 4ba536e

Browse files
authored
Update doc for DATA_LOCK_WAITS (pingcap#9533)
1 parent 1e9e0a0 commit 4ba536e

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

information-schema/information-schema-data-lock-waits.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ summary: Learn the `DATA_LOCK_WAITS` information_schema table.
55

66
# DATA_LOCK_WAITS
77

8-
The `DATA_LOCK_WAITS` table shows the ongoing pessimistic locks waiting on all TiKV nodes in the cluster.
8+
The `DATA_LOCK_WAITS` table shows the ongoing lock-wait information on all TiKV nodes in a cluster, including the lock-wait information of pessimistic transactions and the information of optimistic transactions being blocked.
99

1010
{{< copyable "sql" >}}
1111

@@ -39,7 +39,7 @@ The meaning of each column field in the `DATA_LOCK_WAITS` table is as follows:
3939
> **Warning:**
4040
>
4141
> * Only the users with the [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process) privilege can query this table.
42-
> * Currently, the table can only record the **pessimistic lock waiting** information. If an optimistic transaction (such as an autocommit transaction) is blocked by a pessimistic lock, this table will not display the corresponding lock waiting information.
42+
> * Currently, the `SQL_DIGEST` and `SQL_DIGEST_TEXT` fields are `null` (which means unavailable) for optimistic transactions. As a workaround, to find out the SQL statement that causes the blocking, you can join this table with [`CLUSTER_TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) to get all the SQL statements of the optimistic transaction.
4343
> * The information in the `DATA_LOCK_WAITS` table is obtained in real time from all TiKV nodes during the query. Currently, even if a query has the `WHERE` condition, the information collection is still performed on all TiKV nodes. If your cluster is large and the load is high, querying this table might cause potential risk of performance jitter. Therefore, use it according to your actual situation.
4444
> * Information from different TiKV nodes is NOT guaranteed to be snapshots of the same time.
4545
> * The information (SQL digest) in the `SQL_DIGEST` column is the hash value calculated from the normalized SQL statement. The information in the `SQL_DIGEST_TEXT` column is internally queried from statements summary tables, so it is possible that the corresponding statement cannot be found internally. For the detailed description of SQL digests and the statements summary tables, see [Statement Summary Tables](/statement-summary-tables.md).

0 commit comments

Comments
 (0)