*: optimize anchor text of 68 links for SEO (pingcap#1992)

dev/benchmark/how-to-run-sysbench.md

@@ -5,7 +5,7 @@ category: benchmark
 
 # 如何用 Sysbench 测试 TiDB
 
-本次测试使用的是 TiDB 3.0 Beta 和 Sysbench 1.0.14。建议使用 Sysbench 1.0 或之后的更新版本，可在[此处](https://github.com/akopytov/sysbench/releases/tag/1.0.14)下载。
+本次测试使用的是 TiDB 3.0 Beta 和 Sysbench 1.0.14。建议使用 Sysbench 1.0 或之后的更新版本，可在 [Sysbench Release 1.0.14 页面](https://github.com/akopytov/sysbench/releases/tag/1.0.14)下载。
 
 ## 测试环境
 

dev/faq/tidb.md

@@ -11,7 +11,7 @@ category: FAQ
 
 #### 1.1.1 TiDB 整体架构
 
-[https://pingcap.com/docs-cn/dev/overview/](/dev/overview.md#tidb-简介)
+[TiDB 简介](/dev/overview.md#tidb-简介)
 
 #### 1.1.2 TiDB 是什么？
 
@@ -137,19 +137,19 @@ TiDB 的 sql_mode 与 MySQL 的 sql_mode 设置方法有一些差别，TiDB 不
 
 ##### 1.2.1.1 TiKV 详细解读
 
-[http://t.cn/RTKRRWv](http://t.cn/RTKRRWv)
+[三篇文章了解 TiDB 技术内幕 - 说存储](http://t.cn/RTKRRWv)
 
 #### 1.2.2 计算 TiDB
 
 ##### 1.2.2.1 TiDB 详细解读
 
-[http://t.cn/RTKRkBh](http://t.cn/RTKRkBh)
+[三篇文章了解 TiDB 技术内幕 - 说计算](http://t.cn/RTKRkBh)
 
 #### 1.2.3 调度 PD
 
 ##### 1.2.3.1 PD 详细解读
 
-[http://t.cn/RTKEZ0U](http://t.cn/RTKEZ0U)
+[三篇文章了解 TiDB 技术内幕 - 谈调度](http://t.cn/RTKEZ0U)
 
 ## 二、安装部署升级
 
@@ -214,7 +214,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器
 
 ##### 2.2.1.1 为什么修改了 TiKV/PD 的 toml 配置文件，却没有生效？
 
-这种情况一般是因为没有使用 `--config` 参数来指定配置文件（目前只会出现在 binary 部署的场景），TiKV/PD 会按默认值来设置。如果要使用配置文件，请设置 TiKV/PD 的 `--config` 参数。对于 TiKV 组件，修改配置后重启服务即可；对于 PD 组件，只会在第一次启动时读取配置文件，之后可以使用 pd-ctl 的方式来修改配置，详情可参考[这里](/dev/reference/configuration/pd-server/configuration.md)。
+这种情况一般是因为没有使用 `--config` 参数来指定配置文件（目前只会出现在 binary 部署的场景），TiKV/PD 会按默认值来设置。如果要使用配置文件，请设置 TiKV/PD 的 `--config` 参数。对于 TiKV 组件，修改配置后重启服务即可；对于 PD 组件，只会在第一次启动时读取配置文件，之后可以使用 pd-ctl 的方式来修改配置，详情可参考 [PD 配置参数](/dev/reference/configuration/pd-server/configuration.md)。
 
 ##### 2.2.1.2 TiDB 监控框架 Prometheus + Grafana 监控机器建议单独还是多台部署？
 
@@ -252,7 +252,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器
 
 #### 2.2.2 TiDB 离线 Ansible 部署方案
 
-首先这不是我们建议的方式，如果中控机没有外网，也可以通过离线 Ansible 部署方式，详情可参考[这里](/dev/how-to/deploy/orchestrated/offline-ansible.md)。
+首先这不是我们建议的方式，如果中控机没有外网，也可以通过离线 Ansible 部署方式，详情可参考[离线 TiDB Ansible 部署方案](/dev/how-to/deploy/orchestrated/offline-ansible.md)。
 
 #### 2.2.3 Docker Compose 快速构建集群（单机部署）
 
@@ -420,7 +420,7 @@ TiDB 目前社区非常活跃，在 1.0 GA 版本发布后，还在不断的优
 
 #### 3.1.14 Percolator 用了分布式锁，crash 的客户端会保持锁，会造成锁没有 release？
 
-详细可参考 [https://pingcap.com/blog-cn/percolator-and-txn/](https://pingcap.com/blog-cn/percolator-and-txn/)。
+详细可参考 [Percolator 和 TiDB 事务算法](https://pingcap.com/blog-cn/percolator-and-txn/)。
 
 #### 3.1.15 TiDB 为什么选用 gRPC 而不选用 Thrift，是因为 Google 在用吗？
 
@@ -700,7 +700,7 @@ TiKV 的内存占用主要来自于 RocksDB 的 block-cache，默认为系统总
 #### 3.5.2 TiDB 集群容量 QPS 与节点数之间关系如何，和 MySQL 对比如何？
 
 - 在 10 节点内，TiDB 写入能力（Insert TPS）和节点数量基本成 40% 线性递增，MySQL 由于是单节点写入，所以不具备写入扩展能力。
-- MySQL 读扩容可以通过添加从库进行扩展，但写流量无法扩展，只能通过分库分表，而分库分表有很多问题，具体参考 [http://t.cn/RTD18qV](http://t.cn/RTD18qV)。
+- MySQL 读扩容可以通过添加从库进行扩展，但写流量无法扩展，只能通过分库分表，而分库分表有很多问题，具体参考[方案虽好，成本先行：数据库 Sharding+Proxy 实践解析](http://t.cn/RTD18qV)。
 - TiDB 不管是读流量、还是写流量都可以通过添加节点快速方便的进行扩展。
 
 #### 3.5.3 我们的 DBA 测试过 MySQL 性能，单台 TiDB 的性能没有 MySQL 性能那么好？

dev/how-to/get-started/tispark.md

@@ -209,4 +209,4 @@ scala> spark.sql(
 -----------------+---------+------------+--------+-----------+
 ```
 
-更多样例请参考 [https://github.com/pingcap/tispark-test/tree/master/tpch/sparksql](https://github.com/pingcap/tispark-test/tree/master/tpch/sparksql)
+更多样例请参考 [`pingcap/tispark-test`](https://github.com/pingcap/tispark-test/tree/master/tpch/sparksql)

dev/how-to/maintain/backup-and-restore.md

@@ -48,7 +48,7 @@ cd tidb-enterprise-tools-latest-linux-amd64
 
 ## 使用 `mydumper`/`loader` 全量备份恢复数据
 
-`mydumper` 是一个强大的数据备份工具，具体可以参考 [https://github.com/maxbube/mydumper](https://github.com/maxbube/mydumper)。
+`mydumper` 是一个强大的数据备份工具，具体可以参考 [`maxbube/mydumper`](https://github.com/maxbube/mydumper)。
 
 可使用 [`mydumper`](/dev/reference/tools/mydumper.md) 从 TiDB 导出数据进行备份，然后用 [`loader`](/dev/reference/tools/loader.md) 将其导入到 TiDB 里面进行恢复。
 

dev/how-to/migrate/from-mysql.md

@@ -5,7 +5,7 @@ category: how-to
 
 # 全量数据迁移
 
-`mydumper` 是一个强大的数据迁移工具，具体可以参考 [https://github.com/maxbube/mydumper](https://github.com/maxbube/mydumper)。你可以使用 `mydumper` 从 MySQL 导出数据，然后用 `loader` 将其导入到 TiDB。
+`mydumper` 是一个强大的数据迁移工具，具体可以参考 [`maxbube/mydumper`](https://github.com/maxbube/mydumper)。你可以使用 `mydumper` 从 MySQL 导出数据，然后用 `loader` 将其导入到 TiDB。
 
 > **注意：**
 >

dev/reference/configuration/pd-server/configuration-file.md

@@ -9,7 +9,7 @@ category: reference
 
 PD 配置文件比命令行参数支持更多的选项。你可以在 [conf/config.toml](https://github.com/pingcap/pd/blob/master/conf/config.toml) 找到默认的配置文件。
 
-本文档只阐述未包含在命令行参数中的参数，命令行参数参见[这里](/dev/reference/configuration/pd-server/configuration.md)。
+本文档只阐述未包含在命令行参数中的参数，命令行参数参见 [PD 配置参数](/dev/reference/configuration/pd-server/configuration.md)。
 
 ### `lease`
 

dev/reference/configuration/tidb-server/tidb-specific-variables.md

@@ -216,7 +216,7 @@ set @@global.tidb_distsql_scan_concurrency = 10;
 
 默认值：0
 
-这个变量用来设置是否自动切分待删除的数据。仅在 autocommit 开启，并且是单表删除的 SQL 时有效。关于单表删除的 SQL 的定义，详见[这里](https://dev.mysql.com/doc/refman/8.0/en/delete.html)。
+这个变量用来设置是否自动切分待删除的数据。仅在 autocommit 开启，并且是单表删除的 SQL 时有效。关于单表删除的 SQL 的定义，详见 [`DELETE` Syntax](https://dev.mysql.com/doc/refman/8.0/en/delete.html)。
 当删除大量数据时，可以将其设置为 1，这样待删除数据会被自动切分为多个 batch，每个 batch 使用一个单独的事务进行删除。
 该用法破坏了事务的原子性和隔离性，使用该特性时，使用者需要保证没有其他对正在处理的表的**任何**操作，并且在出现报错时，需要及时**人工介入，检查数据的一致性和完整性**。因此，不建议在生产环境中使用。
 

dev/reference/configuration/tikv-server/configuration-file.md

@@ -7,7 +7,7 @@ category: reference
 
 TiKV 配置文件比命令行参数支持更多的选项。你可以在 [etc/config-template.toml](https://github.com/tikv/tikv/blob/master/etc/config-template.toml) 找到默认值的配置文件，重命名为 config.toml 即可。
 
-本文档只阐述未包含在命令行参数中的参数，命令行参数参见[这里](/dev/reference/configuration/tikv-server/configuration.md)。
+本文档只阐述未包含在命令行参数中的参数，命令行参数参见 [TiKV 配置参数](/dev/reference/configuration/tikv-server/configuration.md)。
 
 <!-- markdownlint-disable MD001 -->
 ### `status-thread-pool-size`

dev/reference/sql/language-structure/comment-syntax.md

@@ -119,6 +119,6 @@ SELECT /*+ hint */ FROM ...;
 
 由于 hint 包含在类似 /*+ xxx */ 的 comment 里，MySQL 客户端在 5.7.7 之前，会默认把 comment 清除掉，如果需要在旧的客户端使用 hint，需要在启动客户端时加上 --comments 选项，例如 mysql -h 127.0.0.1 -P 4000 -uroot --comments
 
-TiDB 支持的相关优化器 hint 详见[这里](/dev/reference/performance/optimizer-hints.md)
+TiDB 支持的相关优化器 hint 详见 [Optimizer Hints](/dev/reference/performance/optimizer-hints.md)。
 
 更多[细节](https://dev.mysql.com/doc/refman/5.7/en/comments.html)。

dev/reference/tispark.md

@@ -77,7 +77,7 @@ spark.sql.extensions org.apache.spark.sql.TiExtensions
 
 ## 部署 TiSpark
 
-TiSpark 的 jar 包可以在[这里](https://github.com/pingcap/tispark/releases)下载对应版本的 jar 包并拷贝到合适的目录。
+TiSpark 的 jar 包可以在 [TiSpark Releases 页面](https://github.com/pingcap/tispark/releases)下载对应版本的 jar 包并拷贝到合适的目录。
 
 ### 已有 Spark 集群的部署方式
 
@@ -95,7 +95,7 @@ spark-shell --jars $TISPARK_FOLDER/tispark-${name_with_version}.jar
 
 #### 下载安装包并安装
 
-你可以在[这里](https://spark.apache.org/downloads.html)下载 Apache Spark。
+你可以在 [Download Apache Spark™ 页面](https://spark.apache.org/downloads.html)下载 Apache Spark。
 
 对于 Standalone 模式且无需 Hadoop 支持，则选择 Spark 2.3.x 或者 Spark 2.4.x 且带有 Hadoop 依赖的 Pre-build with Apache Hadoop 2.x 任意版本。如有需要配合使用的 Hadoop 集群，则选择对应的 Hadoop 版本号。你也可以选择从源代码[自行构建](https://spark.apache.org/docs/latest/building-spark.html)以配合官方 Hadoop 2.x 之前的版本。
 

dev/tidb-in-kubernetes/deploy/prerequisites.md

@@ -72,7 +72,7 @@ free -m
 
 ## 硬件和部署要求
 
-与使用 binary 方式部署 TiDB 集群一致，要求选用 Intel x86-64 架构的 64 位通用硬件服务器，使用万兆网卡。关于 TiDB 集群在物理机上的具体部署需求，参考[这里](/dev/how-to/deploy/hardware-recommendations.md)。
+与使用 binary 方式部署 TiDB 集群一致，要求选用 Intel x86-64 架构的 64 位通用硬件服务器，使用万兆网卡。关于 TiDB 集群在物理机上的具体部署需求，参考 [TiDB 软件和硬件环境建议配置](/dev/how-to/deploy/hardware-recommendations.md)。
 
 对于服务器 disk、memory、CPU 的选择要根据对集群的容量规划以及部署拓扑来定。线上 Kubernetes 集群部署为了保证高可用，一般需要部署三个 master 节点、三个 etcd 节点以及若干个 worker 节点。同时，为了充分利用机器资源，master 节点一般也充当 worker 节点（也就是 master 节点上也可以调度负载）。通过 kubelet 设置[预留资源](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/)来保证机器上的系统进程以及 Kubernetes 的核心进程在工作负载很高的情况下仍然有足够的资源来运行，从而保证整个系统的稳定。
 
@@ -96,7 +96,7 @@ TiDB 集群由 PD、TiKV、TiDB 三个组件组成，在做容量规划的时候
 
 - PD 组件：PD 占用资源较少，这种集群规模下分配 2C 4GB 即可，占用少量本地盘。
 
-    为了便于管理，可以将所有集群的 PD 都放在 master 节点，比如需要支持 5 套 TiDB 集群，则可以规划 3 个 master 节点，每个节点支持部署 5 个 PD 实例，5 个 PD 实例使用同一块 SSD 盘即可（两三百 GB 的盘即可）。通过 bind mount 的方式在这块 SSD 上创建 5 个目录作为挂载点，操作方式见[文档](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/docs/operations.md#sharing-a-disk-filesystem-by-multiple-filesystem-pvs)。
+    为了便于管理，可以将所有集群的 PD 都放在 master 节点，比如需要支持 5 套 TiDB 集群，则可以规划 3 个 master 节点，每个节点支持部署 5 个 PD 实例，5 个 PD 实例使用同一块 SSD 盘即可（两三百 GB 的盘即可）。通过 bind mount 的方式在这块 SSD 上创建 5 个目录作为挂载点，操作方式见 [Sharing a disk filesystem by multiple filesystem PVs](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/docs/operations.md#sharing-a-disk-filesystem-by-multiple-filesystem-pvs)。
 
     如果后续要添加更多机器支持更多的 TiDB 集群，可以在 master 上用这种方式继续增加 PD 实例。如果 master 上资源耗尽，可以找其它的 worker 节点机器用同样的方式添加 PD 实例。这种方式的好处就是方便规划和管理 PD 实例，坏处就是由于 PD 实例过于集中，这些机器中如果有两台宕机会导致所有的 TiDB 集群不可用。
 

dev/tidb-in-kubernetes/deploy/tidb-operator.md

@@ -25,7 +25,7 @@ TiDB Operator 部署前，请确认以下软件需求：
 
 ## 部署 Kubernetes 集群
 
-TiDB Operator 运行在 Kubernetes 集群，你可以使用[这里](https://kubernetes.io/docs/setup/)列出的任何一种方法搭建一套 Kubernetes 集群。只要保证 Kubernetes 版本大于等于 v1.12。如果你使用 AWS、GKE 或者本机，下面是快速上手教程：
+TiDB Operator 运行在 Kubernetes 集群，你可以使用 [Getting started 页面](https://kubernetes.io/docs/setup/)列出的任何一种方法搭建一套 Kubernetes 集群。只要保证 Kubernetes 版本大于等于 v1.12。如果你使用 AWS、GKE 或者本机，下面是快速上手教程：
 
 * [Local DinD 教程](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-dind.md)
 * [Google GKE 教程](/dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-gke.md)

dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-gke.md

@@ -24,7 +24,7 @@ category: how-to
 
 ## 选择一个项目
 
-本教程会启动一个包含 3 个 `n1-standard-1` 类型节点的 Kubernetes 集群。价格信息可以参考[这里](https://cloud.google.com/compute/pricing)。
+本教程会启动一个包含 3 个 `n1-standard-1` 类型节点的 Kubernetes 集群。价格信息可以参考 [All pricing](https://cloud.google.com/compute/pricing)。
 
 继续之前请选择一个项目：
 

dev/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube.md

@@ -55,7 +55,7 @@ minikube start --docker-env https_proxy=http://127.0.0.1:1086 \
 
 Kubernetes 命令行工具 [kubectl](https://kubernetes.io/docs/user-guide/kubectl/)，可以让你执行命令访问 Kubernetes 集群。
 
-参考[文档](https://kubernetes.io/docs/tasks/tools/install-kubectl/)安装和配置 kubectl。
+参考 [Install and Set Up kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) 安装和配置 kubectl。
 
 kubectl 安装完成后，测试 Minikube Kubernetes 集群：