Update documents of lock view for sprint 4 #6824

MyonKeminta · 2021-08-06T08:06:20Z

First-time contributors' checklist

I've signed Contributor License Agreement that's required for repo owners to accept my contribution.

What is changed, added or deleted? (Required)

The feature Lock View has changed much in this sprint. Update documents for it.

Which TiDB version(s) do your changes apply to? (Required)

Tips for choosing the affected version(s):

By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.

For details, see tips for choosing the affected versions (in Chinese).

What is the related PR or file link(s)?

This PR is translated from:
Other reference link(s):

Do your changes match any of the following descriptions?

Delete files
Change aliases
Need modification after applied to another branch
Might cause conflicts after applied to another branch

ti-chi-bot · 2021-08-06T08:06:21Z

[REVIEW NOTIFICATION]

This pull request has been approved by:

TomShawn
qiancai

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

TomShawn · 2021-08-06T08:13:52Z

@MyonKeminta Please involve a technical review.

MyonKeminta · 2021-08-06T11:08:14Z

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

+    * `"int"`：handle 为 int 类型，即 handle 为 row id；
+    * `"common"`：非 int64 类型的 handle，在启用 clustered index 时非 int 类型的主键会显示为此类型；
+    * `"unknown"`：当前暂不支持的 handle 类型。
+* `"partition_handle"`：是否为 partition handle。


Here's some misunderstanding of mine about the partition_handle field. I'll fix it next week.

qiancai · 2021-08-09T05:51:41Z

functions-and-operators/tidb-functions.md

+1 row in set (0.01 sec)
+```
+
+上述调用指定了第二个参数（即阶段长度）为 10，而查询结果中的第三条语句的长度大于 10，因而仅保留了前 10 个字符，并在尾部添加了 `"..."` 表示发生了截断。


Suggested change

上述调用指定了第二个参数（即阶段长度）为 10，而查询结果中的第三条语句的长度大于 10，因而仅保留了前 10 个字符，并在尾部添加了 `"..."` 表示发生了截断。

上述调用指定了第二个参数（即截断长度）为 10，而查询结果中的第三条语句的长度大于 10，因而仅保留了前 10 个字符，并在尾部添加了 `"..."` 表示发生了截断。

qiancai

@MyonKeminta PTAL

qiancai · 2021-08-09T06:01:43Z

functions-and-operators/tidb-functions.md

+> **注意：**
+>
+> * 仅持有 [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process) 权限的用户可以使用该函数。
+> * `TIDB_DECODE_SQL_DIGESTS` 执行时，内部从 Statement Summary 一系列表中查询每个 SQL Digest 所对应的语句，因而并不能保证对任意 SQL Digest 都总是能查询到对应的语句，只有在集群中执行过的语句才有可能被查询到，且是否能查询到受 Statement Summary 表相关配置的影响。有关 Statement Summary 表的详细说明，参见 [Statement Summary Tables](/statement-summary-tables.md)。


“内部从 Statement Summary 一系列表中查询每个 SQL Digest 所对应的语句”，请问这里的 “内部” 是 TiDB 内部，还是什么的内部呢？

TiDB 内部。我改一下

qiancai · 2021-08-09T06:36:42Z

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

+    * `"int"`：handle 为 int 类型，即 handle 为 row id；
+    * `"common"`：非 int64 类型的 handle，在启用 clustered index 时非 int 类型的主键会显示为此类型；
+    * `"unknown"`：当前暂不支持的 handle 类型。


Suggested change

* `"int"`：handle 为 int 类型，即 handle 为 row id；

* `"common"`：非 int64 类型的 handle，在启用 clustered index 时非 int 类型的主键会显示为此类型；

* `"unknown"`：当前暂不支持的 handle 类型。

* `"int"`：handle 为 int 类型，即 handle 为 row id

* `"common"`：非 int64 类型的 handle，在启用 clustered index 时非 int 类型的主键会显示为此类型

* `"unknown"`：当前暂不支持的 handle 类型

qiancai · 2021-08-09T06:40:44Z

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

+* `"index_name"`：该 index key 所属的 index 名称。
+* `"index_values"`：该 index key 中的 index value。
+
+其中，不适用或当前无法查询到的信息会被省略。比如，row key 的信息中不会包含 `index_id`、`index_name` 和 `index_values`，index key 不会包含 `handle_type` 和 `partition_handle`，已经被 drop 掉的表中的 key 的信息可能只有 `table_id` 等几个 ID。


请问 “已经被 drop 掉的表中的 key 的信息可能只有 table_id 等几个 ID” 这里是指 "db_id" 、"table_id"、index_id" 吗？

没有 db_id。这个地方我想了下更确切地说应该是“无法从 schema 信息，因而不会包含 table_name，db_id，db_name，index_name 等字段，且无法区分 key 是否属于分区表“

qiancai · 2021-08-09T06:44:38Z

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

+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 为 `425405024158875649` 的事务在执行 Digest 为 `"f7530877a35ae65300c42250abd8bc731bbaf0a7cabc05dab843565230611bb22"` 的语句的过程中，试图在 `"7480000000000000355f728000000000000002"` 这个 key 上获取悲观锁，但是该 key 上的锁目前被 ID 为 `425405016242126849` 的事务持有。


这里可否也请说明下示例中的SQL_DIGEST 和 SQL_DIGEST_TEXT 信息呢？可以帮助用户理解这个示例

@MyonKeminta PTAL

qiancai · 2021-08-09T06:57:34Z

troubleshoot-lock-conflicts.md

 >
-> 该功能目前为实验性功能，相关表结构的定义和行为在未来版本可能有较大改动。
+> Lock View 相关的表中展示的 SQL 语句均为归一化的 SQL 语句（即去除了格式和参数的形式），由 SQL Digest 内部查询获得，因而无法获取包括格式和参数在内的完整语句。有关 SQL Digest 和归一化 SQL 语句的详细介绍详见 [Statement Summary Tables](/statement-summary-tables.md)


Suggested change

> Lock View 相关的表中展示的 SQL 语句均为归一化的 SQL 语句（即去除了格式和参数的形式），由 SQL Digest 内部查询获得，因而无法获取包括格式和参数在内的完整语句。有关 SQL Digest 和归一化 SQL 语句的详细介绍详见 [Statement Summary Tables](/statement-summary-tables.md)

> Lock View 相关的系统表中展示的 SQL 语句为归一化的 SQL 语句（即去除了格式和参数的形式的 SQL 语句），由 SQL Digest 内部查询获得，因而无法获取包括格式和参数在内的完整语句。有关 SQL Digest 和归一化 SQL 语句的详细介绍，请参阅 [Statement Summary Tables](/statement-summary-tables.md)。

qiancai · 2021-08-09T07:02:36Z

troubleshoot-lock-conflicts.md

-|           1 | 2021-06-04 08:22:38.765699 | 425405959304904708 | 425405959304904707 | update `t` set `v` = ? where `id` = ? ; |
-+-------------+----------------------------+--------------------+--------------------+-----------------------------------------+
-```
+查询结果会显示死锁错误中多个事务之间的等待关系和各个事务当前正在执行的 SQL 语句的归一化形式（即去掉参数和格式的形式），以及发生冲突的 key 及其从 key 中解读出的一些信息。


这里可能有些简略，是否可以再详细说明下呢？比如告诉用户从 CURRENT_SQL_DIGEST_TEXT 列可以获取各个事务当前正在执行的 SQL 语句的归一化形式（即去掉参数和格式的形式）

@MyonKeminta PTAL

这个下面补充了一段说明

qiancai · 2021-08-09T07:04:39Z

troubleshoot-lock-conflicts.md

 1 row in set (0.01 sec)
 ```

+上述查询中，对 `CLUSTER_TIDB_TRX` 表的 `ALL_SQL_DIGESTS` 列使用了 [`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests) 函数，以尝试将该列（内容为一组 SQL Digest）转换为其对应的 SQL 语句，以便于阅读。


“以尝试将该列（内容为一组 SQL Digest）转换为其对应的 SQL 语句“，这里请问是“转换为其对应的 SQL 语句的归一化形式”吗？

cfzjywxk · 2021-08-09T07:17:48Z

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

+
+* `"db_id"`：该 key 所属的数据库（schema）的 ID。
+* `"db_name"`：该 key 所属的数据库（schema）的名称。
+* `"table_id"`：该 key 所属的表的 ID。


May need to explain if it's a partitioned table, if it's the partition table id or the real physical table id

functions-and-operators/tidb-functions.md

cfzjywxk · 2021-08-09T07:19:32Z

functions-and-operators/tidb-functions.md

+>
+> * 仅持有 [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process) 权限的用户可以使用该函数。
+> * `TIDB_DECODE_SQL_DIGESTS` 执行时，内部从 Statement Summary 一系列表中查询每个 SQL Digest 所对应的语句，因而并不能保证对任意 SQL Digest 都总是能查询到对应的语句，只有在集群中执行过的语句才有可能被查询到，且是否能查询到受 Statement Summary 表相关配置的影响。有关 Statement Summary 表的详细说明，参见 [Statement Summary Tables](/statement-summary-tables.md)。
+> 该函数开销较大，在行数很多的查询中（比如在规模较大、比较繁忙的集群上查询 `information_schema.cluster_tidb_trx` 全表时）直接使用该函数可能导致查询运行时间较长。请谨慎使用。


May need to explain more about the impact and the underlying mechanism.

MyonKeminta · 2021-08-11T04:53:16Z

@cfzjywxk @qiancai PTAL again, thanks

qiancai · 2021-08-11T04:59:47Z

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

+* `"index_name"`：该 index key 所属的 index 名称。
+* `"index_values"`：该 index key 中的 index value。
+
+其中，不适用或当前无法查询到的信息会被省略。比如，row key 的信息中不会包含 `index_id`、`index_name` 和 `index_values`；index key 不会包含 `handle_type` 和 `handle_value`；已经被 drop 掉的表中的 key 的信息无法获取 `table_name`、`db_id`、`db_name`、`index_name` 等 schema 信息，且无法区分是否为分区表等。


“且无法区分是否为分区表等” 这里的 “等” 可以删除吗，或者请具体说下是哪些情况。

qiancai · 2021-08-11T05:01:01Z

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

+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 为 `425405024158875649` 的事务在执行 Digest 为 `"f7530877a35ae65300c42250abd8bc731bbaf0a7cabc05dab843565230611bb22"` 的语句的过程中，试图在 `"7480000000000000355f728000000000000002"` 这个 key 上获取悲观锁，但是该 key 上的锁目前被 ID 为 `425405016242126849` 的事务持有。


@MyonKeminta PTAL

cfzjywxk

/lgtm

ti-chi-bot · 2021-08-11T08:49:56Z

@cfzjywxk: Thanks for your review. The bot only counts approvals from reviewers and higher roles in list, but you're still welcome to leave your comments.

In response to this:

/lgtm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.

TomShawn · 2021-08-12T07:38:06Z

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

@@ -7,10 +7,6 @@ summary: 了解 information_schema 表 `DATA_LOCK_WAITS`。

 `DATA_LOCK_WAITS` 表展示了集群中所有 TiKV 节点上当前正在发生的悲观锁等锁的情况。

-> **警告：**
->
-> 该功能目前为实验性功能，表结构的定义和行为在未来版本中可能有较大改动。


这张系统表在 v5.1 中仍为实验功能吗？

TomShawn · 2021-08-12T07:40:27Z

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

+> * 仅拥有 [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process) 权限的用户可以查询该表。
+> * `DATA_LOCK_WAITS` 表中的信息是在查询时，从所有 TiKV 节点实时获取的。目前，即使加上了 `WHERE` 查询条件，也无法避免对所有 TiKV 节点都进行信息收集。如果集群规模很大、负载很高，查询该表有造成性能抖动的潜在风险，因此请根据实际情况使用。
+> * 来自不同 TiKV 节点的信息不能保证是同一时间点的快照。
+> * `SQL_DIGEST` 列中的信息（SQL Digest）为 SQL 语句进行归一化后计算得到的 hash。`SQL_DIGEST_TEXT` 列中的信息为内部从 Statements Summary 系列表中查询得到，因而存在内部查询不到对应语句的可能性。关于 SQL Digest 和 Statements Summary 相关表的详细说明，请参阅[Statement Summary Tables](/statement-summary-tables.md)。


Suggested change

> * `SQL_DIGEST` 列中的信息（SQL Digest）为 SQL 语句进行归一化后计算得到的 hash。`SQL_DIGEST_TEXT` 列中的信息为内部从 Statements Summary 系列表中查询得到，因而存在内部查询不到对应语句的可能性。关于 SQL Digest 和 Statements Summary 相关表的详细说明，请参阅[Statement Summary Tables](/statement-summary-tables.md)。

> * `SQL_DIGEST` 列中的信息（SQL Digest）为 SQL 语句进行归一化后计算得到的哈希值。`SQL_DIGEST_TEXT` 列中的信息为内部从 Statements Summary 系列表中查询得到，因而存在内部查询不到对应语句的可能性。关于 SQL Digest 和 Statements Summary 相关表的详细说明，请参阅[Statement Summary Tables](/statement-summary-tables.md)。

TomShawn · 2021-08-12T07:42:35Z

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

+* `"db_name"`：该 key 所属的数据库（schema）的名称。
+* `"table_id"`：该 key 所属的表的 ID。
+* `"table_name"`：该 key 所属的表的名称。
+* `"partition_id"`：该 key 所在的 partition 的 ID。


partition --> 分区

TomShawn · 2021-08-12T07:43:58Z

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

+* `"table_name"`：该 key 所属的表的名称。
+* `"partition_id"`：该 key 所在的 partition 的 ID。
+* `"partition_name"`：该 key 所在的 partition 的名称。
+* `"handle_type"`：该 row key 的 handle 类型，其可能的值有：


如果 row key 不为专有名词，仅为自然语言，请使用中文“行键”

TomShawn · 2021-08-12T07:45:30Z

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

+* `"index_name"`：该 index key 所属的 index 名称。
+* `"index_values"`：该 index key 中的 index value。
+
+其中，不适用或当前无法查询到的信息会被省略。比如，row key 的信息中不会包含 `index_id`、`index_name` 和 `index_values`；index key 不会包含 `handle_type` 和 `handle_value`；非分区表不会显示 `partition_id` 和 `partition_name`；已经被 drop 掉的表中的 key 的信息无法获取 `table_name`、`db_id`、`db_name`、`index_name` 等 schema 信息，且无法区分是否为分区表。


Suggested change

其中，不适用或当前无法查询到的信息会被省略。比如，row key 的信息中不会包含 `index_id`、`index_name` 和 `index_values`；index key 不会包含 `handle_type` 和 `handle_value`；非分区表不会显示 `partition_id` 和 `partition_name`；已经被 drop 掉的表中的 key 的信息无法获取 `table_name`、`db_id`、`db_name`、`index_name` 等 schema 信息，且无法区分是否为分区表。

其中，不适用或当前无法查询到的信息会被省略。比如，row key 的信息中不会包含 `index_id`、`index_name` 和 `index_values`；index key 不会包含 `handle_type` 和 `handle_value`；非分区表不会显示 `partition_id` 和 `partition_name`；已经被删除的表中的 key 的信息无法获取 `table_name`、`db_id`、`db_name`、`index_name` 等 schema 信息，且无法区分是否为分区表。

TomShawn · 2021-08-12T07:49:31Z

information-schema/information-schema-deadlocks.md

 * `KEY`：该事务试图上锁、但是被阻塞的 key，以十六进制编码的形式显示。
+* `KEY_INFO`：对 `KEY` 进行解读得出的一些详细信息，详见 [KEY_INFO](#key_info)。。


Suggested change

* `KEY_INFO`：对 `KEY` 进行解读得出的一些详细信息，详见 [KEY_INFO](#key_info)。。

* `KEY_INFO`：对 `KEY` 进行解读得出的详细信息，详见 [KEY_INFO](#key_info)。。

TomShawn · 2021-08-12T07:50:06Z

information-schema/information-schema-deadlocks.md

+> **注意：**
+>
+> * 仅拥有 [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process) 权限的用户可以查询该表。
+> * `CURRENT_SQL_DIGEST` 列中的信息（SQL Digest）为 SQL 语句进行归一化后计算得到的 hash。`CURRENT_SQL_DIGEST_TEXT` 列中的信息为内部从 Statements Summary 系列表中查询得到，因而存在内部查询不到对应语句的可能性。关于 SQL Digest 和 Statements Summary 相关表的详细说明，请参阅[Statement Summary Tables](/statement-summary-tables.md)。


Suggested change

> * `CURRENT_SQL_DIGEST` 列中的信息（SQL Digest）为 SQL 语句进行归一化后计算得到的 hash。`CURRENT_SQL_DIGEST_TEXT` 列中的信息为内部从 Statements Summary 系列表中查询得到，因而存在内部查询不到对应语句的可能性。关于 SQL Digest 和 Statements Summary 相关表的详细说明，请参阅[Statement Summary Tables](/statement-summary-tables.md)。

> * `CURRENT_SQL_DIGEST` 列中的信息（SQL Digest）为 SQL 语句进行归一化后计算得到的哈希值。`CURRENT_SQL_DIGEST_TEXT` 列中的信息为内部从 Statements Summary 系列表中查询得到，因而存在内部查询不到对应语句的可能性。关于 SQL Digest 和 Statements Summary 相关表的详细说明，请参阅[Statement Summary Tables](/statement-summary-tables.md)。

TomShawn · 2021-08-12T07:50:49Z

information-schema/information-schema-deadlocks.md

+* `"index_name"`：该 index key 所属的 index 名称。
+* `"index_values"`：该 index key 中的 index value。
+
+其中，不适用或当前无法查询到的信息会被省略。比如，row key 的信息中不会包含 `index_id`、`index_name` 和 `index_values`；index key 不会包含 `handle_type` 和 `handle_value`；非分区表不会显示 `partition_id` 和 `partition_name`；已经被 drop 掉的表中的 key 的信息无法获取 `table_name`、`db_id`、`db_name`、`index_name` 等 schema 信息，且无法区分是否为分区表。


drop --> 删除

TomShawn · 2021-08-12T07:56:09Z

information-schema/information-schema-deadlocks.md

+-------------+----------------------------+-----------+--------------------+------------------------------------------------------------------+-----------------------------------------+----------------------------------------+----------------------------------------------------------------------------------------------------+--------------------+
+```
+
+以上查询结果中的 `DEADLOCK_ID` 列表明，前两行共同表示一次死锁错误的信息，两条事务相互等待构成了死锁；而后三行共同表示另一次死锁信息，三个事务循环等待构成了死锁。


Suggested change

以上查询结果中的 `DEADLOCK_ID` 列表明，前两行共同表示一次死锁错误的信息，两条事务相互等待构成了死锁；而后三行共同表示另一次死锁信息，三个事务循环等待构成了死锁。

以上查询结果中的 `DEADLOCK_ID` 列表明，前两行共同表示一次死锁错误的信息，两个事务相互等待构成了死锁；而后三行共同表示另一次死锁信息，三个事务循环等待构成了死锁。

qiancai

LGTM

TomShawn · 2021-08-12T08:44:42Z

/merge

ti-chi-bot · 2021-08-12T08:44:44Z

This pull request has been accepted and is ready to merge.

Commit hash: 46254ce

TomShawn · 2021-08-17T05:56:05Z

information-schema/information-schema-tidb-trx.md

 ```

-## SQL Digest
+此查询


@MyonKeminta 这里是否还有什么需要补充吗？

应该是写的时候写漏了。。我补一下

Update documents of lock view for sprint 4

b6aea65

MyonKeminta added the v5.2 This PR/issue applies to TiDB v5.2. label Aug 6, 2021

ti-chi-bot requested a review from TomShawn August 6, 2021 08:06

ti-chi-bot added missing-translation-status This PR does not have translation status info. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Aug 6, 2021

TomShawn added translation/doing This PR’s assignee is translating this PR. and removed missing-translation-status This PR does not have translation status info. labels Aug 6, 2021

TomShawn self-assigned this Aug 6, 2021

MyonKeminta added 2 commits August 6, 2021 16:18

Add notation about privilege requirements of the tables

b9c20fb

fix lint

753f5a9

MyonKeminta requested a review from cfzjywxk August 6, 2021 08:23

MyonKeminta commented Aug 6, 2021

View reviewed changes

TomShawn added the status/WIP This PR is still working in progress. label Aug 9, 2021

qiancai reviewed Aug 9, 2021

View reviewed changes

cfzjywxk reviewed Aug 9, 2021

View reviewed changes

TomShawn added status/require-change Needs the author to address comments. and removed status/WIP This PR is still working in progress. labels Aug 10, 2021

MyonKeminta added 2 commits August 11, 2021 12:19

Fix the explaination about partition_handle fields

001d6a5

address comments

adf310b

qiancai reviewed Aug 11, 2021

View reviewed changes

MyonKeminta added 2 commits August 11, 2021 13:17

address comments

f2cd34c

update doc of deadlocks

a7c6bfa

cfzjywxk approved these changes Aug 11, 2021

View reviewed changes

TomShawn requested a review from qiancai August 11, 2021 08:54

TomShawn reviewed Aug 12, 2021

View reviewed changes

Try to avoid unnecessary English terms

46254ce

qiancai approved these changes Aug 12, 2021

View reviewed changes

ti-chi-bot added the status/LGT1 Indicates that a PR has LGTM 1. label Aug 12, 2021

TomShawn approved these changes Aug 12, 2021

View reviewed changes

ti-chi-bot added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Aug 12, 2021

ti-chi-bot added the status/can-merge Indicates a PR has been approved by a committer. label Aug 12, 2021

ti-chi-bot merged commit aaa92d7 into pingcap:master Aug 12, 2021

MyonKeminta deleted the m/lock-view-s4 branch August 13, 2021 02:24

TomShawn removed the status/require-change Needs the author to address comments. label Aug 16, 2021

TomShawn reviewed Aug 17, 2021

View reviewed changes

TomShawn added translation/done This PR has been translated from English into Chinese and updated to pingcap/docs-cn in a PR. and removed translation/doing This PR’s assignee is translating this PR. labels Aug 17, 2021

TomShawn mentioned this pull request Aug 17, 2021

Update documents of lock view for sprint 4 pingcap/docs#6179

Merged

12 tasks

MyonKeminta mentioned this pull request Aug 17, 2021

Fix missing paragraph in document of TIDB_TRX table #6882

Merged

12 tasks

MyonKeminta mentioned this pull request Aug 24, 2021

Fix the description of an example of lock view #6929

Merged

12 tasks

	上述调用指定了第二个参数（即阶段长度）为 10，而查询结果中的第三条语句的长度大于 10，因而仅保留了前 10 个字符，并在尾部添加了 `"..."` 表示发生了截断。
	上述调用指定了第二个参数（即截断长度）为 10，而查询结果中的第三条语句的长度大于 10，因而仅保留了前 10 个字符，并在尾部添加了 `"..."` 表示发生了截断。

	> Lock View 相关的表中展示的 SQL 语句均为归一化的 SQL 语句（即去除了格式和参数的形式），由 SQL Digest 内部查询获得，因而无法获取包括格式和参数在内的完整语句。有关 SQL Digest 和归一化 SQL 语句的详细介绍详见 [Statement Summary Tables](/statement-summary-tables.md)
	> Lock View 相关的系统表中展示的 SQL 语句为归一化的 SQL 语句（即去除了格式和参数的形式的 SQL 语句），由 SQL Digest 内部查询获得，因而无法获取包括格式和参数在内的完整语句。有关 SQL Digest 和归一化 SQL 语句的详细介绍，请参阅 [Statement Summary Tables](/statement-summary-tables.md)。

	> * `SQL_DIGEST` 列中的信息（SQL Digest）为 SQL 语句进行归一化后计算得到的 hash。`SQL_DIGEST_TEXT` 列中的信息为内部从 Statements Summary 系列表中查询得到，因而存在内部查询不到对应语句的可能性。关于 SQL Digest 和 Statements Summary 相关表的详细说明，请参阅[Statement Summary Tables](/statement-summary-tables.md)。
	> * `SQL_DIGEST` 列中的信息（SQL Digest）为 SQL 语句进行归一化后计算得到的哈希值。`SQL_DIGEST_TEXT` 列中的信息为内部从 Statements Summary 系列表中查询得到，因而存在内部查询不到对应语句的可能性。关于 SQL Digest 和 Statements Summary 相关表的详细说明，请参阅[Statement Summary Tables](/statement-summary-tables.md)。

		* `KEY`：该事务试图上锁、但是被阻塞的 key，以十六进制编码的形式显示。
		* `KEY_INFO`：对 `KEY` 进行解读得出的一些详细信息，详见 [KEY_INFO](#key_info)。。

	* `KEY_INFO`：对 `KEY` 进行解读得出的一些详细信息，详见 [KEY_INFO](#key_info)。。
	* `KEY_INFO`：对 `KEY` 进行解读得出的详细信息，详见 [KEY_INFO](#key_info)。。

	以上查询结果中的 `DEADLOCK_ID` 列表明，前两行共同表示一次死锁错误的信息，两条事务相互等待构成了死锁；而后三行共同表示另一次死锁信息，三个事务循环等待构成了死锁。
	以上查询结果中的 `DEADLOCK_ID` 列表明，前两行共同表示一次死锁错误的信息，两个事务相互等待构成了死锁；而后三行共同表示另一次死锁信息，三个事务循环等待构成了死锁。

Update documents of lock view for sprint 4 #6824

Update documents of lock view for sprint 4 #6824

Conversation

MyonKeminta commented Aug 6, 2021

First-time contributors' checklist

What is changed, added or deleted? (Required)

Which TiDB version(s) do your changes apply to? (Required)

What is the related PR or file link(s)?

Do your changes match any of the following descriptions?

ti-chi-bot commented Aug 6, 2021 • edited Loading

TomShawn commented Aug 6, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qiancai left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MyonKeminta commented Aug 11, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cfzjywxk left a comment

Choose a reason for hiding this comment

ti-chi-bot commented Aug 11, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qiancai left a comment

Choose a reason for hiding this comment

TomShawn commented Aug 12, 2021

ti-chi-bot commented Aug 12, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ti-chi-bot commented Aug 6, 2021 •

edited

Loading