From 52462b1f9158c4f9e8285f436f9117aed49f0c93 Mon Sep 17 00:00:00 2001
From: TomShawn <41534398+TomShawn@users.noreply.github.com>
Date: Wed, 15 Apr 2020 12:14:55 +0800
Subject: [PATCH] reference: fix typos and refine sql diagnosis related
 documents (#2737)

* reference: fix typos and refine sql diagnosis related documents

* fix a broken link

Co-authored-by: reafans <30926443+reafans@users.noreply.github.com>
---
 reference/system-databases/cluster-config.md  |  2 +-
 .../system-databases/cluster-hardware.md      |  8 +--
 reference/system-databases/cluster-info.md    |  6 +-
 reference/system-databases/cluster-load.md    |  8 +--
 reference/system-databases/cluster-log.md     | 10 +--
 .../system-databases/cluster-systeminfo.md    |  8 +--
 .../system-databases/inspection-result.md     | 72 +++++++++----------
 .../system-databases/inspection-summary.md    | 48 ++++++-------
 reference/system-databases/metrics-schema.md  | 26 +++----
 reference/system-databases/metrics-summary.md | 20 +++---
 reference/system-databases/metrics-tables.md  |  2 +-
 11 files changed, 104 insertions(+), 106 deletions(-)

diff --git a/reference/system-databases/cluster-config.md b/reference/system-databases/cluster-config.md
index 286645d068b5..623e7a57420c 100644
--- a/reference/system-databases/cluster-config.md
+++ b/reference/system-databases/cluster-config.md
@@ -27,7 +27,7 @@ desc cluster_config;
 
 字段解释：
 
-* `TYPE`：节点的类型，可取值为 `tidb`，`pd` 或 `tikv`。
+* `TYPE`：节点的类型，可取值为 `tidb`，`pd` 和 `tikv`。
 * `INSTANCE`：节点的服务地址。
 * `KEY`：配置项名。
 * `VALUE`：配置项值。
diff --git a/reference/system-databases/cluster-hardware.md b/reference/system-databases/cluster-hardware.md
index aefe09b6200b..d59408628e6f 100644
--- a/reference/system-databases/cluster-hardware.md
+++ b/reference/system-databases/cluster-hardware.md
@@ -1,6 +1,6 @@
 ---
 title: CLUSTER_HARDWARE
-summary: 了解 TiDB 集群配置表 `CLUSTER_HARDWARE`。
+summary: 了解 TiDB 集群硬件表 `CLUSTER_HARDWARE`。
 category: reference
 ---
 
@@ -29,15 +29,15 @@ desc cluster_hardware;
 
 字段解释：
 
-* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。
-* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `STATUS_ADDRESS` 字段。
+* `TYPE`：对应节点信息表 [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md) 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 和 `tikv`。
+* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `INSTANCE` 字段。
 * `DEVICE_TYPE`：硬件类型。目前可以查询的硬件类型有 `cpu`、`memory`、`disk` 和 `net`。
 * `DEVICE_NAME`：硬件名。对于不同的 `DEVICE_TYPE`，`DEVICE_NAME` 的取值不同。
     * `cpu`：硬件名为 cpu。
     * `memory`：硬件名为 memory。
     * `disk`：磁盘名。
     * `net`：网卡名。
-* `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` ， `cpu-physical-cores` 两个信息名，表示逻辑核心数量和物理核心数量。
+* `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` 和 `cpu-physical-cores` 两个信息名，表示逻辑核心数量和物理核心数量。
 * `VALUE`：对应硬件信息的值。例如磁盘容量和 CPU 核数。
 
 查询集群 CPU 信息的示例如下：
diff --git a/reference/system-databases/cluster-info.md b/reference/system-databases/cluster-info.md
index ba74408f07bd..ed7bae4d7b7b 100644
--- a/reference/system-databases/cluster-info.md
+++ b/reference/system-databases/cluster-info.md
@@ -1,6 +1,6 @@
 ---
 title: CLUSTER_INFO
-summary: 了解 TiDB 集群配置表 `CLUSTER_INFO`。
+summary: 了解 TiDB 集群拓扑表 `CLUSTER_INFO`。
 category: reference
 ---
 
@@ -31,9 +31,9 @@ desc cluster_info;
 
 字段解释：
 
-* `TYPE`：节点类型，目前节点的可取值为 `tidb`，`pd` 或 `tikv`。
+* `TYPE`：节点类型，目前节点的可取值为 `tidb`，`pd` 和 `tikv`。
 * `INSTANCE`：实例地址，为 `IP:PORT` 格式的字符串。
-* `STATUS_ADDRESS`：HTTP API 的服务地址。部分 `tikv-ctl`、`pd-ctl` 或 `tidb-ctl` 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 HTTP API 官方文档。
+* `STATUS_ADDRESS`：HTTP API 的服务地址。部分 `tikv-ctl`、`pd-ctl` 或 `tidb-ctl` 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 [HTTP API 文档](https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md)。
 * `VERSION`：对应节点的语义版本号。TiDB 版本为了兼容 MySQL 的版本号，以 `${mysql-version}-${tidb-version}` 的格式展示版本号。
 * `GIT_HASH`：编译节点版本时的 Git Commit Hash，用于识别两个节点是否是绝对一致的版本。
 * `START_TIME`：对应节点的启动时间。
diff --git a/reference/system-databases/cluster-load.md b/reference/system-databases/cluster-load.md
index 57c2e0e2fc1d..b17428d38bb6 100644
--- a/reference/system-databases/cluster-load.md
+++ b/reference/system-databases/cluster-load.md
@@ -1,6 +1,6 @@
 ---
 title: CLUSTER_LOAD
-summary: 了解 TiDB 集群配置表 `CLUSTER_LOAD`。
+summary: 了解 TiDB 集群负载表 `CLUSTER_LOAD`。
 category: reference
 ---
 
@@ -29,7 +29,7 @@ desc cluster_load;
 
 字段解释：
 
-* `TYPE`：对应于节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。
+* `TYPE`：对应于节点信息表 [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md) 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 和 `tikv`。
 * `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `STATUS_ADDRESS` 字段。
 * `DEVICE_TYPE`：硬件类型，目前可以查询的硬件类型有 `cpu`、`memory`、`disk` 和 `net`。
 * `DEVICE_NAME`：硬件名。对于不同的 `DEVICE_TYPE`，`DEVICE_NAME` 取值不同。
@@ -37,8 +37,8 @@ desc cluster_load;
     * `disk`：磁盘名。
     * `net`：网卡名。
     * `memory`：硬件名为 memory。
-* `NAME`：不同的负载类型。例如 cpu 有 `load1`/`load5`/`load15` 三个负载类型，分别表示 cpu 在 `1min`/`5min`/`15min` 内的平均负载。
-* `VALUE`：硬件负载的值，例如 cpu 在 `1min`/`5min`/`15min` 内的平均负载。
+* `NAME`：不同的负载类型。例如 cpu 有 `load1`/`load5`/`load15` 三个负载类型，分别表示 cpu 在 1min/5min/15min 内的平均负载。
+* `VALUE`：硬件负载的值，例如 cpu 在 1min/5min/15min 内的平均负载。
 
 查询集群当前的 CPU 负载信息示例如下：
 
diff --git a/reference/system-databases/cluster-log.md b/reference/system-databases/cluster-log.md
index 8adbad647bd4..564b893860f6 100644
--- a/reference/system-databases/cluster-log.md
+++ b/reference/system-databases/cluster-log.md
@@ -1,6 +1,6 @@
 ---
 title: CLUSTER_LOG
-summary: 了解 TiDB 集群配置表 `CLUSTER_LOG`。
+summary: 了解 TiDB 集群日志表 `CLUSTER_LOG`。
 category: reference
 ---
 
@@ -32,7 +32,7 @@ desc cluster_log;
 字段解释：
 
 * `TIME`：日志打印时间。
-* `TYPE`：节点的类型，可取值为 `tidb`，`pd` 或 `tikv`。
+* `TYPE`：节点的类型，可取值为 `tidb`，`pd` 和 `tikv`。
 * `INSTANCE`：节点的服务地址。
 * `LEVEL`：日志级别。
 * `MESSAGE`：日志内容。
@@ -68,6 +68,6 @@ select * from `CLUSTER_LOG` where message like '%ddl%' and message like '%job%58
 
 上面查询结果表示：
 
-1. 用户将 DDL JOB ID 为 58 的请求发给 `172.16.5.40:4008` TiDB 节点。
-2. `172.16.5.40:4009` TiDB 节点处理这个 DDL 请求，说明此时 `172.16.5.40:4009` 节点是 DDL owner。
-3. DDL JOB ID 为 58 的请求处理完成。
\ No newline at end of file
++ 用户将 DDL JOB ID 为 `58` 的请求发给 `172.16.5.40:4008` TiDB 节点。
++ `172.16.5.40:4009` TiDB 节点处理这个 DDL 请求，说明此时 `172.16.5.40:4009` 节点是 DDL owner。
++ DDL JOB ID 为 58 的请求处理完成。
diff --git a/reference/system-databases/cluster-systeminfo.md b/reference/system-databases/cluster-systeminfo.md
index ef6c6faeea27..cfd4f8d09d9a 100644
--- a/reference/system-databases/cluster-systeminfo.md
+++ b/reference/system-databases/cluster-systeminfo.md
@@ -1,6 +1,6 @@
 ---
 title: CLUSTER_SYSTEMINFO
-summary: 了解 TiDB 集群配置表 `CLUSTER_SYSTEMINFO`。
+summary: 了解 TiDB 集群负载表 `CLUSTER_SYSTEMINFO`。
 category: reference
 ---
 
@@ -30,8 +30,8 @@ desc cluster_systeminfo;
 
 字段解释：
 
-* `TYPE`：对应于节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。
-* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `INSTANCE` 字段。
+* `TYPE`：对应于节点信息表 [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md) 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 和 `tikv`。
+* `INSTANCE`：对应于节点信息表 [`information_schema.cluster_info`](/reference/system-databases/information-schema.md) 中的 `INSTANCE` 字段。
 * `SYSTEM_TYPE`：系统类型，目前可以查询的系统类型有 `system`。
 * `SYSTEM_NAME`：目前可以查询的 `SYSTEM_NAME` 为 `sysctl`。
 * `NAME`：`sysctl` 对应的配置名。
@@ -51,4 +51,4 @@ select * from CLUSTER_SYSTEMINFO where name like '%kernel.osrelease%'
 | pd   | 172.16.5.40:20379 | system      | sysctl      | kernel.osrelease | 3.10.0-862.14.4.el7.x86_64 |
 | tikv | 172.16.5.40:21150 | system      | sysctl      | kernel.osrelease | 3.10.0-862.14.4.el7.x86_64 |
 +------+-------------------+-------------+-------------+------------------+----------------------------+
-```
\ No newline at end of file
+```
diff --git a/reference/system-databases/inspection-result.md b/reference/system-databases/inspection-result.md
index 90ac3f5aec2c..55589ad79e23 100644
--- a/reference/system-databases/inspection-result.md
+++ b/reference/system-databases/inspection-result.md
@@ -1,6 +1,6 @@
 ---
 title: INSPECTION_RESULT
-summary: 了解 TiDB 集群配置表 `INSPECTION_RESULT`。
+summary: 了解 TiDB 系统表 `INSPECTION_RESULT`。
 category: reference
 ---
 
@@ -15,7 +15,7 @@ TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。
 {{< copyable "sql" >}}
 
 ```sql
-mysql> desc inspection_result;
+desc inspection_result;
 ```
 
 ```
@@ -43,7 +43,7 @@ mysql> desc inspection_result;
     * `critical-error`：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 `warning` 诊断结果。
     * `threshold-check`：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息。
 * `ITEM`：每一个规则会对不同的项进行诊断，该字段表示对应规则下面的具体诊断项。
-* `TYPE`：诊断的实例类型，可取值为 `tidb`，`pd` 或 `tikv`。
+* `TYPE`：诊断的实例类型，可取值为 `tidb`，`pd` 和 `tikv`。
 * `INSTANCE`：诊断的具体实例地址。
 * `VALUE`：针对这个诊断项得到的值。
 * `REFERENCE`：针对这个诊断项的参考值（阈值）。如果 `VALUE` 和阈值相差较大，就会产生对应的诊断信息。
@@ -101,9 +101,9 @@ DETAILS   | max duration of 172.16.5.40:20151 tikv rocksdb-write-duration was to
 
 上述诊断结果发现了以下几个问题：
 
-* 第一行表示 TiDB 的 log.slow-threshold 配置值为 0 ， 可能会影响性能。
+* 第一行表示 TiDB 的 `log.slow-threshold` 配置值为 `0`，可能会影响性能。
 * 第二行表示集群中有 2 个不同的 TiDB 版本
-* 第三、四行表示 TiKV 的写入延迟太大，期望时间是不超过 0.1s, 但实际值远超预期。 
+* 第三、四行表示 TiKV 的写入延迟太大，期望时间是不超过 0.1s, 但实际值远超预期。
 
 诊断集群在时间段 "2020-03-26 00:03:00", "2020-03-26 00:08:00" 的问题。指定时间范围需要使用 `/*+ time_range() */` 的 SQL Hint，参考下面的查询示例：
 
@@ -137,7 +137,7 @@ DETAILS   | max duration of 172.16.5.40:10089 tidb get-token-duration is too slo
 上面的诊断结果发现了以下问题：
 
 * 第一行表示 172.16.5.40:4009 TiDB 节点在 `2020/03/26 00:05:45.670` 发生了重启。
-* 第二行表示 172.16.5.40:10089 TiDB 节点的最大的 get-token-duration 时间为 0.234s, 期望时间是小于 0.001s。 
+* 第二行表示 172.16.5.40:10089 TiDB 节点的最大的 `get-token-duration` 时间为 0.234s, 期望时间是小于 0.001s。
 
 也可以指定条件，比如只查询 `critical` 严重级别的诊断结果：
 
@@ -179,9 +179,9 @@ select * from inspection_rules where type='inspection';
 +-----------------+------------+---------+
 ```
 
-### config 诊断规则
+### `config` 诊断规则
 
-config 诊断规则通过查询 `CLUSTER_CONFIG` 系统表，执行以下 2 个诊断规则：
+`config` 诊断规则通过查询 `CLUSTER_CONFIG` 系统表，执行以下两个诊断规则：
 
 * 检测相同组件的配置值是否一致，并非所有配置项都会有一致性检查，下面是一致性检查的白名单：
 
@@ -196,7 +196,7 @@ config 诊断规则通过查询 `CLUSTER_CONFIG` 系统表，执行以下 2 个
     log.file.filename
     log.slow-query-file
 
-    // PD 配置一致性检查白名单 
+    // PD 配置一致性检查白名单
     advertise-client-urls
     advertise-peer-urls
     client-urls
@@ -218,14 +218,14 @@ config 诊断规则通过查询 `CLUSTER_CONFIG` 系统表，执行以下 2 个
 
 * 检测以下配置项的值是否符合预期。
 
-|  组件  | 配置项 | 预期值 |
-|  ----  | ----  |  ----  |
-| TiDB | log.slow-threshold | 大于 0 |
-| TiKV | raftstore.sync-log | true |
+    |  组件  | 配置项 | 预期值 |
+    |  :----  | :----  |  :----  |
+    | TiDB | log.slow-threshold | 大于 0 |
+    | TiKV | raftstore.sync-log | true |
 
 ### version 诊断规则
 
-version 诊断规则通过查询 `CLUSTER_INFO` 系统表，检测相同组件的版本 hash 是否一致。示例如下：
+`version` 诊断规则通过查询 `CLUSTER_INFO` 系统表，检测相同组件的版本 hash 是否一致。示例如下：
 
 {{< copyable "sql" >}}
 
@@ -245,32 +245,32 @@ SEVERITY  | critical
 DETAILS   | the cluster has 2 different tidb versions, execute the sql to see more detail: select * from information_schema.cluster_info where type='tidb'
 ```
 
-### critical-error 诊断规则
+### `critical-error` 诊断规则
 
-critical-error 诊断规则执行以下 2 个诊断规则：
+`critical-error` 诊断规则执行以下两个诊断规则：
 
-* 通过查询 metrics_schema 数据库中相关的监控系统表，检测集群是否有出现以下比较严重的错误：
+* 通过查询 [metrics schema](/reference/system-databases/metrics-schema.md) 数据库中相关的监控系统表，检测集群是否有出现以下比较严重的错误：
 
-|  组件  | 错误名字 | 相关监控表 | 错误说明 |
-|  ----  | ----  |  ----  |  ----  |
-| TiDB | panic-count | tidb_panic_count_total_count | TiDB 出现 panic 错误 |
-| TiDB | binlog-error | tidb_binlog_error_total_count | TiDB 写 binlog 时出现的错误 |
-| TiKV | critical-error | tikv_critical_error_total_coun | TiKV 的 critical error |
-| TiKV | scheduler-is-busy       | tikv_scheduler_is_busy_total_count | TiKV 的 scheduler 太忙，该使 TiKV 临时不可用 |
-| TiKV | coprocessor-is-busy | tikv_coprocessor_is_busy_total_count | TiKV 的 coprocessor 太忙 |
-| TiKV | channel-is-full | tikv_channel_full_total_count | TiKV 出现 channel full 的错误 |
-| TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV 出现写入 stall 的错误 |
+    |  组件  | 错误名字 | 相关监控表 | 错误说明 |
+    |  ----  | ----  |  ----  |  ----  |
+    | TiDB | panic-count | tidb_panic_count_total_count | TiDB 出现 panic 错误 |
+    | TiDB | binlog-error | tidb_binlog_error_total_count | TiDB 写 binlog 时出现的错误 |
+    | TiKV | critical-error | tikv_critical_error_total_coun | TiKV 的 critical error |
+    | TiKV | scheduler-is-busy       | tikv_scheduler_is_busy_total_count | TiKV 的 scheduler 太忙，该使 TiKV 临时不可用 |
+    | TiKV | coprocessor-is-busy | tikv_coprocessor_is_busy_total_count | TiKV 的 coprocessor 太忙 |
+    | TiKV | channel-is-full | tikv_channel_full_total_count | TiKV 出现 channel full 的错误 |
+    | TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV 出现写入 stall 的错误 |
 
-* 通过查询 metrics_schema.up 监控表和 `CLUSTER_LOG` 系统表，检查是否有组件发生重启。
+* 通过查询 `metrics_schema.up` 监控表和 `CLUSTER_LOG` 系统表，检查是否有组件发生重启。
 
-### threshold-check 诊断规则
+### `threshold-check` 诊断规则
 
-threshold-check 诊断规则通过查询 metrics_schema 数据库中相关的监控系统表，检测集群中以下指标是否超出阈值：
+`threshold-check` 诊断规则通过查询 [metrics schema](/reference/system-databases/metrics-schema.md) 数据库中相关的监控系统表，检测集群中以下指标是否超出阈值：
 
 |  组件  | 监控指标 | 相关监控表 | 预期值 |  说明  |
-|  ----  | ----  |  ----  |  ----  |  ----  |
+|  :----  | :----  |  :----  |  :----  |  :----  |
 | TiDB | tso-duration              | pd_tso_wait_duration                | 小于 50 ms  |  获取事务 TSO 时间戳的耗时 |
-| TiDB | get-token-duration        | tidb_get_token_duration             | 小于 1 ms   |  查询获取 token 的耗时, 相关的 TiDB 配置参数是 token-limit  |
+| TiDB | get-token-duration        | tidb_get_token_duration             | 小于 1 ms   |  查询获取 token 的耗时，相关的 TiDB 配置参数是 token-limit  |
 | TiDB | load-schema-duration      | tidb_load_schema_duration           | 小于 1 s    |  TiDB 更新获取表元信息的耗时 |
 | TiKV | scheduler-cmd-duration    | tikv_scheduler_command_duration     | 小于 0.1 s  |  TiKV 执行 KV cmd 请求的耗时 |
 | TiKV | handle-snapshot-duration  | tikv_handle_snapshot_duration       | 小于 30 s   |  TiKV 处理 snapshot 的耗时 |
@@ -284,10 +284,10 @@ threshold-check 诊断规则通过查询 metrics_schema 数据库中相关的监
 | TiKV | filter-block-cache-hit | tikv_block_filter_cache_hit | 大于 0.95 | TiKV 中 filter block 缓存的命中率 |
 | TiKV | data-block-cache-hit | tikv_block_data_cache_hit | 大于 0.80 | TiKV 中 data block 缓存的命中率 |
 | TiKV | leader-score-balance | pd_scheduler_store_status  | 小于 0.05 | 检测各个 TiKV 节点的 leader score 是否均衡，期望节点间的差异小于 5% |
-| TiKV | region-score-balance | pd_scheduler_store_status  | 小于 0.05 | 检测各个 TiKV 节点的 region score 是否均衡，期望节点间的差异小于 5% |
+| TiKV | region-score-balance | pd_scheduler_store_status  | 小于 0.05 | 检测各个 TiKV 节点的 Region score 是否均衡，期望节点间的差异小于 5% |
 | TiKV | store-available-balance | pd_scheduler_store_status  | 小于 0.2 | 检测各个 TiKV 节点的存储可用空间大小是否均衡，期望节点间的差异小于 20% |
-| TiKV | region-count | pd_scheduler_store_status  | 小于 20000 | 检测各个 TiKV 节点的 region 数量，期望单个节点的 region 数量小于 20000 |
-| PD | region-health | pd_region_health | 小于 100  | 检测集群中处于调度中间状态的 region 数量，期望总数小于 100 |
+| TiKV | region-count | pd_scheduler_store_status  | 小于 20000 | 检测各个 TiKV 节点的 Region 数量，期望单个节点的 Region 数量小于 20000 |
+| PD | region-health | pd_region_health | 小于 100  | 检测集群中处于调度中间状态的 Region 数量，期望总数小于 100 |
 
 另外还会检测 TiKV 节点的以下 thread cpu usage 是否过高:
 
@@ -303,6 +303,4 @@ threshold-check 诊断规则通过查询 metrics_schema 数据库中相关的监
 * storage-readpool-low-cpu
 * split-check-cpu
 
-## 最后
-
-TiDB 内置的诊断规则还在不断的完善改进中，如果你也想到了一些诊断规则，非常欢迎给 TiDB 提 PR 或 ISSUE。
\ No newline at end of file
+TiDB 内置的诊断规则还在不断的完善改进中，如果你也想到了一些诊断规则，非常欢迎在 [tidb repository](https://github.com/pingcap/tidb) 下提 PR 或 Issue。
diff --git a/reference/system-databases/inspection-summary.md b/reference/system-databases/inspection-summary.md
index be0df9a86016..7b29b8f004b8 100644
--- a/reference/system-databases/inspection-summary.md
+++ b/reference/system-databases/inspection-summary.md
@@ -1,19 +1,19 @@
 ---
 title: INSPECTION_SUMMARY
-summary: 了解 TiDB 集群配置表 `INSPECTION_SUMMARY`。
+summary: 了解 TiDB 系统表 `INSPECTION_SUMMARY`。
 category: reference
 ---
 
 # INSPECTION_SUMMARY
 
-在部分场景下，用户只关注特定链路或模块的监控汇总。例如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定存在风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。排查这部分场景的问题也非常重要，所以TiDB 提供了 `inspection_summary` 来进行链路汇总。
+在部分场景下，用户只关注特定链路或模块的监控汇总。例如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定存在风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。排查这部分场景的问题也非常重要，所以 TiDB 提供了 `inspection_summary` 来进行链路汇总。
 
 诊断汇总表 `information_schema.inspection_summary` 的表结构如下：
 
 {{< copyable "sql" >}}
 
 ```sql
-mysql> desc inspection_summary;
+desc inspection_summary;
 ```
 
 ```
@@ -51,25 +51,25 @@ mysql> desc inspection_summary;
 {{< copyable "sql" >}}
 
 ```sql
-mysql> SELECT
-         t1.avg_value / t2.avg_value AS ratio,
-         t1.*,
-         t2.*
-       FROM
-         (
-           SELECT
-             /*+ time_range("2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933")*/ *
-           FROM inspection_summary WHERE rule='read-link'
-         ) t1
-         JOIN
-         (
-           SELECT
-             /*+ time_range("2020-01-16 16:10:54.933","2020-01-16 16:20:54.933")*/ *
-           FROM inspection_summary WHERE rule='read-link'
-         ) t2
-         ON t1.metrics_name = t2.metrics_name
-         and t1.instance = t2.instance
-         and t1.label = t2.label
-       ORDER BY
-         ratio DESC;
+SELECT
+  t1.avg_value / t2.avg_value AS ratio,
+  t1.*,
+  t2.*
+FROM
+  (
+    SELECT
+      /*+ time_range("2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933")*/ *
+    FROM inspection_summary WHERE rule='read-link'
+  ) t1
+  JOIN
+  (
+    SELECT
+      /*+ time_range("2020-01-16 16:10:54.933","2020-01-16 16:20:54.933")*/ *
+    FROM inspection_summary WHERE rule='read-link'
+  ) t2
+  ON t1.metrics_name = t2.metrics_name
+  and t1.instance = t2.instance
+  and t1.label = t2.label
+ORDER BY
+  ratio DESC;
 ```
diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md
index 8adad90a67d0..0d67f07d049d 100644
--- a/reference/system-databases/metrics-schema.md
+++ b/reference/system-databases/metrics-schema.md
@@ -1,13 +1,12 @@
 ---
 title: Metrics Schema
-summary: 了解 TiDB 集群配置表 `METRICS_SCHEMA`。
+summary: 了解 TiDB METRICS SCHEMA 系统数据库。
 category: reference
 ---
 
 # Metrics Schema
 
-为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控。实际上，SQL 诊断，以及 `metrics_summary`，`metrics_summary_by_label`，`inspection_result` 这三个监控相关的汇总表数据都是通过查询 `metrics_schema` 库中的各种监控表来获取信息的。
-。目前添加的系统表数量较多，用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。
+为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有表都在 metrics schema 中，可以通过 SQL 的方式查询监控。实际上，SQL 诊断，以及 `metrics_summary`，`metrics_summary_by_label`，`inspection_result` 这三个监控相关的汇总表数据都是通过查询 metrics schema 库中的各种监控表来获取信息的。目前添加的系统表数量较多，用户可以通过 [`information_schema.metrics_tables`](/reference/system-databases/metrics-tables.md) 查询这些表的相关信息。
 
 ## 概览
 
@@ -29,9 +28,9 @@ select * from information_schema.metrics_tables where table_name='tidb_query_dur
 +---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+----------+----------------------------------------------+
 ```
 
-* `TABLE_NAME`：对应于 `metrics_schema` 中的表名，这里表名是 `tidb_query_duration`。
+* `TABLE_NAME`：对应于 metrics schema 中的表名，这里表名是 `tidb_query_duration`。
 * `PROMQL`：因为监控表的原理是将 SQL 映射成 `PromQL`，并将 Prometheus 结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。
-* `LABELS`：监控定义的 label，`tidb_query_duration` 有 2 个 label，分别是 `instance` 和 `sql_type`。
+* `LABELS`：监控定义的 label，`tidb_query_duration` 有两个 label，分别是 `instance` 和 `sql_type`。
 * `QUANTILE`：百分位。对于直方图类型的监控数据，指定一个默认百分位。如果值为 `0`，表示该监控表对应的监控不是直方图。`tidb_query_duration` 默认查询 0.9 ，也就是 P90 的监控值。
 * `COMMENT`：对这个监控表的解释。可以看出 `tidb_query_duration` 表的是用来查询 TiDB query 执行的百分位时间，如 P999/P99/P90 的查询耗时，单位是秒。
 
@@ -86,7 +85,7 @@ select * from metrics_schema.tidb_query_duration where value is not null and tim
 +---------------------+-------------------+----------+----------+----------------+
 ```
 
-以上查询结果的第一行意思是，在 2020-03-25 23:40:00 时，在TiDB 实例 172.16.5.40:10089 上，`Insert` 类型的语句的 P99 执行时间是 0.509929485256 秒。其他各行的含义类似，`sql_type` 列的其他值含义如下：
+以上查询结果的第一行意思是，在 `2020-03-25 23:40:00` 时，在 TiDB 实例 `172.16.5.40:10089` 上，`Insert` 类型的语句的 P99 执行时间是 0.509929485256 秒。其他各行的含义类似，`sql_type` 列的其他值含义如下：
 
 * `Select`：表示执行的 `select` 类型的语句。
 * `internal`：表示 TiDB 的内部 SQL 语句，一般是统计信息更新，获取全局变量相关的内部语句。
@@ -110,17 +109,18 @@ desc select * from metrics_schema.tidb_query_duration where value is not null an
 
 可以发现执行计划中有一个 `PromQL`, 以及查询监控的 `start_time` 和 `end_time`，还有 `step` 值，在实际执行时，TiDB 会调用 Prometheus 的 `query_range` HTTP API 接口来查询监控数据。
 
-细心的读者可能已经发现，在 [`2020-03-25 23:40:00`, `2020-03-25 23:42:00`] 时间范围内，每个 label 只有 3 个时间的值，执行计划中的 `step` 值为 1 分钟，这实际上是由下面 2 个 session 变量决定的：
+从以上结果可知，在 [`2020-03-25 23:40:00`, `2020-03-25 23:42:00`] 时间范围内，每个 label 只有三个时间的值，执行计划中的 `step` 值为一分钟，这实际上是由下面两个 session 变量决定的：
 
 * `tidb_metric_query_step`：查询的分辨率步长。从 Prometheus 的 `query_range` 数据时需要指定 `start`，`end` 和 `step`，其中 `step` 会使用该变量的值。
 * `tidb_metric_query_range_duration`：查询监控时，会将 `PROMQL` 中的 `$RANGE_DURATION` 替换成该变量的值，默认值是 60 秒。
 
-如果想要查看不同时间粒度的监控项的值，用户可以修改上面2个 session 变量后查询监控表，示例如下：
+如果想要查看不同时间粒度的监控项的值，用户可以修改上面两个 session 变量后查询监控表，示例如下：
 
-首先修改 2 个 session 变量的值，将时间粒度设置为 30 秒。
+首先修改两个 session 变量的值，将时间粒度设置为 30 秒。
 
-> 注意
-> Prometheus 支持查询的最小粒度就是 30 秒。
+> **注意：**
+>
+> Prometheus 支持查询的最小粒度为 30 秒。
 
 {{< copyable "sql" >}}
 
@@ -129,7 +129,7 @@ set @@tidb_metric_query_step=30;
 set @@tidb_metric_query_range_duration=30;
 ```
 
-再查询 `tidb_query_duration` 监控如下，可以发现在 3 分钟时间范围内，每个 label 有 6 个时间的值，每个值时间间隔是 30 秒。
+再查询 `tidb_query_duration` 监控如下，可以发现在三分钟时间范围内，每个 label 有六个时间的值，每个值时间间隔是 30 秒。
 
 {{< copyable "sql" >}}
 
@@ -159,7 +159,7 @@ select * from metrics_schema.tidb_query_duration where value is not null and tim
 +---------------------+-------------------+----------+----------+-----------------+
 ```
 
-最后查看执行计划，也会发现执行计划中的 `PromQL` 以及 `step` 的值都已经变成了 `30` 秒。
+最后查看执行计划，也会发现执行计划中的 `PromQL` 以及 `step` 的值都已经变成了 30 秒。
 
 {{< copyable "sql" >}}
 
diff --git a/reference/system-databases/metrics-summary.md b/reference/system-databases/metrics-summary.md
index f7bd3c35ab33..559afa320d2d 100644
--- a/reference/system-databases/metrics-summary.md
+++ b/reference/system-databases/metrics-summary.md
@@ -1,6 +1,6 @@
 ---
 title: METRICS_SUMMARY
-summary: 了解 TiDB 集群配置表 `METRICS_SUMMARY`。
+summary: 了解 TiDB 系统表 `METRICS_SUMMARY`。
 category: reference
 ---
 
@@ -16,7 +16,7 @@ category: reference
 {{< copyable "sql" >}}
 
 ```sql
-mysql> desc metrics_summary;
+desc metrics_summary;
 ```
 
 ```
@@ -38,7 +38,7 @@ mysql> desc metrics_summary;
 * `METRICS_NAME`：监控表名。
 * `QUANTILE`：百分位。可以通过 SQL 语句指定 `QUANTILE`，例如：
     * `select * from metrics_summary where quantile=0.99` 指定查看百分位为 0.99 的数据。
-    * `select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999)` 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据。
+    * `select * from metrics_summary where quantile in (0.80, 0.90, 0.99, 0.999)` 同时查看百分位为 0.80, 0.90, 0.99, 0.999 的数据。
 * `SUM_VALUE、AVG_VALUE、MIN_VALUE、MAX_VALUE` 分别表示总和、平均值、最小值、最大值。
 * `COMMENT`：对应监控的解释。
 
@@ -150,10 +150,10 @@ SELECT GREATEST(t1.avg_value,t2.avg_value)/LEAST(t1.avg_value,
          t1.avg_value as t1_avg_value,
          t2.avg_value as t2_avg_value,
          t2.comment
-FROM 
+FROM
     (SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ *
     FROM information_schema.metrics_summary ) t1
-JOIN 
+JOIN
     (SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ *
     FROM information_schema.metrics_summary ) t2
     ON t1.metrics_name = t2.metrics_name
@@ -180,11 +180,11 @@ ORDER BY  ratio DESC limit 10;
 上面查询结果表示：
 
 * t2 时间段内的 `tidb_slow_query_cop_process_total_time`（TiDB 慢查询中的 `cop process` 耗时）比 t1 时间段高了 5865 倍。
-* t2 时间段内的 `tidb_distsql_partial_scan_key_total_num`（TiDB 的 `distsql` 请求扫描key 的数量）比 t1 时间段高了 3648 倍。
-t2 时间段内，`tidb_slow_query_cop_wait_total_time` (TiDB 慢查询中的 cop 请求排队等待的耗时) 比 t1 时间段高了 267 倍。
-* t2 时间段内的 `tikv_cop_total_response_size`（TiKV 的 cop 请求结果的大小 ）比 t1 时间段高了 192 倍。
-* t2 时间段内的 `tikv_cop_scan_details`（TiKV 的 cop 请求的 scan ）比 t1 时间段高了 105 倍。
+* t2 时间段内的 `tidb_distsql_partial_scan_key_total_num`（TiDB 的 `distsql` 请求扫描 key 的数量）比 t1 时间段高了 3648 倍。
+t2 时间段内，`tidb_slow_query_cop_wait_total_time`（TiDB 慢查询中的 cop 请求排队等待的耗时）比 t1 时间段高了 267 倍。
+* t2 时间段内的 `tikv_cop_total_response_size`（TiKV 的 cop 请求结果的大小）比 t1 时间段高了 192 倍。
+* t2 时间段内的 `tikv_cop_scan_details`（TiKV 的 cop 请求的 scan）比 t1 时间段高了 105 倍。
 
-综上，我们可以马上知道 t2 时间段的 cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 `cop task` 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。
+综上，可以马上知道 t2 时间段的 cop 请求要比 t2 时间段高很多，导致 TiKV 的 Coprocessor 过载，出现了 `cop task` 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。
 
 实际上，在 t1 ~ t2 整个时间段内都在跑 `go-ycsb` 的压测，然后在 t2 时间段跑了 20 个 `tpch` 的查询，所以是因为 `tpch` 大查询导致了出现很多的 cop 请求。
diff --git a/reference/system-databases/metrics-tables.md b/reference/system-databases/metrics-tables.md
index b157be3ccf9c..e75efc8f9f63 100644
--- a/reference/system-databases/metrics-tables.md
+++ b/reference/system-databases/metrics-tables.md
@@ -1,6 +1,6 @@
 ---
 title: METRICS_TABLES
-summary: 了解 TiDB 集群配置表 `METRICS_TABLES`。
+summary: 了解 TiDB 系统表 `METRICS_TABLES`。
 category: reference
 ---