add zhmd to ci (pingcap#6697)

.circleci/config.yml

@@ -7,7 +7,6 @@ jobs:
     working_directory: ~/pingcap/docs-cn
     steps:
       - checkout
-
       - run:
           name: Setup
           command: |
@@ -111,12 +110,35 @@ jobs:
 
       - store_artifacts:
           path: /tmp/artifacts
+  zhmd:
+    docker:
+      - image: circleci/node:lts
+    working_directory: ~/pingcap/docs-cn
+    steps:
+      - checkout
+      - run:
+          name: Setup
+          command: |
+            mkdir ~/.npm-global
+            npm config set prefix '~/.npm-global'
+            echo 'export PATH=~/.npm-global/bin:$PATH' >> $BASH_ENV
+            echo 'export NODE_PATH=~/.npm-global/lib/node_modules:$NODE_PATH' >> $BASH_ENV
+      - run:
+          name: "Install Zhmd"
+          command: |
+            npm install -g preset-lint-zh
+      - run:
+          name: "zhmd lint"
+          command: |
+            zhmd -c ~/pingcap/docs-cn/.zhlint.yaml
+
 
 workflows:
   version: 2
   lint:
     jobs:
       - lint
+      - zhmd
   build:
     jobs:
       - build:

.zhlint.yaml

@@ -0,0 +1,55 @@
+includes:
+  - "/*.md"
+  - "s*/*.md"
+ignore:
+  - path: encryption-at-rest.md
+    scope: all
+    ruleId: ZH426
+  # 括号作为开闭区间标记，忽略左右括号匹配
+  - path: sql-statements/sql-statement-split-region.md
+    scope: all
+    ruleId: ZH423
+  - path: experimental-features.md
+    scope: all
+    ruleId: ZH417
+  # 忽略顿号带来的中英文符号检测
+  - path: mysql-compatibility.md
+    scope: all
+    ruleId: ZH417
+  - path: tidb-storage.md
+    scope: line
+    ruleId: ZH423
+    line: 51
+  - path: statistics.md
+    scope: line
+    ruleId: ZH400
+    line: 32
+  - path: tidb-troubleshooting-map.md
+    scope: all
+    ruleId: ZH417
+  - path: sql-statements/sql-statement-show-table-regions.md
+    scope: line
+    line: 165
+    ruleId: ZH423
+  - path: sql-statements/sql-statement-explain-analyze.md
+    scope: all
+    ruleId: ZH403
+  - path: sql-statements/sql-statement-explain-analyze.md
+    scope: all
+    ruleId: ZH428
+  - path: tidb-configuration-file.md
+    scope: line
+    line: 120
+    ruleId: ZH417
+  - path: storage-engine/titan-overview.md
+    line: 77
+    scope: line
+    ruleId: ZH427
+  - path: storage-engine/rocksdb-overview.md 
+    scope: all
+    ruleId: ZH403
+  - path: pd-control.md
+    scope: all
+    ruleId: ZH403
+
+failed_msg: "以上报错结果仅供参考，请 PR 作者二次确认错误信息后再修改文档。"

experimental-features.md

@@ -22,13 +22,13 @@ aliases: ['/docs-cn/dev/experimental-features-4.0/','/zh/tidb/dev/experimental-f
 
 ## SQL 功能
 
-+ List 分区表 （List Partition）。（v5.0 实验特性）
-+ List Column 分区表 （List Column Partition)。（v5.0 实验特性）
++ List 分区表 (List Partition)。（v5.0 实验特性）
++ List Column 分区表 (List Column Partition)。（v5.0 实验特性）
 + [分区表动态裁剪模式](/partitioned-table.md#动态裁剪模式)。（v5.1 实验特性）
 + 表达式索引 (Expression Index) 功能。表达式索引也叫函数索引，在创建索引时索引的字段不一定是一个具体的列，也可以是由一个或者多个列计算出来的表达式。对于快速访问那些基于计算结果的表非常有用。详情参阅：[表达式索引](/sql-statements/sql-statement-create-index.md)。（v4.0 实验特性）
 + [生成列](/generated-columns.md#生成列)。
 + [自定义变量](/user-defined-variables.md#用户自定义变量)。
-+ [JSON 数据类型](/data-type-json.md) 及 [JSON 函数](/functions-and-operators/json-functions.md)。
++ [JSON 数据类型](/data-type-json.md)及 [JSON 函数](/functions-and-operators/json-functions.md)。
 + [View](/information-schema/information-schema-views.md)。
 + [Stale Read](/stale-read.md)。
 

explore-htap.md

@@ -29,7 +29,7 @@ TiDB HATP 可以满足企业海量数据的增产需求、降低运维的风险
 
     当将 TiDB 应用于数据中枢场景时，TiDB 作为数据中枢可以无缝连接数据业务层和数据仓库层，满足不同业务的需求。
 
-如果想了解更多关于 TiDB HTAP  场景信息，请参阅 [PingCAP 官网中关于 HTAP 的博客](https://pingcap.com/blog-cn/#HTAP)。
+如果想了解更多关于 TiDB HTAP 场景信息，请参阅 [PingCAP 官网中关于 HTAP 的博客](https://pingcap.com/blog-cn/#HTAP)。
 
 ## HTAP 架构
 
@@ -49,7 +49,7 @@ TiDB HATP 可以满足企业海量数据的增产需求、降低运维的风险
 
         - 如果业务场景以 OLTP 为主，做轻量级的 Ad hoc OLAP 计算，通常部署 1 个或几个 TiFlash 节点就会产生明显的加速效果。
         - 当 OLTP 数据吞吐量对节点 I/O 无明显压力时，每个 TiFlash 节点将会使用较多资源用于计算，这样 TiFlash 集群可实现近似线性的扩展能力。TiFlash 节点数量应根据期待的性能和响应时间调整。
-        - 当 OLTP 数据吞吐量较高时（例如写入或更新超过千万行/小时），由于网络和物理磁盘的写入能力有限，内部 TiKV 与 TiFlash 之间的 I/O 会成为主要瓶颈，也容易产生读写热点。此时TiFlash 节点数与 OLAP 计算量有较复杂非线性关系，需要根据具体系统状态调整节点数量。
+        - 当 OLTP 数据吞吐量较高时（例如写入或更新超过千万行/小时），由于网络和物理磁盘的写入能力有限，内部 TiKV 与 TiFlash 之间的 I/O 会成为主要瓶颈，也容易产生读写热点。此时 TiFlash 节点数与 OLAP 计算量有较复杂非线性关系，需要根据具体系统状态调整节点数量。
 
 - TiSpark
 
@@ -84,7 +84,7 @@ TiFlash 部署完成后并不会自动同步数据，你需要指定需要同步
 - [TiDB Dashboard](/dashboard/dashboard-intro.md)：查看集群整体运行概况，分析集群读写流量分布及趋势变化，详细了解耗时较长的 SQL 语句的执行信息。
 - [监控系统 (Prometheus & Grafana)](/grafana-overview-dashboard.md)：查看 TiDB 集群各组件（包括 PD、TiDB、TiKV、TiFlash、TiCDC、Node_exporter）的相关监控参数。
 
-如需查看 TiDB 和 TiFlash 集群报警规则和处理方法，请查阅 [TiDB 集群报警规则](/alert-rules.md) 和 [TiFlash 报警规则](/tiflash/tiflash-alert-rules.md)。
+如需查看 TiDB 和 TiFlash 集群报警规则和处理方法，请查阅 [TiDB 集群报警规则](/alert-rules.md)和 [TiFlash 报警规则](/tiflash/tiflash-alert-rules.md)。
 
 ## HTAP 故障诊断
 

mysql-compatibility.md

@@ -6,7 +6,7 @@ aliases: ['/docs-cn/dev/mysql-compatibility/','/docs-cn/dev/reference/mysql-comp
 
 # 与 MySQL 兼容性对比
 
-- TiDB 100% 兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL 5.7 生态中的系统工具 (PHPMyAdmin、Navicat、MySQL Workbench、 mysqldump、Mydumper/Myloader)、客户端等均适用于 TiDB。
+- TiDB 100% 兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL 5.7 生态中的系统工具 (PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader)、客户端等均适用于 TiDB。
 
 - 但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下：
     - 有更好的解决方案，例如 JSON 取代 XML 函数。

pd-control.md

@@ -671,7 +671,7 @@ time: 43.12698ms
 
 ### `region <region_id> [--jq="<query string>"]`
 
-用于显示 Region 信息。使用 jq 格式化输出请参考 [jq-格式化-json-输出示例](#jq-格式化-json-输出示例)。示例如下。
+用于显示 Region 信息。使用 jq 格式化输出请参考 [jq 格式化 json 输出示例](#jq-格式化-json-输出示例)。示例如下。
 
 显示所有 Region 信息：
 
@@ -1055,7 +1055,7 @@ Encoding 格式示例：
 
 ### `store [delete | label | weight | remove-tombstone | limit | limit-scene] <store_id> [--jq="<query string>"]`
 
-用于显示 store 信息或者删除指定 store。使用 jq 格式化输出请参考 [jq-格式化-json-输出示例](#jq-格式化-json-输出示例)。示例如下。
+用于显示 store 信息或者删除指定 store。使用 jq 格式化输出请参考 [jq 格式化 json 输出示例](#jq-格式化-json-输出示例)。示例如下。
 
 显示所有 store 信息：
 

quick-start-with-htap.md

@@ -30,7 +30,7 @@ summary: 本文介绍如何快速上手体验 TiDB 的 HTAP 功能。
 
 在 [TiDB 数据库快速上手指南](/quick-start-with-tidb.md)中：
 
-- 推荐直接执行 `tiup playground` 命令启动最新版本的 TiDB 集群，此命令将自动部署 TiDB、TiKV、PD 和 TiFlash 实例各 1 个:
+- 推荐直接执行 `tiup playground` 命令启动最新版本的 TiDB 集群，此命令将自动部署 TiDB、TiKV、PD 和 TiFlash 实例各 1 个：
 
     {{< copyable "shell-regular" >}}
 
@@ -102,7 +102,7 @@ summary: 本文介绍如何快速上手体验 TiDB 的 HTAP 功能。
     8 rows in set (0.06 sec)
      ```
 
-    这是一个商业订购系统的数据库。其中，`test.nation` 表是国家信息、`test.region` 表是地区信息，`test.part` 表是零件信息，`test.supplier` 表是供货商信息，`test.partsupp` 表是供货商的零件信息，`test.customer` 表是消费者信息，`test.orders` 表是订单信息，`test.lineitem` 表是在线商品的信息。
+    这是一个商业订购系统的数据库。其中，`test.nation` 表是国家信息、`test.region` 表是地区信息、`test.part` 表是零件信息、`test.supplier` 表是供货商信息、`test.partsupp` 表是供货商的零件信息、`test.customer` 表是消费者信息、`test.orders` 表是订单信息、`test.lineitem` 表是在线商品的信息。
 
 ### 第 3 步：使用行存查询数据
 

sql-statements/sql-statement-explain-analyze.md

@@ -154,9 +154,9 @@ prepare:109.616µs, check_insert:{total_time:1.431678ms, mem_insert_time:667.878
 `IndexJoin` 算子有 1 个 outer worker 和 N 个 inner worker 并行执行，其 join 结果的顺序和 outer table 的顺序一致，具体执行流程如下：
 
 1. Outer worker 读取 N 行 outer table 的数据，然后包装成一个 task 发送给 result channel 和 inner worker channel。
-2. Inner worker 从 inner worker channel 里面接收 task，然后根据 task 生成需要读取 inner table 的 key ranges 范围, 然后读取相应范围的 inner table 行数据，并生成一个 inner table row 的 hash table。
+2. Inner worker 从 inner worker channel 里面接收 task，然后根据 task 生成需要读取 inner table 的 key ranges 范围，然后读取相应范围的 inner table 行数据，并生成一个 inner table row 的 hash table。
 3. `IndexJoin` 的主线程从 result channel 中接收 task，然后等待 inner worker 执行完这个 task。
-4. `IndexJoin` 的主线程用 outer table rows 和 inner table rows 的 hash table 做 join 。
+4. `IndexJoin` 的主线程用 outer table rows 和 inner table rows 的 hash table 做 join。
 
 `IndexJoin` 算子包含以下执行信息：
 

storage-engine/rocksdb-overview.md

@@ -20,7 +20,7 @@ TiKV 的系统架构如下图所示：
 RocksDB 作为 TiKV 的核心存储引擎，用于存储 Raft 日志以及用户数据。每个 TiKV 实例中有两个 RocksDB 实例，一个用于存储 Raft 日志（通常被称为 raftdb），另一个用于存储用户数据以及 MVCC 信息（通常被称为 kvdb）。kvdb 中有四个 ColumnFamily：raft、lock、default 和 write：
 
 * raft 列：用于存储各个 Region 的元信息。仅占极少量空间，用户可以不必关注。 
-* lock 列：用于存储悲观事务的悲观锁以及分布式事务的一阶段 Prewrite 锁。当用户的事务提交之后， lock cf 中对应的数据会很快删除掉，因此大部分情况下 lock cf 中的数据也很少（少于 1GB）。如果 lock cf 中的数据大量增加，说明有大量事务等待提交，系统出现了 bug 或者故障。
+* lock 列：用于存储悲观事务的悲观锁以及分布式事务的一阶段 Prewrite 锁。当用户的事务提交之后，lock cf 中对应的数据会很快删除掉，因此大部分情况下 lock cf 中的数据也很少（少于 1GB）。如果 lock cf 中的数据大量增加，说明有大量事务等待提交，系统出现了 bug 或者故障。
 * write 列：用于存储用户真实的写入数据以及 MVCC 信息（该数据所属事务的开始时间以及提交时间）。当用户写入了一行数据时，如果该行数据长度小于 255 字节，那么会被存储 write 列中，否则的话该行数据会被存入到 default 列中。由于 TiDB 的非 unique 索引存储的 value 为空，unique 索引存储的 value 为主键索引，因此二级索引只会占用 writecf 的空间。
 * default 列：用于存储超过 255 字节长度的数据。 
 
@@ -35,7 +35,7 @@ BlockCache 按照 LRU 算法淘汰低频访问的数据，TiKV 默认将系统
 ## RocksDB 的空间占用
 
 * 多版本：RocksDB 作为一个 LSM-tree 结构的键值存储引擎，MemTable 中的数据会首先被刷到 L0。L0 层的 SST 之间的范围可能存在重叠（因为文件顺序是按照生成的顺序排列），因此同一个 key 在 L0 中可能存在多个版本。当文件从 L0 合并到 L1 的时候，会按照一定大小（默认是 8MB）切割为多个文件，同一层的文件的范围互不重叠，所以 L1 及其以后的层每一层的 key 都只有一个版本。
-* 空间放大：RocksDB 的每一层文件总大小都是上一层的 x 倍，在 TiKV 中这个配置默认是 10，因此 90% 的数据存储在最后一层，这也意味着 RocksDB 的空间放大不超过 1.11 (L0 层的数据较少，可以忽略不计)
+* 空间放大：RocksDB 的每一层文件总大小都是上一层的 x 倍，在 TiKV 中这个配置默认是 10，因此 90% 的数据存储在最后一层，这也意味着 RocksDB 的空间放大不超过 1.11（L0 层的数据较少，可以忽略不计）。
 * TiKV 的空间放大：TiKV 在 RocksDB 之上还有一层自己的 MVCC，当用户写入一个 key 的时候，实际上写入到 RocksDB 的是 key + commit_ts，也就是说，用户的更新和删除都是会写入新的 key 到 RocksDB。TiKV 每隔一段时间会删除旧版本的数据（通过 RocksDB 的 Delete 接口），因此可以认为用户存储在 TiKV 上的数据的实际空间放大为，1.11 加最近 10 分钟内写入的数据（假设 TiKV 回收旧版本数据足够及时）。详情见[《TiDB in Action》](https://github.com/pingcap-incubator/tidb-in-action/blob/master/session4/chapter7/compact.md#tikv-%E7%9A%84%E7%A9%BA%E9%97%B4%E6%94%BE%E5%A4%A7)。
 
 ## RocksDB 后台线程与 Compact

storage-engine/titan-configuration.md

@@ -30,7 +30,7 @@ Titan 对 RocksDB 兼容，也就是说，使用 RocksDB 存储引擎的现有 T
 
     具体命令，可参考[通过 TiUP 修改配置参数](/maintain-tidb-using-tiup.md#修改配置参数)。
 
-+ 方法二：直接编辑 TiKV 配置文件开启 Titan（生产环境不推荐)。
++ 方法二：直接编辑 TiKV 配置文件开启 Titan（生产环境不推荐）。
 
     {{< copyable "" >}}
 

storage-engine/titan-overview.md

@@ -66,7 +66,7 @@ TitanTableBuilder 是实现分离 key-value 的关键，它通过判断 value si
 Garbage Collection (GC) 的目的是回收空间。由于在 LSM-tree compaction 进行回收 key 时，储存在 blob 文件中的 value 并不会一同被删除，因此需要 GC 定期来将已经作废的 value 删除掉。在 Titan 中有两种 GC 方式可供选择：
 
 - 定期整合重写 Blob 文件将作废的 value 剔除（传统 GC）
-- 在 LSM-tree compaction 的时候同时进行 blob 文件的重写（Level-Merge）
+- 在 LSM-tree compaction 的时候同时进行 blob 文件的重写 (Level-Merge)
 
 ### 传统 GC
 

sync-diff-inspector/sync-diff-inspector-overview.md

@@ -46,25 +46,25 @@ sync-diff-inspector 需要获取表结构信息、查询数据、建 checkpoint
 
     - SELECT（查数据进行对比）
 
-    - SHOW_DATABASES (查看库名)
+    - SHOW_DATABASES（查看库名）
 
-    - RELOAD (查看表结构)
+    - RELOAD（查看表结构）
 
 - 下游数据库
 
-    - SELECT （查数据进行对比）
+    - SELECT（查数据进行对比）
 
-    - CREATE （创建 checkpoint 库和表）
+    - CREATE（创建 checkpoint 库和表）
 
-    - DELETE （删除 checkpoint 表中的信息）
+    - DELETE（删除 checkpoint 表中的信息）
 
-    - INSERT  （写入 checkpoint 表）
+    - INSERT（写入 checkpoint 表）
 
     - UPDATE（修改 checkpoint 表）
 
-    - SHOW_DATABASES (查看库名)
+    - SHOW_DATABASES（查看库名）
 
-    - RELOAD (查看表结构)
+    - RELOAD（查看表结构）
 
 ### 配置文件说明
 

system-variables.md

@@ -281,7 +281,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数
 - 作用域：SESSION | GLOBAL
 - 默认值：`2`
 - 范围：`[1, 2147483647]`
-- 这个变量用来给 TiDB 的 `backoff` 最大时间增加权重，即内部遇到网络或其他组件（TiKV、PD）故障时，发送重试请求的最大重试时间。可以通过这个变量来调整最大重试时间，最小值为 1。
+- 这个变量用来给 TiDB 的 `backoff` 最大时间增加权重，即内部遇到网络或其他组件 (TiKV, PD) 故障时，发送重试请求的最大重试时间。可以通过这个变量来调整最大重试时间，最小值为 1。
 
     例如，TiDB 向 PD 取 TSO 的基础超时时间是 15 秒，当 `tidb_backoff_weight = 2` 时，取 TSO 的最大超时时间为：基础时间 \* 2 等于 30 秒。
 
@@ -503,7 +503,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数
 
 - 作用域：SESSION | GLOBAL
 - 默认值：`INT_ONLY`
-- 可选值： `OFF`，`ON`，`INT_ONLY`
+- 可选值：`OFF`，`ON`，`INT_ONLY`
 - 这个变量用于控制默认情况下表的主键是否使用[聚簇索引](/clustered-indexes.md)。“默认情况”即不显式指定 `CLUSTERED`/`NONCLUSTERED` 关键字的情况。可设置为 `OFF`/`ON`/`INT_ONLY`。
     - `OFF` 表示所有主键默认使用非聚簇索引。
     - `ON` 表示所有主键默认使用聚簇索引。
@@ -612,7 +612,7 @@ Query OK, 0 rows affected (0.09 sec)
 
 - 作用域：SESSION | GLOBAL
 - 默认值：`ON`
-- 可选值： `OFF`，`ON`，`AUTO`
+- 可选值：`OFF`，`ON`，`AUTO`
 - 这个变量用来设置是否开启 `TABLE PARTITION` 特性。目前变量支持以下三种值：
     - 默认值 `ON` 表示开启 TiDB 当前已实现了的分区表类型，目前 Range partition、Hash partition 以及 Range column 单列的场景会生效。
     - `AUTO` 目前作用和 `ON` 一样。
@@ -769,7 +769,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告）
 
 - 作用域：GLOBAL
 - 默认值：`LEGACY`
-- 可设置为： `PHYSICAL`，`LEGACY`
+- 可设置为：`PHYSICAL`，`LEGACY`
     - `LEGACY`：使用旧的扫描方式，即禁用 Green GC。
     - `PHYSICAL`：使用物理扫描方式，即启用 Green GC。
 - 这个变量用于指定垃圾回收 (GC) 的 Resolve Locks（清理锁）步骤中扫描锁的方式。当变量值设置为 `LEGACY` 时，TiDB 以 Region 为单位进行扫描。当变量值设置为 `PHYSICAL` 时，每个 TiKV 节点分别绕过 Raft 层直接扫描数据，可以有效地缓解在启用 [Hibernate Region](/tikv-configuration-file.md#hibernate-regions) 功能时，GC 唤醒全部 Region 的影响，从而提升 Resolve Locks（清理锁）这个步骤的执行速度。
@@ -1292,7 +1292,7 @@ set tidb_slow_log_threshold = 200;
 
 - 作用域：SESSION | GLOBAL
 - 默认值：`pessimistic`
-- 可选值： `pessimistic`，`optimistic`
+- 可选值：`pessimistic`，`optimistic`
 - 这个变量用于设置事务模式。TiDB v3.0 支持了悲观事务，自 v3.0.8 开始，默认使用[悲观事务模式](/pessimistic-transaction.md)。
 - 但如果从 3.0.7 及之前的版本升级到 >= 3.0.8 的版本，不会改变默认事务模型，即**只有新创建的集群才会默认使用悲观事务模型**。
 - 将该变量设置为 "optimistic" 或 "" 时，将会使用[乐观事务模式](/optimistic-transaction.md)。
@@ -1372,7 +1372,7 @@ set tidb_slow_log_threshold = 200;
 
 ### `warning_count`
 
-- 作用域: SESSION
+- 作用域：SESSION
 - 默认值：`0`
 - 这个只读变量表示之前执行语句中出现的警告数。