maintain: clear up some expressions (#3494)

maintain-tidb-using-tiup.md

@@ -126,7 +126,7 @@ server_configs:
 
 ## Hotfix 版本替换
 
-常规的升级集群请参考[升级文档](/tiup/tiup-cluster.md#升级操作)，但是在某些场景下（例如 Debug），可能需要用一个临时的包替换正在运行的组件，此时可以用 `patch` 命令：
+常规的升级集群请参考[升级文档](/upgrade-tidb-using-tiup.md)，但是在某些场景下（例如 Debug），可能需要用一个临时的包替换正在运行的组件，此时可以用 `patch` 命令：
 
 {{< copyable "shell-root" >}}
 

scale-tidb-using-tiup.md

@@ -87,7 +87,7 @@ pd_servers:
     log_dir: /data/deploy/install/log/pd-2379
 ```
 
-可以使用 `tiup cluster edit-config <cluster-name>` 查看当前集群的配置信息，因为其中的 `global` 和 `server_configs` 参数配置，默认会被 `scale-out.yaml` 继承。
+可以使用 `tiup cluster edit-config <cluster-name>` 查看当前集群的配置信息，因为其中的 `global` 和 `server_configs` 参数配置默认会被 `scale-out.yaml` 继承，因此也会在 `scale-out.yaml` 中生效。
 
 ### 2. 执行扩容命令
 
@@ -373,9 +373,9 @@ tiup cluster display <cluster-name>
 
 3. 等待该 TiFlash 节点对应的 store 消失或者 state_name 变成 Tombstone 再关闭 TiFlash 进程。
 
-   如果等待较长时间后，该节点仍然无法正常消失或者状态变成 Tombstone，可以考虑以下命令，把节点强制踢出集群：
+    如果等待较长时间后，该节点仍然无法正常消失或者状态变成 Tombstone，可以考虑以下命令，把节点强制踢出集群：
 
-   **注意以下命令会直接丢弃该 TiFlash 节点上的副本，有可能导致查询失败**
+    **注意以下命令会直接丢弃该 TiFlash 节点上的副本，有可能导致查询失败**
 
     {{< copyable "shell-regular" >}}
 

upgrade-tidb-using-tiup.md

@@ -24,10 +24,10 @@ aliases: ['/docs-cn/stable/how-to/upgrade/using-tiup/']
     - 仍使用老版本 `'push'` 的方式收集监控指标（从 3.0 默认为 `'pull'` 模式，如果没有特意调整过则可以支持）
     - 在 `inventory.ini` 配置文件中单独为机器的 node_exporter / blackbox_exporter 通过 `node_exporter_port` / `blackbox_exporter_port` 设置了非默认端口（在 `group_vars` 目录中统一配置的可以兼容）
 - 支持 TiDB Binlog，TiCDC，TiFlash 等组件版本的升级。
-- 从 2.0.6 之前的版本升级到 4.0.0 之前，需要确认集群中是否存在正在运行中的 DDL 操作，特别是耗时的 `Add Index` 操作，等 DDL 操作完成后再执行升级操作
-- 2.1 及之后版本启用了并行 DDL，早于 2.0.1 版本的集群，无法滚动升级到 4.0.0 版本，可以选择下面两种方案：
-    - 停机升级，直接从早于 2.0.1 的 TiDB 版本升级到 4.0.0 版本
-    - 先滚动升级到 2.0.1 或者之后的 2.0.x 版本，再滚动升级到 4.0.0 版本
+- 从 2.0.6 之前的版本升级到 4.0 版本之前，需要确认集群中是否存在正在运行中的 DDL 操作，特别是耗时的 `Add Index` 操作，等 DDL 操作完成后再执行升级操作
+- 2.1 及之后版本启用了并行 DDL，早于 2.0.1 版本的集群，无法滚动升级到 4.0 版本，可以选择下面两种方案：
+    - 停机升级，直接从早于 2.0.1 的 TiDB 版本升级到 4.0 版本
+    - 先滚动升级到 2.0.1 或者之后的 2.0.x 版本，再滚动升级到 4.0 版本
 
 > **注意：**
 >
@@ -196,7 +196,7 @@ TiDB Version: v4.0.0
 
 ### 5.1 升级时报错中断，处理完报错后，如何继续升级
 
-重新执行 `upgrade` 命令进行升级。升级操作会重启之前已经升级完成的节点，后续版本支持从中断的位置继续升级。
+重新执行 `tiup cluster upgrade` 命令进行升级，升级操作会重启之前已经升级完成的节点。TiDB 4.0 后续版本将支持从中断的位置继续升级。
 
 ### 5.2 升级过程中 evict leader 等待时间过长，如何跳过该步骤快速升级
 
@@ -226,7 +226,7 @@ TiFlash 在 `v4.0.0-rc.2` 之前的版本可能有一些不兼容的问题。因
 
 - `oom-action` 参数设置为 `cancel` 时，当查询语句触发 OOM 阈值后会被 kill 掉，升级到 4.0 版本后除了 `select` 语句，还可能 kill 掉 `insert`/`update`/`delete` 等 DML 语句。
 - 4.0 版本增加了 `rename` 时对表名长度的检查，长度限制为 `64` 个字符。升级后 `rename` 后的表名长度超过这个限制会报错，3.0 及之前的版本则不会报错。
-- 4.0 版本增加了对分区表的分区名长度的检查，长度限制为 `64` 个字符。升级后 `create table` 和 `alter table` 分区表时当分区名长度超过这个限制会报错，3.0 及之前的版本则不会报错。
+- 4.0 版本增加了对分区表的分区名长度的检查，长度限制为 `64` 个字符。升级后，当你创建和修改分区表时，如果分区名长度超过这个限制会报错，3.0 及之前的版本则不会报错。
 - 4.0 版本对 `explain` 执行计划的输出格式做了改进，需要注意是否有针对 `explain` 制订了自动化的分析程序。
 - 4.0 版本支持 [Read Committed 隔离级别](/transaction-isolation-levels.md#读已提交隔离级别-read-committed)。升级到 4.0 后，在悲观事务里隔离级别设置为 `READ-COMMITTED` 会生效，3.0 及之前的版本则不会生效。
 - 4.0 版本执行 `alter reorganize partition` 会报错，之前的版本则不会报错，只是语法上支持没有实际效果。