fix typo error by zhlint(zh.md) (pingcap#6634)

enable-tls-between-clients-and-servers.md

@@ -20,7 +20,7 @@ TiDB 的加密连接支持默认是关闭的，必须在 TiDB 服务端通过配
 1. TiDB 服务端配置开启加密连接的支持
 2. 客户端指定使用加密连接
 
-另外，与 MySQL 一致，TiDB 加密连接是以单个连接为单位的，默认情况下是可选的。因而对于开启了加密连接支持的 TiDB 服务端，客户端既可以选择通过加密连接安全地连接到该 TiDB 服务端，也可以选择使用普通的非加密连接。如需强制要求客户端使用加密连接可以通过以下两种方式进行配置:
+另外，与 MySQL 一致，TiDB 加密连接是以单个连接为单位的，默认情况下是可选的。因而对于开启了加密连接支持的 TiDB 服务端，客户端既可以选择通过加密连接安全地连接到该 TiDB 服务端，也可以选择使用普通的非加密连接。如需强制要求客户端使用加密连接可以通过以下两种方式进行配置：
 
 + 通过在启动参数中配置 `--require-secure-transport` 要求所有用户必须使用加密连接来连接到 TiDB。
 + 通过在创建用户 (`create user`)，赋予权限 (`grant`) 或修改已有用户 (`alter user`) 时指定 `require ssl` 要求指定用户必须使用加密连接来连接 TiDB。以创建用户为例：
@@ -91,7 +91,7 @@ MySQL 5.7 及以上版本自带的客户端默认尝试使用安全连接，若
 
 若在 TiDB 服务端或 MySQL 客户端中未指定 `ssl-ca` 参数，则默认不会进行客户端或服务端身份验证，无法抵御中间人攻击，例如客户端可能会“安全地”连接到了一个伪装的服务端。可以在服务端和客户端中配置 `ssl-ca` 参数进行身份验证。一般情况下只需验证服务端身份，但也可以验证客户端身份进一步增强安全性。
 
-- 若要使 MySQL 客户端验证 TiDB 服务端身份，TiDB 服务端需至少配置 `ssl-cert` 和 `ssl-key` 参数，客户端需至少指定 `--ssl-ca` 参数，且 `--ssl-mode` 至少为 `VERIFY_CA`。必须确保 TiDB 服务端配置的证书（`ssl-cert`）是由客户端 `--ssl-ca` 参数所指定的 CA 所签发的，否则身份验证失败。
+- 若要使 MySQL 客户端验证 TiDB 服务端身份，TiDB 服务端需至少配置 `ssl-cert` 和 `ssl-key` 参数，客户端需至少指定 `--ssl-ca` 参数，且 `--ssl-mode` 至少为 `VERIFY_CA`。必须确保 TiDB 服务端配置的证书 (`ssl-cert`) 是由客户端 `--ssl-ca` 参数所指定的 CA 所签发的，否则身份验证失败。
 - 若要使 TiDB 服务端验证 MySQL 客户端身份，TiDB 服务端需配置 `ssl-cert`、`ssl-key`、`ssl-ca` 参数，客户端需至少指定 `--ssl-cert`、`--ssl-key` 参数。必须确保服务端配置的证书和客户端配置的证书都是由服务端配置指定的 `ssl-ca` 签发的。
 - 若要进行双向身份验证，请同时满足上述要求。
 

encryption-at-rest.md

@@ -59,7 +59,7 @@ region = "us-west-2"
 endpoint = "https://kms.us-west-2.amazonaws.com"
 ```
 
-`key-id` 指定 KMS CMK 的密钥 ID。`region` 为 KMS CMK 的 AWS 区域名。除非你使用非 AWS 提供的 AWS KMS 兼容服务， `endpoint` 通常无需指定。
+`key-id` 指定 KMS CMK 的密钥 ID。`region` 为 KMS CMK 的 AWS 区域名。除非你使用非 AWS 提供的 AWS KMS 兼容服务，`endpoint` 通常无需指定。
 
 若要使用文件方式指定主密钥，主密钥配置应如下所示：
 

error-codes.md

@@ -129,7 +129,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样
 
 * Error Number: 8050
 
-    设置了不支持的权限类型，遇到该错误请参考[TiDB 权限说明](/privilege-management.md#tidb-各操作需要的权限)进行调整。
+    设置了不支持的权限类型，遇到该错误请参考 [TiDB 权限说明](/privilege-management.md#tidb-各操作需要的权限)进行调整。
 
 * Error Number: 8051
 
@@ -259,7 +259,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样
 
 * Error Number: 8200
 
-    尚不支持的 DDL 语法。请参考 [与 MySQL DDL 的兼容性](/mysql-compatibility.md#ddl-的限制)。
+    尚不支持的 DDL 语法。请参考[与 MySQL DDL 的兼容性](/mysql-compatibility.md#ddl-的限制)。
 
 * Error Number: 8214
 

explain-joins.md

@@ -7,7 +7,7 @@ summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划信息。
 
 在 TiDB 中，SQL 优化器需要确定数据表的连接顺序，且要判断对于某条特定的 SQL 语句，哪一种 Join 算法最为高效。
 
-本文档使用的示例数据如下:
+本文档使用的示例数据如下：
 
 {{< copyable "sql" >}}
 

explain-mpp.md

@@ -7,7 +7,7 @@ summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划信息。
 
 TiDB 支持使用 [MPP 模式](/tiflash/use-tiflash.md#使用-mpp-模式)来执行查询。在 MPP 执行模式下，SQL 优化器会生成 MPP 的执行计划。注意 MPP 模式仅对有 [TiFlash](/tiflash/tiflash-overview.md) 副本的表生效。
 
-本文档使用的示例数据如下:
+本文档使用的示例数据如下：
 
 {{< copyable "sql" >}}
 

explain-partitions.md

@@ -7,7 +7,7 @@ summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划信息。
 
 使用 `EXPLAIN` 语句可以查看 TiDB 在执行查询时需要访问的分区。由于存在[分区裁剪](/partition-pruning.md)，所显示的分区通常只是所有分区的一个子集。本文档介绍了常见分区表的一些优化方式，以及如何解读 `EXPLAIN` 语句返回的执行计划信息。
 
-本文档所使用的示例数据如下:
+本文档所使用的示例数据如下：
 
 {{< copyable "sql" >}}
 
@@ -76,7 +76,7 @@ EXPLAIN SELECT COUNT(*) FROM t1 WHERE d = '2017-06-01';
 
 由上述 `EXPLAIN` 结果可知，从最末尾的 `—TableFullScan_19` 算子开始，再返回到根部的 `StreamAgg_21` 算子的执行过程如下：
 
-* TiDB 成功地识别出只需要访问一个分区（`p2017`），并将该信息在 `access object` 列中注明。
+* TiDB 成功地识别出只需要访问一个分区 (`p2017`)，并将该信息在 `access object` 列中注明。
 * `└─TableFullScan_19` 算子先对整个分区进行扫描，然后执行 `└─Selection_20` 算子筛选起始日期为 `2017-06-01 00:00:00.000000` 的行。
 * 之后，`└─Selection_20` 算子匹配的行在 Coprocessor 中进行流式聚合，Coprocessor 本身就可以理解聚合函数 `count`。
 * 每个 Coprocessor 请求会发送一行数据给 TiDB 的 `└─TableReader_22` 算子，然后将数据在 `StreamAgg_21` 算子下进行流式聚合，再将一行数据返回给客户端。

explain-subqueries.md

@@ -7,7 +7,7 @@ summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划信息。
 
 TiDB 会执行多种[子查询相关的优化](/subquery-optimization.md)，以提升子查询的执行性能。本文档介绍一些常见子查询的优化方式，以及如何解读 `EXPLAIN` 语句返回的执行计划信息。
 
-本文档所使用的示例表数据如下:
+本文档所使用的示例表数据如下：
 
 ```sql
 CREATE TABLE t1 (id BIGINT NOT NULL PRIMARY KEY auto_increment, pad1 BLOB, pad2 BLOB, pad3 BLOB, int_col INT NOT NULL DEFAULT 0);

exporting-grafana-snapshots.md

@@ -9,7 +9,7 @@ summary: 了解如何将 Grafana 监控数据导出为快照以及如何将快
 
 ## 使用方法
 
-可以通过访问 <https://metricstool.pingcap.com/> 来使用 MetricsTool。它主要提供以下三种功能：
+可以通过访问 `<https://metricstool.pingcap.com>` 来使用 MetricsTool。它主要提供以下三种功能：
 
 * **导出快照**：提供一段在浏览器开发者工具上运行的用户脚本。你可以使用这个脚本在任意 Grafana v6.x.x 服务器上下载当前 Dashboard 中所有可见面板的快照。
 

expression-syntax.md

@@ -12,7 +12,7 @@ aliases: ['/docs-cn/dev/expression-syntax/','/docs-cn/dev/reference/sql/language
 
 + 标识符，可参考[模式对象名](/schema-object-names.md)。
 + 谓词、数值、字符串、日期表达式等，这些类型的[字面值](/literal-values.md)也是表达式。
-+ 函数调用，窗口函数等。可参考[函数和操作符概述](/functions-and-operators/functions-and-operators-overview.md) 和 [窗口函数](/functions-and-operators/window-functions.md)。
++ 函数调用，窗口函数等。可参考[函数和操作符概述](/functions-and-operators/functions-and-operators-overview.md)和[窗口函数](/functions-and-operators/window-functions.md)。
 + 其他，包括 paramMarker（即 `?`）、系统变量和用户变量、CASE 表达式等。
 
 以下规则是表达式的语法，该语法基于 TiDB parser 的 [parser.y](https://github.com/pingcap/parser/blob/master/parser.y) 文件中所定义的规则。此外，下列语法图的可导航版本请参考 [TiDB SQL 语法图](https://pingcap.github.io/sqlgram/#Expression)。

garbage-collection-configuration.md

@@ -5,7 +5,7 @@ aliases: ['/docs-cn/dev/garbage-collection-configuration/','/docs-cn/dev/referen
 
 # GC 配置
 
-你可以通过以下系统变量进行 GC 配置:
+你可以通过以下系统变量进行 GC 配置：
 
 * [`tidb_gc_enable`](/system-variables.md#tidb_gc_enable-从-v50-版本开始引入)
 * [`tidb_gc_run_interval`](/system-variables.md#tidb_gc_run_interval-从-v50-版本开始引入)
@@ -29,7 +29,7 @@ tikv-ctl --host=ip:port modify-tikv-config -m server -n gc.max_write_bytes_per_s
 
 TiDB 5.0 及之后的版本不再需要向各个 TiKV Region 都发送触发 GC 的请求，因此不再提供 `CENTRAL` GC 模式的支持，取而代之的是效率更高的 `DISTRIBUTED` GC 模式 （自 TiDB 3.0 起的默认 GC 模式）。
 
-如果要了解 TiDB 历史版本中 GC 配置的变化信息，请使用左侧导航栏中的 _TIDB 版本选择器_ 切换到本文档的历史版本。
+如果要了解 TiDB 历史版本中 GC 配置的变化信息，请使用左侧导航栏中的 _"TIDB 版本选择器"_ 切换到本文档的历史版本。
 
 ## GC in Compaction Filter 机制
 

garbage-collection-overview.md

@@ -13,9 +13,9 @@ TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新
 
 GC 会被定期触发。每次 GC 时，首先，TiDB 会计算一个称为 safe point 的时间戳，接下来 TiDB 会在保证 safe point 之后的快照全部拥有正确数据的前提下，删除更早的过期数据。每一轮 GC 分为以下三个步骤：
 
-1. Resolve Locks。该阶段会对所有 Region 扫描 safe point 之前的锁，并清理这些锁。
-2. Delete Ranges。该阶段快速地删除由于 `DROP TABLE`/`DROP INDEX` 等操作产生的整区间的废弃数据。
-3. Do GC。该阶段每个 TiKV 节点将会各自扫描该节点上的数据，并对每一个 key 删除其不再需要的旧版本。
+1. "Resolve Locks" 阶段会对所有 Region 扫描 safe point 之前的锁，并清理这些锁。
+2. "Delete Ranges" 阶段快速地删除由于 `DROP TABLE`/`DROP INDEX` 等操作产生的整区间的废弃数据。
+3. "Do GC" 阶段每个 TiKV 节点将会各自扫描该节点上的数据，并对每一个 key 删除其不再需要的旧版本。
 
 默认配置下，GC 每 10 分钟触发一次，每次 GC 会保留最近 10 分钟内的数据（即默认 GC life time 为 10 分钟，safe point 的计算方式为当前时间减去 GC life time）。如果一轮 GC 运行时间太久，那么在一轮 GC 完成之前，即使到了下一次触发 GC 的时间也不会开始下一轮 GC。另外，为了使持续时间较长的事务能在超过 GC life time 之后仍然可以正常运行，safe point 不会超过正在执行中的事务的开始时间 (start_ts)。
 
@@ -50,4 +50,4 @@ Resolve Locks 有两种执行模式：
 
 > **注意：**
 >
-> 从 TiDB 5.0 版本起，`CENTRAL` GC 模式（需要 TiDB 服务器发送 GC 请求到各个 Region）已经废弃， Do GC 这一步将只以 `DISTRIBUTED` GC 模式（从 TiDB 3.0 版起的默认模式）运行。
+> 从 TiDB 5.0 版本起，`CENTRAL` GC 模式（需要 TiDB 服务器发送 GC 请求到各个 Region）已经废弃，Do GC 这一步将只以 `DISTRIBUTED` GC 模式（从 TiDB 3.0 版起的默认模式）运行。

generate-self-signed-certificates.md

@@ -36,7 +36,7 @@ apt install openssl
 yum install openssl
 ```
 
-也可以参考 OpenSSL 官方的[下载文档](https://www.openssl.org/source/) 进行安装。
+也可以参考 OpenSSL 官方的[下载文档](https://www.openssl.org/source/)进行安装。
 
 ## 生成 CA 证书
 

get-started-with-tispark.md

@@ -23,7 +23,7 @@ aliases: ['/docs-cn/dev/get-started-with-tispark/','/docs-cn/dev/how-to/get-star
 
 ### 在 TiDB 实例上安装 JDK
 
-在 [Oracle JDK 官方下载页面](http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html) 下载 JDK 1.8 当前最新版，本示例中下载的版本为 `jdk-8u141-linux-x64.tar.gz`。
+在 [Oracle JDK 官方下载页面](http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html)下载 JDK 1.8 当前最新版，本示例中下载的版本为 `jdk-8u141-linux-x64.tar.gz`。
 
 解压并根据您的 JDK 部署目录设置环境变量，编辑 `~/.bashrc` 文件，比如：
 

glossary.md

@@ -10,7 +10,7 @@ aliases: ['/docs-cn/dev/glossary/']
 
 ### ACID
 
-ACID 是指数据库管理系统在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性 (atomicity)、一致性 (consistency)、隔离性（isolation）以及持久性（durability）。
+ACID 是指数据库管理系统在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性 (atomicity)、一致性 (consistency)、隔离性 (isolation) 以及持久性 (durability)。
 
 * 原子性 (atomicity) 指一个事务中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。TiDB 通过 Primary Key 所在 [Region](#regionpeerraft-group) 的原子性来保证分布式事务的原子性。
 * 一致性 (consistency) 指在事务开始之前和结束以后，数据库的完整性没有被破坏。TiDB 在写入数据之前，会校验数据的一致性，校验通过才会写入内存并返回成功。

grafana-overview-dashboard.md

@@ -67,7 +67,7 @@ aliases: ['/docs-cn/dev/grafana-overview-dashboard/','/docs-cn/dev/reference/key
 - scheduler pending commands：每个 TiKV 实例上 pending 命令的个数
 - coprocessor executor count：TiKV 每秒收到的 coprocessor 操作数量，按照 coprocessor 类型统计
 - coprocessor request duration：处理 coprocessor 读请求所花费的时间
-- raft store CPU：raftstore 线程的 CPU 使用率，线程数量默认为 2 (通过 `raftstore.store-pool-size` 配置)。如果单个线程使用率超过 80%，说明使用率很高
+- raft store CPU：raftstore 线程的 CPU 使用率，线程数量默认为 2（通过 `raftstore.store-pool-size` 配置）。如果单个线程使用率超过 80%，说明使用率很高
 - Coprocessor CPU：coprocessor 线程的 CPU 使用率
 
 ## System Info

grafana-pd-dashboard.md

@@ -72,7 +72,7 @@ aliases: ['/docs-cn/dev/grafana-pd-dashboard/','/docs-cn/dev/reference/key-monit
 - Store Write rate bytes：每个 TiKV 实例总的写入的流量
 - Store Write rate keys：每个 TiKV 实例总的写入 keys
 - Hot cache write entry number：每个 TiKV 实例进入热点统计模块的 peer 的数量
-- Selector events： 热点调度中选择器的事件发生次数
+- Selector events：热点调度中选择器的事件发生次数
 - Direction of hotspot move leader：热点调度中 leader 的调度方向，正数代表调入，负数代表调出
 - Direction of hotspot move peer：热点调度中 peer 的调度方向，正数代表调入，负数代表调出
 
@@ -137,7 +137,7 @@ aliases: ['/docs-cn/dev/grafana-pd-dashboard/','/docs-cn/dev/reference/key-monit
 
 ## Heartbeat
 
-- Heartbeat region event QPS：心跳处理 region 的 QPS， 包括更新缓存和持久化
+- Heartbeat region event QPS：心跳处理 region 的 QPS，包括更新缓存和持久化
 - Region heartbeat report：TiKV 向 PD 发送的心跳个数
 - Region heartbeat report error：TiKV 向 PD 发送的异常的心跳个数
 - Region heartbeat report active：TiKV 向 PD 发送的正常的心跳个数

grafana-tidb-dashboard.md

@@ -76,11 +76,11 @@ aliases: ['/docs-cn/dev/grafana-tidb-dashboard/','/docs-cn/dev/reference/key-mon
     - Async Commit Transaction Counter：启用 Async commit 机制的事务数量，分为成功、失败两种
 
 - Executor
-    - Parse Duration：SQL 语句解析耗时统计
-    - Compile Duration：将解析后的 SQL AST 编译成执行计划耗时统计
-    - Execution Duration：执行 SQL 语句执行计划耗时统计
-    - Expensive Executor OPS：每秒消耗系统资源比较多的算子统计，包括 Merge Join，Hash Join，Index Look Up Join，Hash Agg，Stream Agg，Sort，TopN 等
-    - Queries Using Plan Cache OPS：每秒使用 Plan Cache 的查询数量统计
+    - Parse Duration：SQL 语句解析耗时统计。
+    - Compile Duration：将解析后的 SQL AST 编译成执行计划耗时统计。
+    - Execution Duration：执行 SQL 语句执行计划耗时统计。
+    - Expensive Executor OPS：每秒消耗系统资源比较多的算子统计。包括 Merge Join、Hash Join、Index Look Up Join、Hash Agg、Stream Agg、Sort、TopN 等。
+    - Queries Using Plan Cache OPS：每秒使用 Plan Cache 的查询数量统计。
 
 - Distsql
     - Distsql Duration：Distsql 处理的时长
@@ -153,7 +153,7 @@ aliases: ['/docs-cn/dev/grafana-tidb-dashboard/','/docs-cn/dev/reference/key-mon
 - GC
     - Worker Action OPM：GC 相关操作的数量，包括 run\_job，resolve\_lock，delete\_range 等操作
     - Duration 99：GC 相关操作的耗时统计
-    - Config：GC 的数据保存时长（life time）和 GC 运行间隔（run interval）配置
+    - Config：GC 的数据保存时长 (life time) 和 GC 运行间隔 (run interval) 配置
     - GC Failure OPM：GC 相关操作失败数量统计
     - Delete Range Failure OPM：Delete range 失败的次数
     - Too Many Locks Error OPM：GC 清锁过多错误的数量

grafana-tikv-dashboard.md

@@ -9,7 +9,7 @@ aliases: ['/docs-cn/dev/grafana-tikv-dashboard/','/docs-cn/dev/reference/key-mon
 
 目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node\_exporter、Overview 等。
 
-对于日常运维，我们通过观察 **TiKV-Details** 面板上的指标，可以了解 TiKV 当前的状态。根据 [性能地图](https://asktug.com/_/tidb-performance-map/#/) 可以检查集群的状态是否符合预期。
+对于日常运维，我们通过观察 **TiKV-Details** 面板上的指标，可以了解 TiKV 当前的状态。根据[性能地图](https://asktug.com/_/tidb-performance-map/#/)可以检查集群的状态是否符合预期。
 
 以下为 **TiKV-Details** 默认的监控信息：
 
@@ -227,7 +227,7 @@ aliases: ['/docs-cn/dev/grafana-tikv-dashboard/','/docs-cn/dev/reference/key-mon
 - TiDB GC seconds：TiDB 执行 GC 花费的时间
 - TiDB GC worker actions：TiDB GC worker 的不同 action 的个数
 - TiKV AutoGC Working：Auto GC 管理器的工作状态
-- ResolveLocks Progress：GC 第一阶段（ResolveLocks）的进度
+- ResolveLocks Progress：GC 第一阶段 (ResolveLocks) 的进度
 - TiKV Auto GC Progress：GC 第二阶段的进度
 - GC speed：GC 每秒删除的 key 的数量
 - TiKV Auto GC SafePoint：TiKV GC 的 safe point 的数值，safe point 为当前 GC 的时间戳
@@ -305,9 +305,9 @@ aliases: ['/docs-cn/dev/grafana-tikv-dashboard/','/docs-cn/dev/reference/key-mon
 - Keys flow：不同操作造成的 key 的流量
 - Total keys：每个 CF 中 key 的个数
 - Read flow：不同读操作的流量
-- Bytes / Read：每次读的大小
+- Bytes/Read：每次读的大小
 - Write flow：不同写操作的流量
-- Bytes / Write：每次写的大小
+- Bytes/Write：每次写的大小
 - Compaction flow：compaction 相关的流量
 - Compaction pending bytes：等待 compaction 的大小
 - Read amplification：每个 TiKV 实例的读放大