如果你的 MySQL 服务位于没有公网访问权限的 AWS VPC 中，请按照以下步骤操作：
-1. 在 MySQL 服务所在 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。
+1. 在 MySQL 服务所在 VPC 与 TiDB 集群所在 VPC 之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。
2. 修改 MySQL 服务关联的安全组的入站规则。
- 你必须将 [TiDB Cloud 集群所在区域的 CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region) 添加到入站规则中。这样可以允许来自 TiDB 集群的流量访问 MySQL 实例。
+ 你必须将 [TiDB Cloud 集群所在区域的 CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region) 添加到入站规则中。这样可以允许来自 TiDB 集群到 MySQL 实例的流量。
3. 如果 MySQL URL 包含主机名，你需要允许 TiDB Cloud 能够解析 MySQL 服务的 DNS 主机名。
- 1. 按照 [为 VPC Peering 连接启用 DNS 解析](https://docs.aws.amazon.com/vpc/latest/peering/modify-peering-connections.html#vpc-peering-dns) 的步骤操作。
+ 1. 按照 [为 VPC Peering 连接启用 DNS 解析](https://docs.aws.amazon.com/vpc/latest/peering/modify-peering-connections.html#vpc-peering-dns) 中的步骤操作。
2. 启用 **Accepter DNS resolution** 选项。
如果你的 MySQL 服务位于没有公网访问权限的 Google Cloud VPC 中，请按照以下步骤操作：
1. 如果你的 MySQL 服务是 Google Cloud SQL，必须在 Google Cloud SQL 实例关联的 VPC 中暴露一个 MySQL 端点。你可能需要使用 Google 提供的 [**Cloud SQL Auth proxy**](https://cloud.google.com/sql/docs/mysql/sql-proxy)。
-2. 在 MySQL 服务所在 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。
-3. 修改 MySQL 所在 VPC 的入站防火墙规则。
+2. 在 MySQL 服务所在 VPC 与 TiDB 集群所在 VPC 之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。
+3. 修改 MySQL 所在 VPC 的 ingress 防火墙规则。
- 你必须将 [TiDB Cloud 集群所在区域的 CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region) 添加到入站防火墙规则中。这样可以允许来自 TiDB Cloud 集群的流量访问 MySQL 端点。
+ 你必须将 [TiDB Cloud 集群所在区域的 CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region) 添加到 ingress 防火墙规则中。这样可以允许来自 TiDB Cloud 集群到 MySQL 端点的流量。
-私有端点利用云服务商的 **Private Link** 或 **Private Service Connect** 技术，使你 VPC 中的资源能够通过私有 IP 地址连接到其他 VPC 的服务，就像这些服务直接托管在你的 VPC 内一样。
+私有端点利用云服务商的 **Private Link** 或 **Private Service Connect** 技术，使你 VPC 中的资源能够通过私有 IP 地址连接到其他 VPC 中的服务，就像这些服务直接托管在你的 VPC 内一样。
你可以通过私有端点安全地将 TiDB Cloud 集群连接到 MySQL 服务。如果你的 MySQL 服务尚未启用私有端点，请参考 [Set Up Private Endpoint for Changefeeds](/tidb-cloud/set-up-sink-private-endpoint.md) 创建私有端点。
@@ -65,28 +78,54 @@ summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 T
-### 加载已有数据（可选）
+
+
+
+
+确保你的 TiDB Cloud 实例可以连接到 MySQL 服务。
+
+> **注意：**
+>
+> 目前，TiDB Cloud Premium 实例的 VPC Peering 功能仅支持按需申请。若需申请此功能，请在 [TiDB Cloud 控制台](https://tidbcloud.com) 右下角点击 **?**，然后点击 **Request Support**。在 **Description** 字段填写 "Apply for VPC Peering for TiDB Cloud Premium instance"，并点击 **Submit**。
+
+私有端点利用云服务商的 **Private Link** 或 **Private Service Connect** 技术，使你 VPC 中的资源能够通过私有 IP 地址连接到其他 VPC 中的服务，就像这些服务直接托管在你的 VPC 内一样。
+
+你可以通过私有端点安全地将 TiDB Cloud 实例连接到 MySQL 服务。如果你的 MySQL 服务尚未启用私有端点，请参考 [Set Up Private Endpoint for Changefeeds](/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md) 创建私有端点。
+
+
+
+### 加载现有数据（可选）
+
+
+
+**Sink to MySQL** 连接器只能将某一时间点之后的增量数据从 TiDB 集群同步到 MySQL。如果你的 TiDB 集群中已经有数据，可以在启用 **Sink to MySQL** 之前，将 TiDB 集群的现有数据导出并加载到 MySQL。
+
+
+
+
+**Sink to MySQL** 连接器只能将某一时间点之后的增量数据从 TiDB 实例同步到 MySQL。如果你的 TiDB 实例中已经有数据，可以在启用 **Sink to MySQL** 之前，将 TiDB 实例的现有数据导出并加载到 MySQL。
-**Sink to MySQL** 连接器只能将某一时间戳之后的增量数据从 TiDB 集群同步到 MySQL。如果你的 TiDB 集群中已经有数据，可以在启用 **Sink to MySQL** 之前，将已有数据导出并加载到 MySQL。
+
-加载已有数据的步骤如下：
+加载现有数据的步骤如下：
1. 将 [tidb_gc_life_time](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50) 设置为大于以下两个操作总耗时的值，以避免这段时间内的历史数据被 TiDB 垃圾回收。
- - 导出和导入已有数据所需的时间
+ - 导出和导入现有数据所需的时间
- 创建 **Sink to MySQL** 所需的时间
例如：
+
```sql
SET GLOBAL tidb_gc_life_time = '720h';
```
-2. 使用 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview) 从 TiDB 集群导出数据，然后使用社区工具如 [mydumper/myloader](https://centminmod.com/mydumper.html) 将数据加载到 MySQL 服务。
+2. 使用 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview) 从 TiDB 集群 实例 导出数据，然后使用社区工具如 [mydumper/myloader](https://centminmod.com/mydumper.html) 将数据加载到 MySQL 服务。
3. 从 [Dumpling 导出的文件](https://docs.pingcap.com/tidb/stable/dumpling-overview#format-of-exported-files) 中，获取 MySQL sink 的起始位置（start position），该信息位于 metadata 文件中：
- 以下是示例 metadata 文件的一部分。`SHOW MASTER STATUS` 的 `Pos` 即为已有数据的 TSO，也是 MySQL sink 的起始位置。
+ 以下是示例 metadata 文件的一部分。`SHOW MASTER STATUS` 的 `Pos` 即为现有数据的 TSO，也是 MySQL sink 的起始位置。
```
Started dump at: 2020-11-10 10:40:19
@@ -98,13 +137,13 @@ summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 T
### 在 MySQL 中创建目标表
-如果你没有加载已有数据，需要在 MySQL 中手动创建对应的目标表，用于存储来自 TiDB 的增量数据。否则，数据将无法同步。
+如果你没有加载现有数据，需要在 MySQL 中手动创建对应的目标表，用于存储来自 TiDB 的增量数据。否则，数据将无法被同步。
## 创建 MySQL sink
完成前置条件后，你可以将数据同步到 MySQL。
-1. 进入目标 TiDB 集群的集群总览页面，在左侧导航栏点击 **Data** > **Changefeed**。
+1. 进入目标 TiDB 集群 实例 的概览页面，在左侧导航栏点击 **Data** > **Changefeed**。
2. 点击 **Create Changefeed**，并选择 **MySQL** 作为 **Destination**。
@@ -115,38 +154,38 @@ summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 T
4. 在 **Authentication** 中，填写 MySQL 服务的用户名和密码。
-5. 点击 **Next** 测试 TiDB 是否能成功连接到 MySQL：
+5. 点击 **Next** 测试 TiDB 是否可以成功连接到 MySQL：
- - 如果连接成功，将进入下一步配置。
+ - 如果可以连接，将进入下一步配置。
- 如果连接失败，会显示连接错误，你需要排查并解决问题。解决后再次点击 **Next**。
6. 自定义 **Table Filter**，筛选你希望同步的表。规则语法详见 [table filter rules](/table-filter.md)。
- **Case Sensitive**：你可以设置过滤规则中数据库和表名的匹配是否区分大小写。默认情况下，匹配不区分大小写。
- - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则后，TiDB Cloud 会查询 TiDB 中所有表，并在右侧仅显示匹配规则的表。最多可添加 100 条过滤规则。
- - **Tables with valid keys**：此列显示具有有效键（主键或唯一索引）的表。
- - **Tables without valid keys**：此列显示缺少主键或唯一索引的表。这些表在同步时存在风险，因为下游处理重复事件时，缺少唯一标识可能导致数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一索引或主键，或者通过过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。
+ - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则时，TiDB Cloud 会查询 TiDB 中的所有表，并在右侧仅显示匹配规则的表。最多可添加 100 条过滤规则。
+ - **Tables with valid keys**：此列显示具有有效键（包括主键或唯一索引）的表。
+ - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步时存在风险，因为缺少唯一标识可能导致下游处理重复事件时数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一键或主键，或者通过过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。
7. 自定义 **Event Filter**，筛选你希望同步的事件。
- **Tables matching**：你可以设置事件过滤器应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个 changefeed 最多可添加 10 条事件过滤规则。
- - **Event Filter**：你可以使用以下事件过滤器，从 changefeed 中排除特定事件：
+ - **Event Filter**：你可以使用以下事件过滤器排除特定事件类型：
- **Ignore event**：排除指定类型的事件。
- **Ignore SQL**：排除匹配指定表达式的 DDL 事件。例如，`^drop` 排除以 `DROP` 开头的语句，`add column` 排除包含 `ADD COLUMN` 的语句。
- **Ignore insert value expression**：排除满足特定条件的 `INSERT` 语句。例如，`id >= 100` 排除 `id` 大于等于 100 的 `INSERT` 语句。
- - **Ignore update new value expression**：排除新值满足指定条件的 `UPDATE` 语句。例如，`gender = 'male'` 排除更新后 `gender` 为 `male` 的操作。
- - **Ignore update old value expression**：排除旧值满足指定条件的 `UPDATE` 语句。例如，`age < 18` 排除旧值 `age` 小于 18 的更新操作。
- - **Ignore delete value expression**：排除满足指定条件的 `DELETE` 语句。例如，`name = 'john'` 排除 `name` 为 `'john'` 的删除操作。
+ - **Ignore update new value expression**：排除新值满足指定条件的 `UPDATE` 语句。例如，`gender = 'male'` 排除更新后 `gender` 为 `male` 的更新。
+ - **Ignore update old value expression**：排除旧值满足指定条件的 `UPDATE` 语句。例如，`age < 18` 排除旧值 `age` 小于 18 的更新。
+ - **Ignore delete value expression**：排除满足指定条件的 `DELETE` 语句。例如，`name = 'john'` 排除 `name` 为 `'john'` 的删除。
8. 在 **Start Replication Position** 中，配置 MySQL sink 的起始同步位置。
- - 如果你已通过 Dumpling [加载了已有数据](#load-existing-data-optional)，请选择 **Start replication from a specific TSO**，并填写从 Dumpling 导出 metadata 文件中获取的 TSO。
- - 如果上游 TiDB 集群没有任何数据，选择 **Start replication from now on**。
- - 其他情况下，你可以选择 **Start replication from a specific time**，自定义起始时间点。
+ - 如果你已通过 Dumpling [加载了现有数据](#load-existing-data-optional)，请选择 **Start replication from a specific TSO**，并填写从 Dumpling 导出 metadata 文件中获取的 TSO。
+ - 如果上游 TiDB 集群 实例 中没有任何数据，选择 **Start replication from now on**。
+ - 否则，你可以通过选择 **Start replication from a specific time** 自定义起始时间点。
9. 点击 **Next** 配置 changefeed 规格。
- - 在 **Changefeed Specification** 区域，指定 changefeed 使用的 Replication Capacity Units（RCU）数量。
+ - 在 **Changefeed Specification** 区域，指定 changefeed 使用的 Replication Capacity Units (RCUs) Changefeed Capacity Units (CCUs) 数量。
- 在 **Changefeed Name** 区域，指定 changefeed 的名称。
10. 点击 **Next**，检查 changefeed 配置。
@@ -159,7 +198,7 @@ summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 T
点击 changefeed 名称，可以查看更多 changefeed 详情，如 checkpoint、同步延迟及其他指标。
-12. 如果你已通过 Dumpling [加载了已有数据](#load-existing-data-optional)，在 sink 创建完成后，需要将 GC 时间恢复为原值（默认值为 `10m`）：
+12. 如果你已通过 Dumpling [加载了现有数据](#load-existing-data-optional)，在 sink 创建完成后，需要将 GC 时间恢复为原值（默认值为 `10m`）：
```sql
SET GLOBAL tidb_gc_life_time = '10m';
diff --git a/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md b/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md
index e58a4f38b8272..667c9b5317e6a 100644
--- a/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md
+++ b/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md
@@ -5,18 +5,18 @@ summary: 了解如何通过阿里云私有终端节点连接到你的 TiDB Cloud
# 通过阿里云私有终端节点连接 TiDB Cloud Starter 或 Essential
-本教程将指导你如何通过阿里云的私有终端节点连接到你的 TiDB Cloud Starter 或 Essential 集群。通过私有终端节点连接，可以在不经过公网的情况下，实现你的服务与 TiDB Cloud 集群之间的安全、私密通信。
+本教程将指导你通过阿里云的私有终端节点连接到你的 TiDB Cloud Starter 或 Essential 集群。通过私有终端节点连接，可以在不经过公网的情况下，实现你的服务与 TiDB Cloud 集群之间的安全、私密通信。
> **Tip:**
>
-> 如果你想了解如何通过 AWS PrivateLink 连接 TiDB Cloud Starter 或 Essential 集群，请参阅 [Connect to TiDB Cloud via AWS PrivateLink](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)。
+> 如果你想了解如何通过 AWS PrivateLink 连接到 TiDB Cloud Starter 或 Essential 集群，请参见 [Connect to TiDB Cloud via AWS PrivateLink](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)。
## 限制
- 目前，TiDB Cloud Starter 和 TiDB Cloud Essential 支持在终端节点服务托管于 AWS 或阿里云时使用私有终端节点连接。如果服务托管在其他云服务商，私有终端节点不可用。
- 不支持跨地域的私有终端节点连接。
-## 使用阿里云设置私有终端节点
+## 在阿里云上设置私有终端节点
要通过私有终端节点连接到你的 TiDB Cloud Starter 或 TiDB Cloud Essential 集群，请按照以下步骤操作：
@@ -44,8 +44,8 @@ summary: 了解如何通过阿里云私有终端节点连接到你的 TiDB Cloud
- **Endpoint Type**：选择 **Interface Endpoint**。
- **Endpoint Service**：选择 **Other Endpoint Services**。
-5. 粘贴你从 TiDB Cloud 复制的 **Endpoint Service Name**。
-6. 点击 **Verify**。如果服务有效，会出现绿色对勾。
+5. 在 **Endpoint Service Name** 字段中，粘贴你从 TiDB Cloud 复制的服务名称。
+6. 点击 **Verify**。如果服务有效，会出现绿色勾选。
7. 选择要用于该终端节点的 **VPC**、**Security Group** 和 **Zone**。
8. 点击 **OK** 创建终端节点。
9. 等待终端节点状态变为 **Active**，连接状态变为 **Connected**。
diff --git a/tidb-cloud/set-up-private-endpoint-connections-serverless.md b/tidb-cloud/set-up-private-endpoint-connections-serverless.md
index 1ae56f010124d..d89d59b77cd18 100644
--- a/tidb-cloud/set-up-private-endpoint-connections-serverless.md
+++ b/tidb-cloud/set-up-private-endpoint-connections-serverless.md
@@ -13,9 +13,9 @@ summary: 了解如何通过私有终端节点连接到你的 TiDB Cloud 集群
> - 如果你想了解如何通过 Azure 私有终端节点连接 TiDB Cloud Dedicated 集群，请参见 [Connect to a TiDB Cloud Dedicated Cluster via Azure Private Link](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)。
> - 如果你想了解如何通过 Google Cloud 私有终端节点连接 TiDB Cloud Dedicated 集群，请参见 [Connect to a TiDB Cloud Dedicated Cluster via Google Cloud Private Service Connect](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)。
-TiDB Cloud 支持通过 [AWS PrivateLink](https://aws.amazon.com/privatelink/?privatelink-blogs.sort-by=item.additionalFields.createdDate&privatelink-blogs.sort-order=desc) 实现对托管在 AWS VPC 中的 TiDB Cloud 服务的高度安全、单向访问，就像服务部署在你自己的 VPC 中一样。你的 VPC 中会暴露一个私有终端节点，你可以通过该终端节点并具备相应权限后连接到 TiDB Cloud 服务。
+TiDB Cloud 支持通过 [AWS PrivateLink](https://aws.amazon.com/privatelink/?privatelink-blogs.sort-by=item.additionalFields.createdDate&privatelink-blogs.sort-order=desc) 实现对托管在 AWS VPC 中的 TiDB Cloud 服务的高度安全、单向访问，就像该服务部署在你自己的 VPC 中一样。你的 VPC 中会暴露一个私有终端节点，你可以通过该终端节点并具备相应权限后连接到 TiDB Cloud 服务。
-借助 AWS PrivateLink，终端节点连接是安全且私有的，不会将你的数据暴露在公网上。此外，终端节点连接支持 CIDR 重叠，便于网络管理。
+借助 AWS PrivateLink，终端节点连接安全且私密，不会将你的数据暴露在公网。此外，终端节点连接支持 CIDR 重叠，便于网络管理。
私有终端节点的架构如下所示：
@@ -33,7 +33,7 @@ TiDB Cloud 支持通过 [AWS PrivateLink](https://aws.amazon.com/privatelink/?pr
## 前提条件
-请确保在 AWS VPC 设置中已启用 DNS 主机名和 DNS 解析。在 [AWS 管理控制台](https://console.aws.amazon.com/) 创建 VPC 时，这些选项默认是关闭的。
+请确保在 AWS VPC 设置中已启用 DNS 主机名和 DNS 解析。在 [AWS 管理控制台](https://console.aws.amazon.com/) 中创建 VPC 时，这些选项默认是关闭的。
## 使用 AWS 设置私有终端节点
@@ -71,8 +71,8 @@ TiDB Cloud 支持通过 [AWS PrivateLink](https://aws.amazon.com/privatelink/?pr
3. 选择 **Endpoint services that use NLBs and GWLBs**。
4. 输入你在 [step 1](#step-1-choose-a-tidb-cluster) 中获取的 service name。
5. 点击 **Verify service**。
-6. 在下拉列表中选择你的 VPC。展开 **Additional settings** 并勾选 **Enable DNS name** 复选框。
-7. 在 **Subnets** 区域，选择 TiDB 集群所在的可用区，并选择 Subnet ID。
+6. 在下拉列表中选择你的 VPC。展开 **Additional settings**，勾选 **Enable DNS name** 复选框。
+7. 在 **Subnets** 区域，选择你的 TiDB 集群所在的可用区，并选择 Subnet ID。
8. 在 **Security groups** 区域，正确选择你的安全组。
> **Note:**
@@ -109,12 +109,12 @@ aws ec2 create-vpc-endpoint --vpc-id ${your_vpc_id} --region ${region_id} --serv
1. 在 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群名称，进入其概览页面。
2. 点击右上角的 **Connect**。会弹出连接对话框。
3. 在 **Connection Type** 下拉列表中，选择 **Private Endpoint**。
-4. 在 **Connect With** 下拉列表中，选择你偏好的连接方式。对话框底部会显示相应的连接字符串。
+4. 在 **Connect With** 下拉列表中，选择你偏好的连接方式。对话框底部会显示对应的连接字符串。
5. 使用该连接字符串连接到你的集群。
> **Tip:**
>
-> 如果你无法连接到集群，可能是因为 AWS 中 VPC 终端节点的安全组设置不正确。解决方法请参见 [此 FAQ](#troubleshooting)。
+> 如果你无法连接到集群，可能是 AWS 中 VPC 终端节点的安全组设置不正确。解决方法请参见 [此 FAQ](#troubleshooting)。
>
> 如果在创建 VPC 终端节点时遇到错误 `private-dns-enabled cannot be set because there is already a conflicting DNS domain for gatewayXX-privatelink.XX.prod.aws.tidbcloud.com in the VPC vpc-XXXXX`，说明已经创建过私有终端节点，无需重复创建。
@@ -122,6 +122,6 @@ aws ec2 create-vpc-endpoint --vpc-id ${your_vpc_id} --region ${region_id} --serv
### 启用私有 DNS 后，无法通过私有终端节点连接 TiDB 集群，为什么？
-你可能需要在 AWS 管理控制台中为 VPC 终端节点正确设置安全组。进入 **VPC** > **Endpoints**，右键你的 VPC 终端节点，选择合适的 **Manage security groups**。在你的 VPC 内选择允许 EC2 实例通过 4000 端口或自定义端口入站访问的安全组。
+你可能需要在 AWS 管理控制台中正确设置 VPC 终端节点的安全组。进入 **VPC** > **Endpoints**，右键你的 VPC 终端节点，选择合适的 **Manage security groups**。在你的 VPC 内选择允许 EC2 实例通过 4000 端口或自定义端口入站访问的安全组。
-
\ No newline at end of file
+
diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md
index 0a6bd06bd65ae..87c4d2fd65329 100644
--- a/tidb-cloud/set-up-vpc-peering-connections.md
+++ b/tidb-cloud/set-up-vpc-peering-connections.md
@@ -7,17 +7,17 @@ summary: 了解如何通过 VPC Peering 连接 TiDB Cloud Dedicated。
> **Note:**
>
-> VPC Peering 连接仅适用于托管在 AWS 和 Google Cloud 上的 TiDB Cloud Dedicated 集群。你无法使用 VPC Peering 连接托管在 Azure 上的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群以及 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群。
+> VPC Peering 连接仅适用于托管在 AWS 和 Google Cloud 上的 TiDB Cloud Dedicated 集群。
要通过 VPC Peering 将你的应用程序连接到 TiDB Cloud，你需要与 TiDB Cloud 建立 [VPC Peering](/tidb-cloud/tidb-cloud-glossary.md#vpc-peering)。本文档将指导你在 [AWS 上设置 VPC Peering](#set-up-vpc-peering-on-aws) 和 [Google Cloud 上设置 VPC Peering](#set-up-vpc-peering-on-google-cloud)，并通过 VPC Peering 连接到 TiDB Cloud。
VPC Peering 连接是两个 VPC 之间的网络连接，使你能够使用私有 IP 地址在它们之间路由流量。任一 VPC 中的实例都可以像在同一网络中一样相互通信。
-目前，同一项目同一区域下的 TiDB 集群会创建在同一个 VPC 中。因此，一旦在某个项目的某个区域设置了 VPC Peering，该项目在同一区域内创建的所有 TiDB 集群都可以通过你的 VPC 进行连接。不同云服务商的 VPC Peering 设置方式有所不同。
+目前，同一项目下同一区域的 TiDB 集群会创建在同一个 VPC 中。因此，一旦在某个项目的某个区域设置了 VPC Peering，该项目在同一区域内创建的所有 TiDB 集群都可以通过你的 VPC 进行连接。不同云服务商的 VPC Peering 设置方式不同。
> **Tip:**
>
-> 你也可以通过与 TiDB Cloud 建立 [私有终端节点连接](/tidb-cloud/set-up-private-endpoint-connections.md) 来连接你的应用程序到 TiDB Cloud，该方式安全且私密，不会将你的数据暴露在公网。推荐优先使用私有终端节点而不是 VPC Peering 连接。
+> 你也可以通过与 TiDB Cloud 建立 [Private Endpoint 连接](/tidb-cloud/set-up-private-endpoint-connections.md) 来连接你的应用程序到 TiDB Cloud，这种方式安全且私有，不会将你的数据暴露在公网上。推荐优先使用 Private Endpoint 连接而不是 VPC Peering 连接。
## 前置条件：为区域设置 CIDR
@@ -36,16 +36,16 @@ CIDR（无类域间路由）是用于为 TiDB Cloud Dedicated 集群创建 VPC
> **Note:**
>
- > - 为避免与你应用程序所在 VPC 的 CIDR 冲突，你需要在此字段设置不同的项目 CIDR。
+ > - 为避免与你应用程序所在 VPC 的 CIDR 冲突，你需要在此字段中设置不同的项目 CIDR。
> - 对于 AWS 区域，建议配置 `/16` 到 `/23` 之间的 IP 范围。支持的网络地址包括：
> - 10.250.0.0 - 10.251.255.255
> - 172.16.0.0 - 172.31.255.255
> - 192.168.0.0 - 192.168.255.255
- > - 对于 Google Cloud 区域，建议配置 `/19` 到 `/20` 之间的 IP 范围。如果你希望配置 `/16` 到 `/18` 之间的 IP 范围，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。支持的网络地址包括：
+ > - 对于 Google Cloud 区域，建议配置 `/19` 到 `/20` 之间的 IP 范围。支持的网络地址包括：
> - 10.250.0.0 - 10.251.255.255
> - 172.16.0.0 - 172.17.255.255
> - 172.30.0.0 - 172.31.255.255
- > - TiDB Cloud 会根据区域 CIDR 块的大小限制该项目在该区域内的 TiDB Cloud 节点数量。
+ > - TiDB Cloud 会根据区域的 CIDR 块大小限制该项目在该区域内的 TiDB Cloud 节点数量。
5. 查看云服务商及具体区域的 CIDR。
@@ -57,7 +57,7 @@ CIDR（无类域间路由）是用于为 TiDB Cloud Dedicated 集群创建 VPC
本节介绍如何在 AWS 上设置 VPC Peering 连接。关于 Google Cloud，请参见 [在 Google Cloud 上设置 VPC Peering](#set-up-vpc-peering-on-google-cloud)。
-### 步骤 1. 添加 VPC Peering 请求
+### 第 1 步：添加 VPC Peering 请求
你可以在 TiDB Cloud 控制台的项目级 **Network Access** 页面或集群级 **Networking** 页面添加 VPC Peering 请求。
@@ -118,7 +118,7 @@ CIDR（无类域间路由）是用于为 TiDB Cloud Dedicated 集群创建 VPC
- `usw2-az1`
- `usw2-az2`
- `usw2-az3`
示例：
- `usw2-az1` => `us-west-2a`
- `usw2-az2` => `us-west-2c`
- `usw2-az3` => `us-west-2b`
为可用区生成的模式：
- `usw2-az1` => <broker_id>.usw2-az1.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `usw2-az2` => <broker_id>.usw2-az2.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `usw2-az3` => <broker_id>.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `us-west-2a` => <broker_id>.usw2-az1.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `us-west-2c` => <broker_id>.usw2-az2.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `us-west-2b` => <broker_id>.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `usw2-az1`
- `usw2-az2`
- `usw2-az3`
示例：
- `usw2-az1` => `us-west-2a`
- `usw2-az2` => `us-west-2c`
- `usw2-az3` => `us-west-2b`
为各 AZ 生成的 pattern：
- `usw2-az1` => <broker_id>.usw2-az1.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `usw2-az2` => <broker_id>.usw2-az2.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `usw2-az3` => <broker_id>.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `us-west-2a` => <broker_id>.usw2-az1.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `us-west-2c` => <broker_id>.usw2-az2.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- `us-west-2b` => <broker_id>.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:<port>
- 左侧导航栏的入口会根据组合框当前选择动态调整，帮助你聚焦最相关功能。
- - **Support**、**Notification** 和账号入口现始终固定在左侧导航栏底部，便于快速访问。
+ - **Support**、**Notification** 和账户入口现始终固定在左侧导航栏底部，便于快速访问。
## 2025 年 6 月 4 日
**通用变更**
-- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 在 Microsoft Azure 上现已公测。
+- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 现已在 Microsoft Azure 公测。
- 至此，TiDB Cloud 已支持三大主流公有云平台 —— AWS、Google Cloud 和 Azure，助你根据业务需求和云战略灵活部署 TiDB Cloud Dedicated 集群。
+ 随着本次发布，TiDB Cloud 现已支持三大主流公有云平台 —— AWS、Google Cloud 和 Azure，助你根据业务需求和云战略灵活部署 TiDB Cloud Dedicated 集群。
- AWS 和 Google Cloud 上的所有核心功能在 Azure 上均已支持。
- - 目前 Azure 支持的区域有：美国东部 2、日本东部和东南亚，更多区域即将开放。
+ - Azure 目前支持 East US 2、日本东部和东南亚三个区域，后续将支持更多区域。
- Azure 上的 TiDB Cloud Dedicated 集群需 TiDB 版本 v7.5.3 或更高。
- 快速上手请参见以下文档：
+ 快速上手文档：
- [在 Azure 上创建 TiDB Cloud Dedicated 集群](/tidb-cloud/create-tidb-cluster.md)
- [通过 Azure Private Endpoint 连接 TiDB Cloud Dedicated 集群](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)
- - [导入数据到 Azure 上的 TiDB Cloud Dedicated 集群](/tidb-cloud/import-csv-files.md)
+ - [向 Azure 上的 TiDB Cloud Dedicated 集群导入数据](/tidb-cloud/import-csv-files.md)
+
+- Prometheus 集成为 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群提供更多监控指标。
-- Prometheus 集成为 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群提供更多监控指标，增强监控能力。
-
你现在可以将 `tidbcloud_disk_read_latency`、`tidbcloud_kv_request_duration` 等更多指标集成到 Prometheus，追踪 TiDB Cloud Dedicated 性能的更多方面。
-
- 详情及启用方法请参见 [集成 TiDB Cloud 与 Prometheus 和 Grafana（Beta）](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#metrics-available-to-prometheus)。
+
+ 了解可用指标及启用方法，参见 [集成 TiDB Cloud 与 Prometheus 和 Grafana（Beta）](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#metrics-available-to-prometheus)。
- TiKV [Standard](/tidb-cloud/size-your-cluster.md#standard-storage) 和 [Performance](/tidb-cloud/size-your-cluster.md#performance-and-plus-storage) 存储定价正式发布。
- 优惠期自 **2025 年 6 月 5 日 00:00 UTC** 起结束，届时价格恢复为标准价。TiDB Cloud Dedicated 价格详情请参见 [TiDB Cloud Dedicated 价格明细](https://www.pingcap.com/tidb-dedicated-pricing-details/#node-cost)。
+ 优惠期自 **2025 年 6 月 5 日 00:00 UTC** 起结束，届时价格恢复为标准价。更多 TiDB Cloud Dedicated 价格信息，参见 [TiDB Cloud Dedicated 价格详情](https://www.pingcap.com/tidb-dedicated-pricing-details/#node-cost)。
**控制台变更**
@@ -472,35 +486,35 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
该功能可将 TiDB Cloud Dedicated 集群与更多下游系统集成，满足更多数据集成需求。使用该功能需确保集群版本为 v7.5.1 或更高。
- 详情请参见 [下沉到 Apache Pulsar](/tidb-cloud/changefeed-sink-to-apache-pulsar.md)。
+ 了解更多信息，参见 [下沉到 Apache Pulsar](/tidb-cloud/changefeed-sink-to-apache-pulsar.md)。
## 2025 年 5 月 13 日
**通用变更**
-- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 现已支持全文检索（beta），助力 AI 应用。
+- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 现已支持全文检索（beta），适用于 AI 应用。
- TiDB Cloud Serverless 现已支持全文检索（beta），使 AI 和 RAG（检索增强生成）应用可通过精确关键词检索内容。该功能补充了向量检索（按语义相似度检索内容），两者结合可显著提升 RAG 工作流的检索准确性和答案质量。主要特性包括：
+ TiDB Cloud Serverless 现支持全文检索（beta），使 AI 和 RAG（检索增强生成）应用可通过精确关键词检索内容。该功能补充了向量检索（按语义相似度检索内容），两者结合可显著提升 RAG 工作流的检索准确性和答案质量。主要特性包括：
- 直接文本检索：可直接查询字符串列，无需嵌入。
- - 多语言支持：自动检测并分析多语言文本，甚至同一表内无需指定语言。
- - 基于相关性的排序：结果采用业界标准 BM25 算法排序，相关性最佳。
- - 原生 SQL 兼容：可无缝结合 SQL 过滤、分组、关联等功能使用全文检索。
+ - 多语言支持：自动检测并分析多语言文本，即使同一表中包含多种语言，无需指定语言。
+ - 相关性排序：结果采用业界标准 BM25 算法进行最优相关性排序。
+ - 原生 SQL 兼容：可无缝结合 SQL 的过滤、分组和关联等功能使用全文检索。
- 快速上手请参见 [使用 SQL 进行全文检索](/tidb-cloud/vector-search-full-text-search-sql.md) 或 [使用 Python 进行全文检索](/tidb-cloud/vector-search-full-text-search-python.md)。
+ 快速上手，参见 [使用 SQL 进行全文检索](/tidb-cloud/vector-search-full-text-search-sql.md) 或 [使用 Python 进行全文检索](/tidb-cloud/vector-search-full-text-search-python.md)。
- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群 TiFlash 节点最大存储容量提升：
- 8 vCPU TiFlash：由 2048 GiB 提升至 4096 GiB
- 32 vCPU TiFlash：由 4096 GiB 提升至 8192 GiB
- 该增强提升了 TiDB Cloud Dedicated 集群的分析型数据存储能力，提高了工作负载扩展效率，满足不断增长的数据需求。
+ 该增强提升了 TiDB Cloud Dedicated 集群的分析数据存储能力，提高了工作负载扩展效率，满足不断增长的数据需求。
- 详情请参见 [TiFlash 节点存储容量](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)。
+ 了解更多信息，参见 [TiFlash 节点存储容量](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)。
- 优化维护窗口配置体验，提供更直观的选项以配置和重新安排维护任务。
- 详情请参见 [配置维护窗口](/tidb-cloud/configure-maintenance-window.md)。
+ 了解更多信息，参见 [配置维护窗口](/tidb-cloud/configure-maintenance-window.md)。
- 延长 TiKV [Standard](/tidb-cloud/size-your-cluster.md#standard-storage) 和 [Performance](/tidb-cloud/size-your-cluster.md#performance-and-plus-storage) 存储类型的优惠期，现延长至 2025 年 6 月 5 日。届时价格将恢复为标准价。
@@ -508,7 +522,7 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
- 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群 **Backup Setting** 页面布局，提升备份配置体验。
- 详情请参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md)。
+ 了解更多信息，参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md)。
## 2025 年 4 月 22 日
@@ -518,7 +532,7 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
[TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群现支持使用 [AccessKey 对](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair) 将数据导出到 [阿里云对象存储服务（OSS）](https://www.alibabacloud.com/en/product/object-storage-service)。
- 详情请参见 [从 TiDB Cloud Serverless 导出数据](/tidb-cloud/serverless-export.md#alibaba-cloud-oss)。
+ 了解更多信息，参见 [从 TiDB Cloud Serverless 导出数据](/tidb-cloud/serverless-export.md#alibaba-cloud-oss)。
- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群的 TiDB 版本由 [v7.1.3](https://docs.pingcap.com/tidb/v7.1/release-7.1.3) 升级为 [v7.5.2](https://docs.pingcap.com/tidb/v7.5/release-7.5.2)。
@@ -530,7 +544,7 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
该功能简化了数据迁移到 TiDB Cloud Serverless 的流程。你可以使用 AccessKey 对进行认证。
- 详情请参见以下文档：
+ 了解更多信息，参见以下文档：
- [从 Amazon S3、GCS、Azure Blob Storage 或阿里云 OSS 导入 CSV 文件到 TiDB Cloud Serverless](/tidb-cloud/import-csv-files-serverless.md)
- [从 Amazon S3、GCS、Azure Blob Storage 或阿里云 OSS 导入 Apache Parquet 文件到 TiDB Cloud Serverless](/tidb-cloud/import-parquet-files-serverless.md)
@@ -541,37 +555,37 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
- [TiDB Node Groups](/tidb-cloud/tidb-node-group-overview.md) 功能现已在托管于 AWS 和 Google Cloud 的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群正式发布（GA）。
- 该功能可在单一集群内实现**细粒度计算资源隔离**，助你为多租户或多工作负载场景优化性能和资源分配。
+ 该功能支持在单一集群内实现**细粒度计算资源隔离**，帮助你为多租户或多工作负载场景优化性能和资源分配。
**主要优势：**
- **资源隔离**：
- - 将 TiDB 节点分组为逻辑隔离单元，确保一个组内的工作负载不会影响其他组。
+ - 将 TiDB 节点分组为逻辑隔离单元，确保一个组的工作负载不会影响其他组。
- 防止应用或业务单元间的资源争用。
- **简化管理**：
- 在单一集群内统一管理所有节点组，降低运维负担。
- - 可按需独立扩缩各组。
+ - 可按需独立扩缩各节点组。
- 详细优势请参见 [技术博客](https://www.pingcap.com/blog/tidb-cloud-node-groups-scaling-workloads-predictable-performance/)。快速上手请参见 [管理 TiDB Node Groups](/tidb-cloud/tidb-node-group-management.md)。
+ 了解更多优势，参见 [技术博客](https://www.pingcap.com/blog/tidb-cloud-node-groups-scaling-workloads-predictable-performance/)。快速上手，参见 [管理 TiDB Node Groups](/tidb-cloud/tidb-node-group-management.md)。
- 在托管于 AWS 的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中引入 [Standard storage](/tidb-cloud/size-your-cluster.md#standard-storage) 类型的 TiKV 节点。
- Standard 存储类型适用于大多数工作负载，在性能和成本之间实现平衡。
+ Standard 存储类型适用于大多数工作负载，在性能与成本之间实现平衡。
**主要优势：**
- **性能提升**：为 Raft 日志预留充足磁盘资源，减少 Raft 与数据存储的 I/O 争用，提升 TiKV 读写性能。
- - **稳定性增强**：将关键 Raft 操作与数据工作负载隔离，确保性能更可预测。
- - **成本效益**：相比之前的存储类型，以更具竞争力的价格提供更高性能。
+ - **稳定性增强**：将关键 Raft 操作与数据工作负载隔离，确保更可预测的性能。
+ - **成本效益**：与之前的存储类型相比，以更具竞争力的价格提供更高性能。
**可用性：**
Standard 存储类型会自动应用于 2025 年 4 月 1 日及以后在 AWS 上新建的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群，且需支持的版本（>= 7.5.5、8.1.2 或 8.5.0）。现有集群仍使用之前的 [Basic storage](/tidb-cloud/size-your-cluster.md#basic-storage) 类型，无需迁移。
- Standard 存储类型的价格与 Basic 存储类型不同。详情请参见 [价格说明](https://www.pingcap.com/tidb-dedicated-pricing-details/)。
+ Standard 存储类型的价格与 Basic 存储类型不同。了解更多信息，参见 [价格](https://www.pingcap.com/tidb-dedicated-pricing-details/)。
## 2025 年 3 月 25 日
@@ -579,9 +593,9 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群现已支持为公网端点配置防火墙规则。
- 你现在可以为 TiDB Cloud Serverless 集群配置防火墙规则，控制公网端点的访问。可在 [TiDB Cloud 控制台](https://tidbcloud.com/) 直接指定允许的 IP 地址或范围，提升安全性。
+ 你现在可以在 [TiDB Cloud 控制台](https://tidbcloud.com/) 为 TiDB Cloud Serverless 集群配置防火墙规则，控制公网端点的访问。可直接指定允许的 IP 地址或范围，提升安全性。
- 详情请参见 [为 TiDB Cloud Serverless 公网端点配置防火墙规则](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)。
+ 了解更多信息，参见 [为 TiDB Cloud Serverless 公网端点配置防火墙规则](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)。
## 2025 年 3 月 18 日
@@ -589,48 +603,48 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
- 支持为部署在 Google Cloud 的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建 TiDB 节点组，提升资源管理灵活性。
- 详情请参见 [TiDB Node Group 概述](/tidb-cloud/tidb-node-group-overview.md)。
+ 了解更多信息，参见 [TiDB Node Group 概述](/tidb-cloud/tidb-node-group-overview.md)。
- 支持将数据库审计日志文件存储在 TiDB Cloud，适用于部署在 AWS 的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。
你可以直接从 TiDB Cloud 下载这些审计日志文件。该功能仅支持按需申请。
- 详情请参见 [数据库审计日志](/tidb-cloud/tidb-cloud-auditing.md)。
+ 了解更多信息，参见 [数据库审计日志](/tidb-cloud/tidb-cloud-auditing.md)。
-- 通过优化多因素认证（MFA）管理，提升 TiDB Cloud 账号安全性。该功能适用于 TiDB Cloud 的密码登录。
+- 通过优化多因素认证（MFA）管理，提升 TiDB Cloud 账户安全性。该功能适用于 TiDB Cloud 的密码登录。
- 详情请参见 [密码认证](/tidb-cloud/tidb-cloud-password-authentication.md)。
+ 了解更多信息，参见 [密码认证](/tidb-cloud/tidb-cloud-password-authentication.md)。
## 2025 年 2 月 18 日
**控制台变更**
-- 引入 Connected Care，TiDB Cloud 的全新支持服务。
+- 引入 Connected Care，TiDB Cloud 的新一代支持服务。
Connected Care 服务通过现代通信工具、主动支持和先进 AI 能力，增强你与 TiDB Cloud 的连接，带来无缝且以客户为中心的体验。
Connected Care 服务包含以下功能：
- - **Clinic 服务**：高级监控与诊断，优化性能。
- - **IM 中的 AI 聊天**：通过即时通讯工具获得 AI 实时协助。
- - **IM 订阅告警与工单进展**：通过 IM 实时获知告警和工单进展。
+ - **Clinic service**：高级监控与诊断，优化性能。
+ - **AI chat in IM**：通过即时通讯工具获得 AI 实时协助。
+ - **IM 订阅告警与工单更新**：通过 IM 实时获知告警和工单进展。
- **IM 工单交互**：可通过 IM 工具创建和跟进支持工单。
- 详情请参见 [Connected Care 概述](/tidb-cloud/connected-care-overview.md)。
+ 了解更多信息，参见 [Connected Care 概述](/tidb-cloud/connected-care-overview.md)。
-- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群现已支持从 GCS 和 Azure Blob Storage 导入数据。
+- 支持从 GCS 和 Azure Blob Storage 导入数据到 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群。
- TiDB Cloud Serverless 现支持从 Google Cloud Storage（GCS）和 Azure Blob Storage 导入数据。你可以使用 Google Cloud 服务账号密钥或 Azure 共享访问签名（SAS）令牌进行认证。该功能简化了数据迁移到 TiDB Cloud Serverless。
+ TiDB Cloud Serverless 现支持从 Google Cloud Storage (GCS) 和 Azure Blob Storage 导入数据。你可以使用 Google Cloud 服务账号密钥或 Azure SAS Token 进行认证。该功能简化了数据迁移到 TiDB Cloud Serverless 的流程。
- 详情请参见 [从 Amazon S3、GCS 或 Azure Blob Storage 导入 CSV 文件到 TiDB Cloud Serverless](/tidb-cloud/import-csv-files-serverless.md) 和 [从 Amazon S3、GCS 或 Azure Blob Storage 导入 Apache Parquet 文件到 TiDB Cloud Serverless](/tidb-cloud/import-parquet-files-serverless.md)。
+ 了解更多信息，参见 [从 Amazon S3、GCS 或 Azure Blob Storage 导入 CSV 文件到 TiDB Cloud Serverless](/tidb-cloud/import-csv-files-serverless.md) 和 [从 Amazon S3、GCS 或 Azure Blob Storage 导入 Apache Parquet 文件到 TiDB Cloud Serverless](/tidb-cloud/import-parquet-files-serverless.md)。
## 2025 年 1 月 21 日
**控制台变更**
-- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群现已支持每次任务导入单个本地 CSV 文件，文件大小上限由 50 MiB 提升至 250 MiB。
+- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群现支持每次任务导入单个本地 CSV 文件，文件大小上限由 50 MiB 提升至 250 MiB。
- 详情请参见 [导入本地文件到 TiDB Cloud](/tidb-cloud/tidb-cloud-import-local-files.md)。
+ 了解更多信息，参见 [导入本地文件到 TiDB Cloud](/tidb-cloud/tidb-cloud-import-local-files.md)。
## 2025 年 1 月 14 日
@@ -638,9 +652,9 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群新增支持 AWS 区域：`Jakarta (ap-southeast-3)`。
-- 引入 Notification 功能，可通过 [TiDB Cloud 控制台](https://tidbcloud.com/) 实时获知 TiDB Cloud 更新和告警。
+- 引入 Notification 功能，让你可通过 [TiDB Cloud 控制台](https://tidbcloud.com/) 实时获知 TiDB Cloud 更新和告警。
- 详情请参见 [通知](/tidb-cloud/notifications.md)。
+ 了解更多信息，参见 [通知](/tidb-cloud/notifications.md)。
## 2025 年 1 月 2 日
@@ -648,53 +662,49 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
- 支持为 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建 TiDB 节点组，提升资源管理灵活性。
- 详情请参见 [TiDB Node Group 概述](/tidb-cloud/tidb-node-group-overview.md)。
+ 了解更多信息，参见 [TiDB Node Group 概述](/tidb-cloud/tidb-node-group-overview.md)。
-- 支持通过 Private Connect（beta）将 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群连接到 AWS 和 Google Cloud 上的通用 Kafka。
+- 支持通过 Private Connect（beta）将 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群连接到 AWS 和 Google Cloud 的通用 Kafka。
- Private Connect 利用云服务商的 Private Link 或 Private Service Connect 技术，使 TiDB Cloud VPC 内的 changefeed 可通过私有 IP 连接客户 VPC 内的 Kafka，仿佛这些 Kafka 就部署在 TiDB Cloud VPC 内。该功能有助于避免 VPC CIDR 冲突并满足安全合规要求。
+ Private Connect 利用云服务商的 Private Link 或 Private Service Connect 技术，使 TiDB Cloud VPC 内的 changefeed 可通过私有 IP 连接客户 VPC 内的 Kafka，就像这些 Kafka 直接托管在 TiDB Cloud VPC 内一样。该功能有助于避免 VPC CIDR 冲突并满足安全合规要求。
- - 对于 AWS 上的 Apache Kafka，请参见 [在 AWS 上设置自建 Kafka Private Link 服务](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md) 配置网络连接。
+ - 对于 AWS 上的 Apache Kafka，参见 [在 AWS 上配置自建 Kafka Private Link 服务](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md)。
+ - 对于 Google Cloud 上的 Apache Kafka，参见 [在 Google Cloud 上配置自建 Kafka Private Service Connect](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md)。
- - 对于 Google Cloud 上的 Apache Kafka，请参见 [在 Google Cloud 上设置自建 Kafka Private Service Connect](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md) 配置网络连接。
-
注意，使用该功能会产生额外的 [Private Data Link 费用](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md#private-data-link-cost)。
- 详情请参见 [Changefeed 下沉到 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md#network)。
+ 了解更多信息，参见 [Changefeed 下沉到 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md#network)。
- Kafka changefeed 新增可配置选项：
- - 支持使用 Debezium 协议。Debezium 是一种数据库变更捕获工具，会将每个捕获到的数据库变更转为事件消息并发送到 Kafka。详情请参见 [TiCDC Debezium 协议](https://docs.pingcap.com/tidb/v8.1/ticdc-debezium)。
-
+ - 支持使用 Debezium 协议。Debezium 是一种数据库变更捕获工具，将每个捕获的数据库变更转换为事件消息并发送到 Kafka。了解更多信息，参见 [TiCDC Debezium 协议](https://docs.pingcap.com/tidb/v8.1/ticdc-debezium)。
- 支持为所有表定义单一分区分发器，或为不同表定义不同分区分发器。
-
- 新增两种分发器类型：按时间戳和按列值分区分发 Kafka 消息。
- 详情请参见 [下沉到 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md)。
+ 了解更多信息，参见 [下沉到 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md)。
- TiDB Cloud 角色增强：
- - 新增 `Project Viewer` 和 `Organization Billing Viewer` 角色，实现更细粒度的访问控制。
-
+ - 新增 `Project Viewer` 和 `Organization Billing Viewer` 角色，提升 TiDB Cloud 的细粒度访问控制。
- 重命名以下角色：
- `Organization Member` 改为 `Organization Viewer`
- `Organization Billing Admin` 改为 `Organization Billing Manager`
- `Organization Console Audit Admin` 改为 `Organization Console Audit Manager`
- 详情请参见 [身份访问管理](/tidb-cloud/manage-user-access.md#organization-roles)。
+ 了解更多信息，参见 [身份访问管理](/tidb-cloud/manage-user-access.md#organization-roles)。
-- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群区域级高可用性（beta）。
+- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群区域高可用性（beta）。
- 该功能适用于对基础设施冗余和业务连续性要求极高的工作负载。主要功能包括：
+ 该功能适用于对基础设施冗余和业务连续性要求极高的工作负载。主要特性包括：
- - 节点分布于多个可用区，确保单区故障时高可用。
+ - 节点分布于多个可用区，确保主可用区故障时的高可用性。
- 关键 OLTP 组件（如 PD 和 TiKV）跨可用区冗余部署。
- - 主区故障时自动故障转移，最小化服务中断。
-
- 目前该功能仅在 AWS 东京（ap-northeast-1）区域开放，且仅可在集群创建时启用。
-
- 详情请参见 [TiDB Cloud Serverless 的高可用性](/tidb-cloud/serverless-high-availability.md)。
+ - 主可用区故障时自动故障转移，最小化服务中断。
+
+ 该功能目前仅在 AWS 东京（ap-northeast-1）区域可用，且仅可在集群创建时启用。
+
+ 了解更多信息，参见 [TiDB Cloud Serverless 的高可用性](/tidb-cloud/serverless-high-availability.md)。
- 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v8.1.1](https://docs.pingcap.com/tidb/v8.1/release-8.1.1) 升级为 [v8.1.2](https://docs.pingcap.com/tidb/v8.1/release-8.1.2)。
@@ -703,7 +713,6 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes']
- 数据导出服务增强：
- 支持通过 [TiDB Cloud 控制台](https://tidbcloud.com/) 将 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 数据导出到 Google Cloud Storage 和 Azure Blob Storage。
+ - 支持通过 [TiDB Cloud 控制台](https://tidbcloud.com/) 导出 Parquet 格式文件。
- - 支持通过 [TiDB Cloud 控制台](https://tidbcloud.com/) 导出 Parquet 文件格式数据。
-
- 详情请参见 [从 TiDB Cloud Serverless 导出数据](/tidb-cloud/serverless-export.md) 和 [为 TiDB Cloud Serverless 配置外部存储访问](/tidb-cloud/serverless-external-storage.md)。
\ No newline at end of file
+ 了解更多信息，参见 [从 TiDB Cloud Serverless 导出数据](/tidb-cloud/serverless-export.md) 和 [为 TiDB Cloud Serverless 配置外部存储访问](/tidb-cloud/serverless-external-storage.md)。
diff --git a/tidb-computing.md b/tidb-computing.md
index d1b64ae8a3136..60c83b84c51bd 100644
--- a/tidb-computing.md
+++ b/tidb-computing.md
@@ -1,60 +1,60 @@
---
-title: TiDB 计算
+title: TiDB Computing
summary: 了解 TiDB 数据库的计算层。
---
# TiDB 计算
-基于 TiKV 提供的分布式存储，TiDB 构建了结合了事务处理能力和数据分析能力的计算引擎。本文档首先介绍一种将数据映射到 TiKV 中 (Key, Value) 键值对的算法，然后介绍 TiDB 如何管理元数据，最后说明 TiDB SQL 层的架构。
+基于 TiKV 提供的分布式存储，TiDB 构建了结合强大事务处理能力与数据分析能力的计算引擎。本文档首先介绍一种将 TiDB 数据库表中的数据映射为 TiKV 中 (Key, Value) 键值对的数据映射算法，然后介绍 TiDB 如何管理元数据，最后阐述 TiDB SQL 层的架构。
-关于计算层所依赖的存储方案，本文仅介绍 TiKV 的行存储结构。对于 OLAP 服务，TiDB 引入了列存储方案 [TiFlash](/tiflash/tiflash-overview.md) 作为 TiKV 的扩展。
+关于计算层所依赖的存储方案，本文档仅介绍 TiKV 的行存储结构。对于 OLAP 服务，TiDB 引入了基于列存储的解决方案 [TiFlash](/tiflash/tiflash-overview.md)，作为 TiKV 的扩展。
-## 将表数据映射到 Key-Value
+## 表数据到 Key-Value 的映射
-本节描述将数据映射到 TiDB 中 (Key, Value) 键值对的方案。待映射的数据包括以下两类：
+本节描述了 TiDB 中将数据映射为 (Key, Value) 键值对的方案。这里需要映射的数据包括以下两类：
-- 表中每一行的数据，以下简称表数据。
-- 表中所有索引的数据，以下简称索引数据。
+- 表中每一行的数据，以下简称为表数据。
+- 表中所有索引的数据，以下简称为索引数据。
### 表数据到 Key-Value 的映射
-在关系型数据库中，一个表可能有许多列。为了将每一行中每一列的数据映射到 (Key, Value) 键值对，需要考虑如何构造 Key。首先，在 OLTP 场景下，存在许多对单行或多行数据的增删改查操作，这需要数据库能够快速读取一行数据。因此，每个 Key 应该具有唯一的 ID（显式或隐式），以便快速定位。然后，许多 OLAP 查询需要对整个表进行扫描。如果能将表中所有行的 Key 编码成一个范围，整个表就可以通过范围查询高效扫描。
+在关系型数据库中，一张表可能有很多列。要将一行中每一列的数据映射为 (Key, Value) 键值对，需要考虑如何构造 Key。首先，在 OLTP 场景下，存在大量对单行或多行数据的增、删、改、查操作，需要数据库能够快速读取一行数据。因此，每个 Key 应该有一个唯一的 ID（显式或隐式），以便快速定位。其次，许多 OLAP 查询需要全表扫描。如果能将一张表中所有行的 Key 编码为一个范围，就可以通过范围查询高效地扫描整张表。
基于上述考虑，TiDB 中表数据到 Key-Value 的映射设计如下：
-- 为了确保同一表的数据保持在一起，便于搜索，TiDB 为每个表分配一个表 ID，用 `TableID` 表示。表 ID 是在整个集群中唯一的整数。
-- TiDB 为表中的每一行数据分配一个行 ID，用 `RowID` 表示。行 ID 也是整数，在表内唯一。对于行 ID，TiDB 做了一个小的优化：如果表有一个整数类型的主键，TiDB 会使用该主键的值作为行 ID。
+- 为了保证同一张表的数据能够聚集在一起便于查找，TiDB 为每张表分配一个表 ID，用 `TableID` 表示。表 ID 是在整个集群中唯一的整数。
+- TiDB 为表中的每一行数据分配一个行 ID，用 `RowID` 表示。行 ID 也是表内唯一的整数。对于行 ID，TiDB 做了一个小优化：如果表有整型主键，TiDB 会用该主键的值作为行 ID。
-每一行数据根据以下规则编码为 (Key, Value) 键值对：
+每一行数据会按照如下规则编码为一个 (Key, Value) 键值对：
```
Key: tablePrefix{TableID}_recordPrefixSep{RowID}
Value: [col1, col2, col3, col4]
```
-`tablePrefix` 和 `recordPrefixSep` 都是用来区分 Key 空间中其他数据的特殊字符串常量。具体的字符串常量值在 [Mapping关系总结](#summary-of-mapping-relationships) 中介绍。
+`tablePrefix` 和 `recordPrefixSep` 都是用于区分 Key 空间中其他数据的特殊字符串常量。字符串常量的具体值在 [映射关系总结](#summary-of-mapping-relationships) 中介绍。
### 索引数据到 Key-Value 的映射
-TiDB 支持主键和二级索引（包括唯一索引和非唯一索引）。与表数据映射方案类似，TiDB 为表的每个索引分配一个索引 ID，用 `IndexID` 表示。
+TiDB 支持主键和二级索引（包括唯一索引和非唯一索引）。与表数据的映射方案类似，TiDB 为表的每个索引分配一个索引 ID，用 `IndexID` 表示。
-对于主键和唯一索引，为了能根据 Key-Value 快速定位对应的 `RowID`，此类 Key-Value 编码如下：
+对于主键和唯一索引，需要能够根据键值对快速定位到对应的 `RowID`，因此这类键值对的编码方式如下：
```
-Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
+Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue
Value: RowID
```
-对于不需要满足唯一性约束的普通二级索引，一个 Key 可能对应多行数据。需要根据 Key 的范围查询对应的 `RowID`，因此此类 Key-Value 必须按照以下规则编码：
+对于不需要满足唯一性约束的普通二级索引，一个 Key 可能对应多行数据。需要根据 Key 的范围查询对应的 `RowID`。因此，键值对的编码方式如下：
```
Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_{RowID}
Value: null
```
-### Mapping关系总结
+### 映射关系总结
-上述所有编码规则中的 `tablePrefix`、`recordPrefixSep` 和 `indexPrefixSep` 都是用来区分 KV 与 Key 空间中其他数据的字符串常量，定义如下：
+上述所有编码规则中的 `tablePrefix`、`recordPrefixSep` 和 `indexPrefixSep` 都是用于区分 Key 空间中其他数据的字符串常量，定义如下：
```
tablePrefix = []byte{'t'}
@@ -62,11 +62,11 @@ recordPrefixSep = []byte{'r'}
indexPrefixSep = []byte{'i'}
```
-还需注意，在上述编码方案中，无论是表数据还是索引数据的 Key 编码方案，表中的所有行具有相同的 Key 前缀，索引的所有数据也具有相同的前缀。具有相同前缀的数据在 TiKV 的 Key 空间中会被一同存放。因此，通过精心设计后缀部分的编码方案，确保编码前后比较保持一致，可以在 TiKV 中以有序的方式存储表数据或索引数据。利用此编码方案，表中的所有行数据会按照 `RowID` 在 TiKV 的 Key 空间中有序排列，特定索引的数据也会根据索引数据的具体值 (`indexedColumnsValue`) 顺序存放。
+还需要注意的是，在上述编码方案中，无论是表数据还是索引数据的 Key 编码方案，同一张表的所有行都有相同的 Key 前缀，同一个索引的所有数据也有相同的前缀。具有相同前缀的数据会在 TiKV 的 Key 空间中排列在一起。因此，通过精心设计后缀部分的编码方式，保证编码前后比较结果一致，表数据或索引数据就可以有序地存储在 TiKV 中。采用这种编码方案，一张表的所有行数据会按照 `RowID` 在 TiKV 的 Key 空间中有序排列，某个索引的数据也会根据索引数据的具体值（`indexedColumnsValue`）在 Key 空间中顺序排列。
### Key-Value 映射关系示例
-本节通过一个简单示例帮助理解 TiDB 的 Key-Value 映射关系。假设 TiDB 中存在如下表：
+本节通过一个简单示例帮助你理解 TiDB 的 Key-Value 映射关系。假设 TiDB 中存在如下表：
```sql
CREATE TABLE User (
@@ -87,7 +87,7 @@ CREATE TABLE User (
3, "PD", "Manager", 30
```
-每一行数据映射为一个 (Key, Value) 键值对，且该表的主键类型为 `int`，因此 `RowID` 的值即为主键值。假设该表的 `TableID` 为 `10`，则存储在 TiKV 上的表数据为：
+每一行数据会被映射为一个 (Key, Value) 键值对，并且该表有一个 int 类型的主键，所以 `RowID` 的值就是主键的值。假设该表的 `TableID` 为 `10`，那么其在 TiKV 上存储的表数据为：
```
t10_r1 --> ["TiDB", "SQL Layer", 10]
@@ -95,7 +95,7 @@ t10_r2 --> ["TiKV", "KV Engine", 20]
t10_r3 --> ["PD", " Manager", 30]
```
-除了主键外，表中还有一个非唯一的普通二级索引 `idxAge`，其 `IndexID` 为 `1`，存储在 TiKV 上的索引数据为：
+除了主键外，该表还有一个非唯一的普通二级索引 `idxAge`。假设 `IndexID` 为 `1`，那么其在 TiKV 上存储的索引数据为：
```
t10_i1_10_1 --> null
@@ -103,55 +103,55 @@ t10_i1_20_2 --> null
t10_i1_30_3 --> null
```
-上述示例展示了关系模型到 TiDB 中 Key-Value 模型的映射规则，以及此映射方案背后的考虑。
+上述示例展示了 TiDB 从关系模型到 Key-Value 模型的映射规则，以及该映射方案背后的设计考量。
## 元数据管理
-TiDB 中的每个数据库和表都拥有元数据，指示其定义和各种属性。这些信息也需要持久化存储，TiDB 同样将其存储在 TiKV 中。
+TiDB 中的每个数据库和表都有元数据，描述其定义和各种属性。这些信息同样需要持久化，TiDB 也将这些信息存储在 TiKV 中。
-每个数据库或表都被赋予一个唯一的 ID。作为唯一标识符，在将表数据编码为 Key-Value 时，此 ID 会在 Key 中以 `m_` 前缀编码，构成一个存储序列化元数据的 Key-Value 对。
+每个数据库或表都会分配一个唯一的 ID。作为唯一标识符，当表数据被编码为 Key-Value 时，这个 ID 会以 `m_` 前缀编码到 Key 中，构成一个以序列化元数据为 Value 的键值对。
-此外，TiDB 还使用一个专用的 (Key, Value) 键值对存储所有表结构信息的最新版本号。此 Key-Value 对是全局的，每当 DDL 操作状态发生变化时，其版本号会增加 `1`。TiDB 将此 Key-Value 持久化存储在 PD 服务器中，Key 为 `/tidb/ddl/global_schema_version`，Value 为 `int64` 类型的版本号值。同时，由于 TiDB 支持在线架构变更，它会在后台持续检测存储在 PD 服务器中的表结构信息的版本号是否发生变化，以确保在一定时间内可以获取到版本变更。
+此外，TiDB 还使用专门的 (Key, Value) 键值对来存储所有表结构信息的最新版本号。这个键值对是全局的，每当 DDL 操作状态发生变化时，其版本号会加 1。TiDB 将该键值对持久化存储在 PD server 中，Key 为 `/tidb/ddl/global_schema_version`，Value 是 `int64` 类型的版本号值。同时，由于 TiDB 支持在线变更表结构，它会保持一个后台线程，持续检测 PD server 中表结构信息的版本号是否发生变化。该线程也保证版本变更能在一定时间内被感知到。
## SQL 层概述
-TiDB 的 SQL 层，TiDB Server，将 SQL 语句转化为 Key-Value 操作，转发到分布式的 Key-Value 存储层 TiKV，组装 TiKV 返回的结果，最终将查询结果返回给客户端。
+TiDB 的 SQL 层（TiDB Server）将 SQL 语句转换为 Key-Value 操作，转发到分布式 Key-Value 存储层 TiKV，组装 TiKV 返回的结果，最终将查询结果返回给客户端。
-该层的节点是无状态的。这些节点本身不存储数据，完全是等价的。
+该层的节点是无状态的。这些节点本身不存储数据，且完全等价。
### SQL 计算
-最简单的 SQL 计算方案是前述的 [表数据到 Key-Value 的映射](#mapping-of-table-data-to-key-value)，它将 SQL 查询映射到 KV 查询，通过 KV 接口获取对应数据，并执行各种计算。
+最简单的 SQL 计算方案就是上一节介绍的 [表数据到 Key-Value 的映射](#mapping-of-table-data-to-key-value)，即将 SQL 查询映射为 KV 查询，通过 KV 接口获取对应数据，并进行各种计算。
-例如，要执行 `select count(*) from user where name = "TiDB"` 这条 SQL 语句，TiDB 需要读取表中的所有数据，然后检查 `name` 字段是否为 `TiDB`，如果是，则返回该行。过程如下：
+例如，执行 `select count(*) from user where name = "TiDB"` 这个 SQL 语句时，TiDB 需要读取表中的所有数据，然后判断 `name` 字段是否为 `TiDB`，如果是则返回该行。其过程如下：
-1. 构造 Key 范围：表中所有 `RowID` 在 `[0, MaxInt64)` 范围内。根据行数据的 Key 编码规则，使用 `0` 和 `MaxInt64` 可以构造一个 `[StartKey, EndKey)` 的范围（左闭右开）。
-2. 扫描 Key 范围：根据上述构造的范围读取 TiKV 中的数据。
-3. 过滤数据：对每一行读取到的数据，计算表达式 `name = "TiDB"`。如果结果为 `true`，则返回该行；否则跳过。
-4. 统计 `Count(*)`：对每一行满足条件的，累计到 `Count(*)` 的结果中。
+1. 构造 Key Range：一张表中所有 `RowID` 的范围是 `[0, MaxInt64)`。根据行数据 Key 的编码规则，使用 `0` 和 `MaxInt64` 可以构造一个左闭右开的 `[StartKey, EndKey)` 范围。
+2. 扫描 Key Range：根据上述构造的 Key 范围，从 TiKV 读取数据。
+3. 过滤数据：对每一行读取到的数据，计算 `name = "TiDB"` 这个表达式。如果结果为 `true`，则返回该行，否则跳过。
+4. 计算 `Count(*)`：对每一行满足条件的数据，累加到 `Count(*)` 的结果中。
-**整个流程示意如下：**
+**整个过程如下图所示：**
-此方案直观且可行，但在分布式数据库场景中存在一些明显的问题：
+这种方案直观且可行，但在分布式数据库场景下存在一些明显问题：
-- 在扫描过程中，每一行都通过至少一个 RPC 开销的 KV 操作从 TiKV 读取，若数据量很大，开销会非常高。
-- 不需要读取所有不满足条件的行。只需读取满足条件的行即可。
-- 从返回的结果中，只需要满足条件的行数，而不需要行的具体值。
+- 在扫描数据时，每一行都需要通过一次 KV 操作从 TiKV 读取，至少有一次 RPC 开销，如果需要扫描的数据量很大，开销会非常高。
+- 并不是所有行都需要读取，不满足条件的数据无需读取。
+- 查询结果只需要返回满足条件的行数，而不需要这些行的具体值。
### 分布式 SQL 操作
-为解决上述问题，应尽可能将计算靠近存储节点，避免大量 RPC 调用。首先，应将 SQL 谓词条件 `name = "TiDB"` 下推到存储节点进行计算，只返回符合条件的有效行，从而避免无意义的网络传输。然后，聚合函数 `Count(*)` 也可以下推到存储节点进行预聚合，每个节点只需返回一个 `Count(*)` 的结果，SQL 层再将各节点返回的 `Count(*)` 结果相加。
+为了解决上述问题，计算应尽量靠近存储节点，以避免大量 RPC 调用。首先，SQL 的谓词条件 `name = "TiDB"` 应下推到存储节点进行计算，只返回有效行，避免无意义的网络传输。其次，聚合函数 `Count(*)` 也可以下推到存储节点进行预聚合，每个节点只需返回一个 `Count(*)` 结果，SQL 层再对各节点返回的 `Count(*)` 结果进行求和。
-下图展示了数据逐层返回的流程：
+下图展示了数据逐层返回的过程：
### SQL 层架构
-前述部分介绍了 SQL 层的一些功能，希望你对 SQL 语句的处理有了基本了解。实际上，TiDB 的 SQL 层要复杂得多，包含许多模块和层级。下图列出了重要模块及调用关系：
+前文介绍了 SQL 层的一些功能，希望你对 SQL 语句的处理流程有了基本了解。实际上，TiDB 的 SQL 层要复杂得多，包含许多模块和层次。下图列出了重要模块及其调用关系：
-用户的 SQL 请求可以直接或通过 `Load Balancer` 发送到 TiDB Server。TiDB Server 会解析 `MySQL Protocol Packet`，获取请求内容，进行语法和语义分析，生成并优化查询计划，执行查询计划，获取并处理数据。所有数据都存储在 TiKV 集群中，因此在此过程中，TiDB Server 需要与 TiKV 交互以获取数据。最后，TiDB Server 将查询结果返回给用户。
+用户的 SQL 请求会直接或通过 `Load Balancer` 发送到 TiDB Server。TiDB Server 会解析 `MySQL Protocol Packet`，获取请求内容，对 SQL 请求进行语法和语义解析，制定并优化查询计划，执行查询计划，获取并处理数据。所有数据都存储在 TiKV 集群中，因此在此过程中，TiDB Server 需要与 TiKV 交互并获取数据。最后，TiDB Server 需要将查询结果返回给用户。
\ No newline at end of file