diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index d40d31fdaa6b3..17b4304d69821 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -1,41 +1,41 @@ --- title: 将 TiDB 集成到 Amazon AppFlow -summary: 逐步介绍如何将 TiDB 与 Amazon AppFlow 集成。 +summary: 逐步介绍如何将 TiDB 集成到 Amazon AppFlow。 --- # 将 TiDB 集成到 Amazon AppFlow -[Amazon AppFlow](https://aws.amazon.com/appflow/) 是一项完全托管的 API 集成服务，您可以使用它将您的软件即服务（SaaS）应用程序连接到 AWS 服务，并安全地传输数据。通过 Amazon AppFlow，您可以将数据从 TiDB 导入或导出到多种数据提供商，例如 Salesforce、Amazon S3、LinkedIn 和 GitHub。更多信息，请参见 AWS 文档中的 [Supported source and destination applications](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)。 +[Amazon AppFlow](https://aws.amazon.com/appflow/) 是一项全托管的 API 集成服务，你可以用它将你的 SaaS 应用程序与 AWS 服务连接，并安全地传输数据。通过 Amazon AppFlow，你可以在 TiDB 与多种数据提供方之间导入和导出数据，例如 Salesforce、Amazon S3、LinkedIn 和 GitHub。更多信息请参见 AWS 文档中的 [Supported source and destination applications](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)。 -本文档描述了如何将 TiDB 与 Amazon AppFlow 集成，并以集成 {{{ .starter }}} 集群为例。 +本文档介绍了如何将 TiDB 集成到 Amazon AppFlow，并以集成 TiDB Cloud Starter 集群为例进行说明。 -如果你没有 TiDB 集群，可以创建一个 [{{{ .starter }}}](https://tidbcloud.com/console/clusters) 集群，该集群免费且大约在 30 秒内即可创建完成。 +如果你还没有 TiDB 集群，可以创建一个 [TiDB Cloud Starter](https://tidbcloud.com/console/clusters) 集群，该集群免费且大约 30 秒即可创建完成。 -## 前提条件 +## 前置条件 - [Git](https://git-scm.com/) -- [JDK](https://openjdk.org/install/) 11 或以上 -- [Maven](https://maven.apache.org/install.html) 3.8 或以上 +- [JDK](https://openjdk.org/install/) 11 或更高版本 +- [Maven](https://maven.apache.org/install.html) 3.8 或更高版本 - [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 版本 2 -- [AWS Serverless Application Model Command Line Interface (AWS SAM CLI)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html) 1.58.0 或以上 -- 一个具有以下权限的 AWS [身份与访问管理（IAM）用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)： +- [AWS Serverless Application Model Command Line Interface (AWS SAM CLI)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html) 1.58.0 或更高版本 +- 一个满足以下要求的 AWS [Identity and Access Management (IAM) 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)： - - 用户可以使用 [访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) 访问 AWS。 - - 用户拥有以下权限： + - 该用户可以通过 [access key](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) 访问 AWS。 + - 该用户拥有以下权限： - - `AWSCertificateManagerFullAccess`：用于读取和写入 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)。 + - `AWSCertificateManagerFullAccess`：用于读写 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)。 - `AWSCloudFormationFullAccess`：SAM CLI 使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 来声明 AWS 资源。 - `AmazonS3FullAccess`：AWS CloudFormation 使用 [Amazon S3](https://aws.amazon.com/s3/?nc2=h_ql_prod_fs_s3) 进行发布。 - - `AWSLambda_FullAccess`：目前，[AWS Lambda](https://aws.amazon.com/lambda/?nc2=h_ql_prod_fs_lbd) 是实现 Amazon AppFlow 新连接器的唯一方式。 - - `IAMFullAccess`：SAM CLI 需要创建一个 `ConnectorFunctionRole` 以供连接器使用。 + - `AWSLambda_FullAccess`：目前，[AWS Lambda](https://aws.amazon.com/lambda/?nc2=h_ql_prod_fs_lbd) 是为 Amazon AppFlow 实现新连接器的唯一方式。 + - `IAMFullAccess`：SAM CLI 需要为连接器创建 `ConnectorFunctionRole`。 -- 一个 [SalesForce](https://developer.salesforce.com) 账户。 +- 一个 [SalesForce](https://developer.salesforce.com) 账号。 ## 第 1 步：注册 TiDB 连接器 ### 克隆代码 -克隆 [集成示例代码仓库](https://github.com/pingcap-inc/tidb-appflow-integration)，用于 TiDB 和 Amazon AppFlow： +克隆 TiDB 与 Amazon AppFlow 的[集成示例代码仓库](https://github.com/pingcap-inc/tidb-appflow-integration)： ```bash git clone https://github.com/pingcap-inc/tidb-appflow-integration @@ -50,74 +50,74 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration mvn clean package ``` -2. （可选）如果尚未配置 AWS 访问密钥 ID 和密钥，请进行配置。 +2. （可选）如果你还没有配置 AWS access key ID 和 secret access key，请进行配置。 ```bash aws configure ``` -3. 将 JAR 包作为 Lambda 上传： +3. 将你的 JAR 包上传为 Lambda： ```bash sam deploy --guided ``` - > **注意：** + > **Note:** > - > - `--guided` 选项会使用提示引导你完成部署。你的输入会被存储在配置文件中，默认为 `samconfig.toml`。 - > - `stack_name` 指定你要部署的 AWS Lambda 的名称。 - > - 该引导流程假设使用 AWS 作为 {{{ .starter }}} 的云提供商。若要使用 Amazon S3 作为源或目标，你需要将 AWS Lambda 的 `region` 设置为与 Amazon S3 相同。 - > - 如果你之前已运行过 `sam deploy --guided`，可以直接运行 `sam deploy`，SAM CLI 会使用 `samconfig.toml` 配置文件简化操作。 + > - `--guided` 选项会通过提示引导你完成部署。你的输入会被存储在配置文件中，默认是 `samconfig.toml`。 + > - `stack_name` 指定你正在部署的 AWS Lambda 的名称。 + > - 该引导流程默认使用 AWS 作为 TiDB Cloud Starter 的云服务商。如果你要将 Amazon S3 作为源或目标，需要将 AWS Lambda 的 `region` 设置为与 Amazon S3 相同。 + > - 如果你之前已经运行过 `sam deploy --guided`，可以直接运行 `sam deploy`，SAM CLI 会使用 `samconfig.toml` 配置文件简化交互。 - 如果看到类似如下的输出，说明 Lambda 已成功部署。 + 如果你看到如下类似输出，说明 Lambda 部署成功。 ``` Successfully created/updated stack - in ``` -4. 进入 [AWS Lambda 控制台](https://console.aws.amazon.com/lambda/home)，可以看到你刚刚上传的 Lambda。注意需要在右上角选择正确的区域。 +4. 进入 [AWS Lambda 控制台](https://console.aws.amazon.com/lambda/home)，你可以看到刚刚上传的 Lambda。请注意需要在窗口右上角选择正确的 region。 ![lambda dashboard](/media/develop/aws-appflow-step-lambda-dashboard.png) ### 使用 Lambda 注册连接器 -1. 在 [AWS 管理控制台](https://console.aws.amazon.com)，导航到 [Amazon AppFlow > Connectors](https://console.aws.amazon.com/appflow/home#/gallery)，点击 **Register new connector**。 +1. 在 [AWS 管理控制台](https://console.aws.amazon.com) 中，导航到 [Amazon AppFlow > Connectors](https://console.aws.amazon.com/appflow/home#/gallery)，点击 **Register new connector**。 ![register connector](/media/develop/aws-appflow-step-register-connector.png) -2. 在 **Register a new connector** 对话框中，选择你上传的 Lambda 函数，并用连接器名称指定连接器标签。 +2. 在 **Register a new connector** 对话框中，选择你上传的 Lambda 函数，并使用连接器名称指定 connector label。 ![register connector dialog](/media/develop/aws-appflow-step-register-connector-dialog.png) -3. 点击 **Register**。此时，TiDB 连接器注册成功。 +3. 点击 **Register**，此时 TiDB 连接器注册成功。 -## 第 2 步：创建数据流 +## 第 2 步：创建 flow 导航到 [Amazon AppFlow > Flows](https://console.aws.amazon.com/appflow/home#/list)，点击 **Create flow**。 ![create flow](/media/develop/aws-appflow-step-create-flow.png) -### 设置数据流名称 +### 设置 flow 名称 -输入数据流名称，然后点击 **Next**。 +输入 flow 名称，然后点击 **Next**。 ![name flow](/media/develop/aws-appflow-step-name-flow.png) ### 设置源表和目标表 -选择 **Source details** 和 **Destination details**。TiDB 连接器可以在两者中使用。 +选择 **Source details** 和 **Destination details**。TiDB 连接器可以用作两者之一。 -1. 选择源名称。本文以 **Salesforce** 作为示例源。 +1. 选择源名称。本文档以 **Salesforce** 作为示例源。 ![salesforce source](/media/develop/aws-appflow-step-salesforce-source.png) - 注册到 Salesforce 后，Salesforce 会向你的平台添加一些示例数据。以下步骤将以 **Account** 对象作为示例源对象。 + 注册 Salesforce 后，Salesforce 会在你的平台中添加一些示例数据。接下来的步骤将以 **Account** 对象作为示例源对象。 ![salesforce data](/media/develop/aws-appflow-step-salesforce-data.png) 2. 点击 **Connect**。 - 1. 在 **Connect to Salesforce** 对话框中，指定此连接的名称，然后点击 **Continue**。 + 1. 在 **Connect to Salesforce** 对话框中，指定该连接的名称，然后点击 **Continue**。 ![connect to salesforce](/media/develop/aws-appflow-step-connect-to-salesforce.png) @@ -125,15 +125,15 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration ![allow salesforce](/media/develop/aws-appflow-step-allow-salesforce.png) - > **注意：** + > **Note:** > - > 如果你的公司已使用 Salesforce 的专业版，REST API 默认未启用。你可能需要注册一个新的开发者版以使用 REST API。更多信息，请参见 [Salesforce Forum Topic](https://developer.salesforce.com/forums/?id=906F0000000D9Y2IAK)。 + > 如果你的公司已经在使用 Salesforce 的 Professional Edition，REST API 默认未启用。你可能需要注册一个新的 Developer Edition 才能使用 REST API。更多信息请参考 [Salesforce Forum Topic](https://developer.salesforce.com/forums/?id=906F0000000D9Y2IAK)。 3. 在 **Destination details** 区域，选择 **TiDB-Connector** 作为目标。此时会显示 **Connect** 按钮。 ![tidb dest](/media/develop/aws-appflow-step-tidb-dest.png) -4. 在点击 **Connect** 之前，你需要在 TiDB 中创建一个 `sf_account` 表，用于存储 Salesforce 的 **Account** 对象。注意，此表结构与 [Amazon AppFlow 教程](https://docs.aws.amazon.com/appflow/latest/userguide/flow-tutorial-set-up-source.html) 中的示例数据不同。 +4. 在点击 **Connect** 之前，你需要在 TiDB 中为 Salesforce 的 **Account** 对象创建一个 `sf_account` 表。注意，该表结构与 [Tutorial of Amazon AppFlow](https://docs.aws.amazon.com/appflow/latest/userguide/flow-tutorial-set-up-source.html) 中的示例数据不同。 ```sql CREATE TABLE `sf_account` ( @@ -147,29 +147,28 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration ); ``` -5. `sf_account` 表创建完成后，点击 **Connect**。会显示连接对话框。 - -6. 在 **Connect to TiDB-Connector** 对话框中，输入 TiDB 集群的连接属性。如果使用 {{{ .starter }}} 集群，需要将 **TLS** 选项设置为 `Yes`，以启用 TLS 连接。然后点击 **Connect**。 +5. 创建好 `sf_account` 表后，点击 **Connect**，会弹出连接对话框。 +6. 在 **Connect to TiDB-Connector** 对话框中，输入 TiDB 集群的连接属性。如果你使用的是 TiDB Cloud Starter 集群，需要将 **TLS** 选项设置为 `Yes`，以便 TiDB 连接器使用 TLS 连接。然后点击 **Connect**。 ![tidb connection message](/media/develop/aws-appflow-step-tidb-connection-message.png) -7. 现在可以获取你指定连接的数据库中的所有表。从下拉列表中选择 **sf_account** 表。 +7. 现在你可以获取到你指定数据库下的所有表。从下拉列表中选择 **sf_account** 表。 ![database](/media/develop/aws-appflow-step-database.png) - 下图显示了将 Salesforce **Account** 对象中的数据传输到 TiDB 中 `sf_account` 表的配置示例： + 下图展示了将 Salesforce **Account** 对象的数据传输到 TiDB 的 `sf_account` 表的配置： ![complete flow](/media/develop/aws-appflow-step-complete-flow.png) -8. 在 **Error handling** 区域，选择 **Stop the current flow run**。在 **Flow trigger** 区域，选择 **Run on demand** 触发类型，即需要手动运行数据流。然后点击 **Next**。 +8. 在 **Error handling** 区域，选择 **Stop the current flow run**。在 **Flow trigger** 区域，选择 **Run on demand** 触发类型，表示你需要手动运行 flow。然后点击 **Next**。 ![complete step1](/media/develop/aws-appflow-step-complete-step1.png) ### 设置映射规则 -将 Salesforce 中 **Account** 对象的字段映射到 TiDB 中的 `sf_account` 表，然后点击 **Next**。 +将 Salesforce 中 **Account** 对象的字段映射到 TiDB 的 `sf_account` 表，然后点击 **Next**。 -- `sf_account` 表在 TiDB 中是新建且为空的。 +- `sf_account` 表是新建的，当前为空。 ```sql test> SELECT * FROM sf_account; @@ -179,11 +178,11 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration +----+------+------+---------------+--------+----------+ ``` -- 设置映射规则时，可以在左侧选择源字段名，在右侧选择目标字段名，然后点击 **Map fields**，规则即被设置。 +- 设置映射规则时，你可以在左侧选择源字段名，在右侧选择目标字段名。然后点击 **Map fields**，即可设置一条规则。 ![add mapping rule](/media/develop/aws-appflow-step-add-mapping-rule.png) -- 本文档中需要的映射规则（源字段名 -> 目标字段名）包括： +- 本文档需要以下映射规则（源字段名 -> 目标字段名）： - Account ID -> id - Account Name -> name @@ -198,27 +197,27 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration ### （可选）设置过滤器 -如果你想为数据字段添加过滤条件，可以在此设置。否则跳过此步骤，点击 **Next**。 +如果你希望对数据字段添加一些过滤条件，可以在此处设置。否则跳过此步骤，点击 **Next**。 ![filters](/media/develop/aws-appflow-step-filters.png) -### 确认并创建数据流 +### 确认并创建 flow -确认即将创建的数据流信息。如果一切正常，点击 **Create flow**。 +确认即将创建的 flow 的信息。如果一切无误，点击 **Create flow**。 ![review](/media/develop/aws-appflow-step-review.png) -## 第 3 步：运行数据流 +## 第 3 步：运行 flow -在新建数据流的页面，点击右上角的 **Run flow**。 +在新建 flow 的页面右上角，点击 **Run flow**。 ![run flow](/media/develop/aws-appflow-step-run-flow.png) -下图显示了数据流成功运行的示例： +下图展示了 flow 成功运行的示例： ![run success](/media/develop/aws-appflow-step-run-success.png) -查询 `sf_account` 表，即可看到 Salesforce **Account** 对象中的记录已写入其中： +查询 `sf_account` 表，可以看到 Salesforce **Account** 对象中的记录已经写入该表： ```sql test> SELECT * FROM sf_account; @@ -241,23 +240,23 @@ test> SELECT * FROM sf_account; +--------------------+-------------------------------------+--------------------+---------------+--------+----------------+ ``` -## 重要事项 +## 注意事项 -- 如果出现问题，可以在 [CloudWatch](https://console.aws.amazon.com/cloudwatch/home) 页面查看日志。 +- 如果遇到问题，可以在 AWS 管理控制台的 [CloudWatch](https://console.aws.amazon.com/cloudwatch/home) 页面查看日志。 - 本文档中的步骤基于 [Building custom connectors using the Amazon AppFlow Custom Connector SDK](https://aws.amazon.com/blogs/compute/building-custom-connectors-using-the-amazon-appflow-custom-connector-sdk/)。 -- [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) **不是** 生产环境。 -- 为了避免篇幅过长，本文中的示例仅展示了 `Insert` 策略，但 `Update` 和 `Upsert` 策略也已测试，可以使用。 +- [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) **不是** 生产环境。 +- 为避免篇幅过长，本文档示例仅展示了 `Insert` 策略，`Update` 和 `Upsert` 策略也已测试并可用。 ## 需要帮助？ -在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或[提交支持工单](/support.md)。 +欢迎在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或[提交支持工单](/support.md)。 -在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或[提交支持工单](https://tidb.support.pingcap.com/)。 +欢迎在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或[提交支持工单](https://tidb.support.pingcap.com/)。 \ No newline at end of file diff --git a/develop/dev-guide-build-cluster-in-cloud.md b/develop/dev-guide-build-cluster-in-cloud.md index bd92dbb46d5a0..99c31f5eef8ff 100644 --- a/develop/dev-guide-build-cluster-in-cloud.md +++ b/develop/dev-guide-build-cluster-in-cloud.md @@ -1,15 +1,15 @@ --- -title: 搭建一个 {{{ .starter }}} 集群 -summary: 学习如何在 TiDB Cloud 中搭建一个 {{{ .starter }}} 集群并连接到它。 +title: 构建 TiDB Cloud Starter 集群 +summary: 了解如何在 TiDB Cloud 中构建 TiDB Cloud Starter 集群并连接到它。 --- -# 搭建一个 {{{ .starter }}} 集群 +# 构建 TiDB Cloud Starter 集群 -本文档将带你快速上手 TiDB。你将使用 [TiDB Cloud](https://www.pingcap.com/tidb-cloud) 创建一个 {{{ .starter }}}（原 Serverless）集群，连接到该集群，并在其上运行一个示例应用程序。 +本文档将带你快速上手 TiDB。你将使用 [TiDB Cloud](https://www.pingcap.com/tidb-cloud) 创建一个 TiDB Cloud Starter 集群，连接到它，并在其上运行一个示例应用程序。 如果你需要在本地机器上运行 TiDB，请参见 [本地启动 TiDB](/quick-start-with-tidb.md)。 @@ -17,21 +17,21 @@ summary: 学习如何在 TiDB Cloud 中搭建一个 {{{ .starter }}} 集群并 -本文档将带你快速上手 TiDB Cloud。你将创建一个 TiDB 集群，连接到该集群，并在其上运行一个示例应用程序。 +本文档将带你快速上手 TiDB Cloud。你将创建一个 TiDB 集群，连接到它，并在其上运行一个示例应用程序。 -## 第 1 步：创建一个 {{{ .starter }}} 集群 {#step-1-create-a-tidb-cloud-cluster} +## 第 1 步. 创建 TiDB Cloud Starter 集群 {#step-1-create-a-tidb-cloud-cluster} -1. 如果你还没有 TiDB Cloud 账号，请点击[这里](https://tidbcloud.com/free-trial)注册账号。 +1. 如果你还没有 TiDB Cloud 账号，请点击 [这里](https://tidbcloud.com/free-trial) 注册账号。 -2. [登录](https://tidbcloud.com/)你的 TiDB Cloud 账号。 +2. [登录](https://tidbcloud.com/) 你的 TiDB Cloud 账号。 3. 在 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击 **Create Cluster**。 -4. 在 **Create Cluster** 页面，**Starter** 默认已选中。如有需要，可修改默认集群名称，并选择你希望创建集群的区域。 +4. 在 **Create Cluster** 页面，**Starter** 默认已选中。如有需要可修改默认集群名称，然后选择你希望创建集群的区域。 -5. 点击 **Create** 创建一个 {{{ .starter }}} 集群。 +5. 点击 **Create** 创建 TiDB Cloud Starter 集群。 你的 TiDB Cloud 集群将在大约 30 秒内创建完成。 @@ -45,7 +45,7 @@ summary: 学习如何在 TiDB Cloud 中搭建一个 {{{ .starter }}} 集群并 > **注意：** > -> 对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 集群，连接集群时，必须在用户名中包含集群的前缀，并用引号包裹用户名。详细信息请参见 [用户名前缀](https://docs.pingcap.com/tidbcloud/select-cluster-tier#user-name-prefix)。 +> 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 集群，连接集群时，必须在用户名中包含集群的前缀，并用引号包裹用户名。更多信息请参见 [用户名前缀](https://docs.pingcap.com/tidbcloud/select-cluster-tier#user-name-prefix)。 @@ -53,11 +53,11 @@ summary: 学习如何在 TiDB Cloud 中搭建一个 {{{ .starter }}} 集群并 > **注意：** > -> 对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 集群，连接集群时，必须在用户名中包含集群的前缀，并用引号包裹用户名。详细信息请参见 [用户名前缀](/tidb-cloud/select-cluster-tier.md#user-name-prefix)。 +> 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 集群，连接集群时，必须在用户名中包含集群的前缀，并用引号包裹用户名。更多信息请参见 [用户名前缀](/tidb-cloud/select-cluster-tier.md#user-name-prefix)。 -## 第 2 步：连接到集群 +## 第 2 步. 连接到集群 1. 如果未安装 MySQL 客户端，请选择你的操作系统并按照以下步骤安装。 @@ -65,7 +65,7 @@ summary: 学习如何在 TiDB Cloud 中搭建一个 {{{ .starter }}} 集群并
-对于 macOS，如果尚未安装 [Homebrew](https://brew.sh/index)，请先安装，然后运行以下命令安装 MySQL 客户端： +对于 macOS，如果你还没有安装 [Homebrew](https://brew.sh/index)，请先安装，然后运行以下命令安装 MySQL 客户端： ```shell brew install mysql-client @@ -85,7 +85,7 @@ For compilers to find mysql-client you may need to set: export CPPFLAGS="-I/opt/homebrew/opt/mysql-client/include" ``` -要将 MySQL 客户端添加到 PATH，请在上述输出中找到以下命令（如果你的输出与本文档不一致，请使用你输出中的对应命令）并运行： +要将 MySQL 客户端添加到 PATH，请在上述输出中找到如下命令（如果你的输出与本文档不一致，请使用你输出中的对应命令）并运行： ```shell echo 'export PATH="/opt/homebrew/opt/mysql-client/bin:$PATH"' >> ~/.zshrc @@ -130,7 +130,7 @@ mysql Ver 15.1 Distrib 5.5.68-MariaDB, for Linux (x86_64) using readline 5.1 -2. 运行在[第 1 步](#step-1-create-a-tidb-cloud-cluster)中获取的连接字符串。 +2. 运行在 [第 1 步](#step-1-create-a-tidb-cloud-cluster) 获取的连接字符串。 ```shell @@ -141,8 +141,8 @@ mysql Ver 15.1 Distrib 5.5.68-MariaDB, for Linux (x86_64) using readline 5.1 > **注意：** > -> - 连接 {{{ .starter }}} 集群时，必须[使用 TLS 连接](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters)。 -> - 如果在连接 {{{ .starter }}} 集群时遇到问题，可以参考 [安全连接到 {{{ .starter }}} 集群](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters) 获取更多信息。 +> - 连接 TiDB Cloud Starter 集群时，必须 [使用 TLS 连接](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters)。 +> - 如果在连接 TiDB Cloud Starter 集群时遇到问题，可以参考 [安全连接到 TiDB Cloud Starter 集群](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters) 获取更多信息。 @@ -150,14 +150,14 @@ mysql Ver 15.1 Distrib 5.5.68-MariaDB, for Linux (x86_64) using readline 5.1 > **注意：** > -> - 连接 {{{ .starter }}} 集群时，必须[使用 TLS 连接](/tidb-cloud/secure-connections-to-serverless-clusters.md)。 -> - 如果在连接 {{{ .starter }}} 集群时遇到问题，可以参考 [安全连接到 {{{ .starter }}} 集群](/tidb-cloud/secure-connections-to-serverless-clusters.md) 获取更多信息。 +> - 连接 TiDB Cloud Starter 集群时，必须 [使用 TLS 连接](/tidb-cloud/secure-connections-to-serverless-clusters.md)。 +> - 如果在连接 TiDB Cloud Starter 集群时遇到问题，可以参考 [安全连接到 TiDB Cloud Starter 集群](/tidb-cloud/secure-connections-to-serverless-clusters.md) 获取更多信息。 -3. 输入密码以登录。 +3. 输入密码进行登录。 -## 第 3 步：执行 SQL 语句 +## 第 3 步. 执行 SQL 语句 让我们尝试在 TiDB Cloud 上执行你的第一条 SQL 语句。 @@ -181,12 +181,12 @@ SELECT 'Hello TiDB Cloud!'; -可以在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或[提交支持工单](/support.md)。 +可以在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](/support.md)。 -可以在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或[提交支持工单](https://tidb.support.pingcap.com/)。 +可以在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](https://tidb.support.pingcap.com/)。 diff --git a/develop/dev-guide-sample-application-cs.md b/develop/dev-guide-sample-application-cs.md index d6948dca3bc23..1687afe6456ef 100644 --- a/develop/dev-guide-sample-application-cs.md +++ b/develop/dev-guide-sample-application-cs.md @@ -13,11 +13,11 @@ C#（发音为 “C-Sharp”）是 .NET 家族中的一种编程语言，由 Mic - 下载 [.NET 9.0 SDK](https://dotnet.microsoft.com/en-us/download)。 - 本教程使用 `dotnet` 命令行工具。你也可以使用 Visual Studio Code IDE 来编写 C# 代码。 -- 要完成本教程，你需要有一个 TiDB 实例的访问权限。你可以使用 TiDB Cloud 上的 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier/#tidb-cloud-serverless) 或 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier/#tidb-cloud-dedicated) 集群，或者使用 `tiup playground` 启动的 TiDB 自建集群。 +- 要完成本教程，你需要有一个 TiDB 实例的访问权限。你可以使用 TiDB Cloud 上的 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 或 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier/#tidb-cloud-dedicated) 集群，或者使用 `tiup playground` 启动的 TiDB 自建集群。 -## 步骤 1. 创建控制台项目 +## 第 1 步：创建控制台项目 -使用 `console` 模板创建一个新项目。这会生成一个名为 `tidb_cs` 的新目录。在运行以下命令前，请先切换到你希望创建该目录的位置，或者直接指定完整路径。 +使用 `console` 模板创建一个新项目。这会生成一个名为 `tidb_cs` 的新目录。在运行以下命令前，请先切换到你希望创建该目录的位置，或者指定完整路径。 ``` $ dotnet new console -o tidb_cs @@ -28,7 +28,7 @@ Restoring /home/dvaneeden/tidb_cs/tidb_cs.csproj: Restore succeeded. ``` -## 步骤 2. 添加 MySql.Data 包 +## 第 2 步：添加 MySql.Data 包 .NET 的包管理器叫做 NuGet。MySQL Connector/NET 的 NuGet 包名称为 [MySql.Data](https://www.nuget.org/packages/MySql.Data)，它为 .NET 应用程序提供了 MySQL 协议的支持。如果你没有指定版本，NuGet 会安装最新的稳定版本（例如 9.3.0 版本）。 @@ -56,7 +56,7 @@ info : Writing assets file to disk. Path: /home/dvaneeden/tidb_cs/obj/project.as log : Restored /home/dvaneeden/tidb_cs/tidb_cs.csproj (in 551 ms). ``` -## 步骤 3. 更新代码 +## 第 3 步：更新代码 将 `Program.cs` 中的 “Hello World” 示例替换为以下代码。 @@ -97,20 +97,20 @@ public class Tutorial1 } ``` -这段代码会连接到指定 IP 和端口的 TiDB 实例。如果你使用 TiDB Cloud，请将连接字符串参数（如 hostname、port、user 和 password）替换为 [TiDB Cloud 控制台](https://tidbcloud.com/) 中提供的详细信息。 +这段代码会连接到指定 IP 和端口的 TiDB 实例。如果你使用 TiDB Cloud，请将连接字符串参数（如主机名、端口、用户和密码）替换为 [TiDB Cloud 控制台](https://tidbcloud.com/) 提供的详细信息。 -该代码会连接数据库，打印其版本信息，然后通过执行 [`TIDB_VERSION()`](/functions-and-operators/tidb-functions.md#tidb_version) SQL 查询获取更详细的版本信息，并最终输出该结果。 +该代码会连接数据库，打印其版本信息，然后使用 [`TIDB_VERSION()`](/functions-and-operators/tidb-functions.md#tidb_version) 执行 SQL 查询以获取更详细的版本信息，并最终打印该结果。 -## 步骤 4. 运行程序 +## 第 4 步：运行程序 ``` $ dotnet run Connecting to TiDB... -Connected to: 8.0.11-TiDB-v{{{ .tidb-version }}} +Connected to: 8.0.11-TiDB-v8.5.3 Version details: -Release Version: v{{{ .tidb-version }}} +Release Version: v8.5.3 Edition: Community Git Commit Hash: f43a13324440f92209e2a9f04c0bbe9cf763978d Git Branch: HEAD diff --git a/develop/dev-guide-sample-application-ruby-mysql2.md b/develop/dev-guide-sample-application-ruby-mysql2.md index 32c2e57f3d6e3..5db86bcaf3adb 100644 --- a/develop/dev-guide-sample-application-ruby-mysql2.md +++ b/develop/dev-guide-sample-application-ruby-mysql2.md @@ -11,11 +11,11 @@ TiDB 是兼容 MySQL 的数据库，[mysql2](https://github.com/brianmario/mysql - 搭建你的开发环境。 - 使用 mysql2 连接到你的 TiDB 集群。 -- 构建并运行你的应用程序。你还可以在 [示例代码片段](#sample-code-snippets) 中找到基本 CRUD 操作的代码示例。 +- 构建并运行你的应用程序。你还可以在 [示例代码片段](#sample-code-snippets) 中找到基本 CRUD 操作的示例代码。 -> **注意：** +> **Note:** > -> 本教程适用于 {{{ .starter }}}, {{{ .essential }}}, TiDB Cloud Dedicated 以及 TiDB 自建集群。 +> 本教程适用于 TiDB Cloud Starter、TiDB Cloud Essential、TiDB Cloud Dedicated 以及自建 TiDB 集群。 ## 前置条件 @@ -30,18 +30,18 @@ TiDB 是兼容 MySQL 的数据库，[mysql2](https://github.com/brianmario/mysql -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建你自己的 TiDB Cloud 集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 - 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建你自己的 TiDB Cloud 集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 - 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建本地集群。 -## 运行示例应用并连接 TiDB +## 运行示例应用连接 TiDB 本节演示如何运行示例应用代码并连接到 TiDB。 @@ -65,7 +65,7 @@ bundle install
为已有项目安装依赖 -对于你的已有项目，运行以下命令安装依赖包： +对于你已有的项目，运行以下命令安装依赖包： ```shell bundle add mysql2 dotenv @@ -78,28 +78,28 @@ bundle add mysql2 dotenv 根据你选择的 TiDB 部署方式，连接到你的 TiDB 集群。 -
+
1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入集群概览页。 -2. 点击右上角的 **Connect**，弹出连接对话框。 +2. 点击右上角的 **Connect**，弹出连接信息对话框。 3. 确保连接对话框中的配置与你的操作环境一致。 - **Connection Type** 设置为 `Public`。 - **Branch** 设置为 `main`。 - **Connect With** 设置为 `General`。 - - **Operating System** 与运行应用的操作系统一致。 + - **Operating System** 与你运行应用的操作系统一致。 4. 如果你还未设置密码，点击 **Generate Password** 生成随机密码。 -5. 运行以下命令，复制 `.env.example` 并重命名为 `.env`： +5. 运行以下命令，将 `.env.example` 复制并重命名为 `.env`： ```shell cp .env.example .env ``` -6. 编辑 `.env` 文件，按如下方式设置环境变量，并将对应的占位符 {} 替换为连接对话框中的参数： +6. 编辑 `.env` 文件，按如下方式设置环境变量，并将对应的占位符 `{}` 替换为连接对话框中的参数： ```dotenv DATABASE_HOST={host} @@ -110,9 +110,9 @@ bundle add mysql2 dotenv DATABASE_ENABLE_SSL=true ``` - > **注意** + > **Note** > - > 对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，使用公网地址时，**必须** 通过 `DATABASE_ENABLE_SSL` 启用 TLS 连接。 + > 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，使用公网地址时，**必须** 通过 `DATABASE_ENABLE_SSL` 启用 TLS 连接。 7. 保存 `.env` 文件。 @@ -121,21 +121,21 @@ bundle add mysql2 dotenv 1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入集群概览页。 -2. 点击右上角的 **Connect**，弹出连接对话框。 +2. 点击右上角的 **Connect**，弹出连接信息对话框。 3. 在连接对话框中，从 **Connection Type** 下拉列表选择 **Public**，然后点击 **CA cert** 下载 CA 证书。 - 如果你还未配置 IP 访问列表，点击 **Configure IP Access List**，或参考 [配置 IP 访问列表](https://docs.pingcap.com/tidbcloud/configure-ip-access-list) 进行配置，以便首次连接。 + 如果你还未配置 IP 访问列表，点击 **Configure IP Access List** 或参考 [配置 IP 访问列表](https://docs.pingcap.com/tidbcloud/configure-ip-access-list) 进行配置，以便首次连接。 - 除了 **Public** 连接类型外，TiDB Cloud Dedicated 还支持 **Private Endpoint** 和 **VPC Peering** 连接类型。更多信息请参考 [连接到你的 TiDB Cloud Dedicated 集群](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)。 + 除了 **Public** 连接类型，TiDB Cloud Dedicated 还支持 **Private Endpoint** 和 **VPC Peering** 连接类型。更多信息参见 [连接到你的 TiDB Cloud Dedicated 集群](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)。 -4. 运行以下命令，复制 `.env.example` 并重命名为 `.env`： +4. 运行以下命令，将 `.env.example` 复制并重命名为 `.env`： ```shell cp .env.example .env ``` -5. 编辑 `.env` 文件，按如下方式设置环境变量，并将对应的占位符 {} 替换为连接对话框中的参数： +5. 编辑 `.env` 文件，按如下方式设置环境变量，并将对应的占位符 `{}` 替换为连接对话框中的参数： ```dotenv DATABASE_HOST={host} @@ -147,24 +147,24 @@ bundle add mysql2 dotenv DATABASE_SSL_CA={downloaded_ssl_ca_path} ``` - > **注意** + > **Note** > > 推荐在使用公网地址连接 TiDB Cloud Dedicated 集群时启用 TLS 连接。 > - > 启用 TLS 连接时，请将 `DATABASE_ENABLE_SSL` 设置为 `true`，并通过 `DATABASE_SSL_CA` 指定从连接对话框下载的 CA 证书文件路径。 + > 启用 TLS 连接时，将 `DATABASE_ENABLE_SSL` 设置为 `true`，并通过 `DATABASE_SSL_CA` 指定从连接对话框下载的 CA 证书文件路径。 6. 保存 `.env` 文件。
-
+
-1. 运行以下命令，复制 `.env.example` 并重命名为 `.env`： +1. 运行以下命令，将 `.env.example` 复制并重命名为 `.env`： ```shell cp .env.example .env ``` -2. 编辑 `.env` 文件，按如下方式设置环境变量，并将对应的占位符 {} 替换为你自己的 TiDB 连接信息： +2. 编辑 `.env` 文件，按如下方式设置环境变量，并将对应的占位符 `{}` 替换为你自己的 TiDB 连接信息： ```dotenv DATABASE_HOST={host} @@ -192,7 +192,7 @@ ruby app.rb 如果连接成功，控制台会输出 TiDB 集群的版本信息，如下所示： ``` -🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v{{{ .tidb-version }}}) +🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.5.3) ⏳ Loading sample game data... ✅ Loaded sample game data. @@ -229,13 +229,13 @@ options.merge(sslca: ENV['DATABASE_SSL_CA']) if ENV['DATABASE_SSL_CA'] client = Mysql2::Client.new(options) ``` -> **注意** +> **Note** > -> 对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，使用公网地址时，**必须** 通过 `DATABASE_ENABLE_SSL` 启用 TLS 连接，但**不需要**通过 `DATABASE_SSL_CA` 指定 SSL CA 证书，因为 mysql2 gem 会按特定顺序自动查找本地已存在的 CA 证书文件。 +> 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，使用公网地址时，**必须** 通过 `DATABASE_ENABLE_SSL` 启用 TLS 连接，但**无需**通过 `DATABASE_SSL_CA` 指定 SSL CA 证书，因为 mysql2 gem 会按特定顺序自动查找本地已存在的 CA 证书文件。 ### 插入数据 -以下查询创建一个包含两个字段的玩家，并返回 `last_insert_id`： +以下查询语句创建一个包含两个字段的玩家，并返回 `last_insert_id`： ```ruby def create_player(client, coins, goods) @@ -250,7 +250,7 @@ end ### 查询数据 -以下查询根据 ID 返回指定玩家的记录： +以下查询语句根据 ID 返回指定玩家的记录： ```ruby def get_player_by_id(client, id) @@ -265,7 +265,7 @@ end ### 更新数据 -以下查询根据 ID 更新指定玩家的记录： +以下查询语句根据 ID 更新指定玩家的记录： ```ruby def update_player(client, player_id, inc_coins, inc_goods) @@ -280,7 +280,7 @@ end ### 删除数据 -以下查询删除指定玩家的记录： +以下查询语句删除指定玩家的记录： ```ruby def delete_player_by_id(client, id) @@ -295,31 +295,31 @@ end ## 最佳实践 -默认情况下，mysql2 gem 会按如下顺序查找本地已存在的 CA 证书文件，直到找到为止。 +默认情况下，mysql2 gem 会按特定顺序查找本地已存在的 CA 证书文件，直到找到为止。 1. `/etc/ssl/certs/ca-certificates.crt`（适用于 Debian、Ubuntu、Gentoo、Arch 或 Slackware） 2. `/etc/pki/tls/certs/ca-bundle.crt`（适用于 RedHat、Fedora、CentOS、Mageia、Vercel 或 Netlify） 3. `/etc/ssl/ca-bundle.pem`（适用于 OpenSUSE） 4. `/etc/ssl/cert.pem`（适用于 macOS 或 Alpine（docker 容器）） -虽然可以手动指定 CA 证书路径，但在多环境部署场景下，不同机器和环境的 CA 证书存放路径可能不同，这会带来较大不便。因此，推荐将 `sslca` 设置为 `nil`，以便在不同环境下灵活部署和使用。 +虽然可以手动指定 CA 证书路径，但在多环境部署场景下，不同机器和环境可能存储 CA 证书的位置不同，这样做会带来较大不便。因此，推荐将 `sslca` 设置为 `nil`，以便在不同环境下灵活部署和使用。 ## 后续步骤 -- 通过 [mysql2 官方文档](https://github.com/brianmario/mysql2#readme) 学习更多 mysql2 驱动的用法。 +- 通过 [mysql2 的官方文档](https://github.com/brianmario/mysql2#readme) 学习更多 mysql2 驱动的用法。 - 通过 [开发者指南](/develop/dev-guide-overview.md) 各章节，学习 TiDB 应用开发最佳实践，例如：[插入数据](/develop/dev-guide-insert-data.md)、[更新数据](/develop/dev-guide-update-data.md)、[删除数据](/develop/dev-guide-delete-data.md)、[查询数据](/develop/dev-guide-get-data-from-single-table.md)、[事务](/develop/dev-guide-transaction-overview.md) 以及 [SQL 性能优化](/develop/dev-guide-optimize-sql-overview.md)。 -- 通过专业的 [TiDB 开发者课程](https://www.pingcap.com/education/)，考试通过后获得 [TiDB 认证](https://www.pingcap.com/education/certification/)。 +- 通过专业的 [TiDB 开发者课程](https://www.pingcap.com/education/)，并在通过考试后获得 [TiDB 认证](https://www.pingcap.com/education/certification/)。 ## 需要帮助？ -欢迎在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](/support.md)。 +在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](/support.md)。 -欢迎在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](https://tidb.support.pingcap.com/)。 +在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](https://tidb.support.pingcap.com/)。 \ No newline at end of file diff --git a/develop/dev-guide-sample-application-ruby-rails.md b/develop/dev-guide-sample-application-ruby-rails.md index a8c6b16038af4..d2c1dff89223e 100644 --- a/develop/dev-guide-sample-application-ruby-rails.md +++ b/develop/dev-guide-sample-application-ruby-rails.md @@ -15,7 +15,7 @@ TiDB 是一个兼容 MySQL 的数据库，[Rails](https://github.com/rails/rails > **Note:** > -> 本教程适用于 {{{ .starter }}}, {{{ .essential }}}, TiDB Cloud Dedicated 以及 TiDB 自建集群。 +> 本教程适用于 TiDB Cloud Starter、TiDB Cloud Essential、TiDB Cloud Dedicated 以及自建 TiDB 集群。 ## 前置条件 @@ -30,22 +30,22 @@ TiDB 是一个兼容 MySQL 的数据库，[Rails](https://github.com/rails/rails -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建你自己的 TiDB Cloud 集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 - 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建你自己的 TiDB Cloud 集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 - 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建本地集群。 -## 运行示例应用并连接 TiDB +## 运行示例应用连接 TiDB 本节演示如何运行示例应用代码并连接到 TiDB。 -### 步骤 1：克隆示例应用仓库 +### 第 1 步：克隆示例应用仓库 在终端窗口中运行以下命令，克隆示例代码仓库： @@ -54,9 +54,9 @@ git clone https://github.com/tidb-samples/tidb-ruby-rails-quickstart.git cd tidb-ruby-rails-quickstart ``` -### 步骤 2：安装依赖 +### 第 2 步：安装依赖 -运行以下命令安装示例应用所需的依赖包（包括 `mysql2` 和 `dotenv`）： +运行以下命令，安装示例应用所需的依赖包（包括 `mysql2` 和 `dotenv`）： ```shell bundle install @@ -73,12 +73,12 @@ bundle add mysql2 dotenv
-### 步骤 3：配置连接信息 +### 第 3 步：配置连接信息 根据你选择的 TiDB 部署方式，连接到你的 TiDB 集群。 -
+
1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入集群概览页。 @@ -86,7 +86,7 @@ bundle add mysql2 dotenv 3. 在连接对话框中，从 **Connect With** 下拉列表选择 `Rails`，**Connection Type** 保持默认的 `Public`。 -4. 如果你还未设置密码，点击 **Generate Password** 生成一个随机密码。 +4. 如果你还未设置密码，点击 **Generate Password** 生成随机密码。 5. 运行以下命令，复制 `.env.example` 并重命名为 `.env`： @@ -102,7 +102,7 @@ bundle add mysql2 dotenv > **Note** > - > 对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，使用公共连接地址时，**必须** 通过 `ssl_mode=verify_identity` 参数启用 TLS 连接。 + > 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，使用公网地址时，**必须** 通过 `ssl_mode=verify_identity` 参数启用 TLS 连接。 7. 保存 `.env` 文件。 @@ -115,9 +115,9 @@ bundle add mysql2 dotenv 3. 在连接对话框中，从 **Connection Type** 下拉列表选择 **Public**，然后点击 **CA cert** 下载 CA 证书。 - 如果你还未配置 IP 访问列表，点击 **Configure IP Access List** 或参考 [Configure an IP Access List](https://docs.pingcap.com/tidbcloud/configure-ip-access-list) 进行配置，以便首次连接。 + 如果你还未配置 IP 访问列表，点击 **Configure IP Access List**，或参考 [配置 IP 访问列表](https://docs.pingcap.com/tidbcloud/configure-ip-access-list) 进行配置后再首次连接。 - 除了 **Public** 连接类型，TiDB Cloud Dedicated 还支持 **Private Endpoint** 和 **VPC Peering** 连接类型。更多信息请参考 [Connect to Your TiDB Cloud Dedicated Cluster](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)。 + 除了 **Public** 连接类型，TiDB Cloud Dedicated 还支持 **Private Endpoint** 和 **VPC Peering** 连接类型。更多信息请参考 [连接到你的 TiDB Cloud Dedicated 集群](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)。 4. 运行以下命令，复制 `.env.example` 并重命名为 `.env`： @@ -133,14 +133,14 @@ bundle add mysql2 dotenv > **Note** > - > 推荐在使用公共连接地址连接 TiDB Cloud Dedicated 时启用 TLS 连接。 + > 推荐在使用公网地址连接 TiDB Cloud Dedicated 时启用 TLS 连接。 > - > 启用 TLS 连接时，请将 `ssl_mode` 参数值设置为 `verify_identity`，并将 `sslca` 设置为从连接对话框下载的 CA 证书文件路径。 + > 启用 TLS 连接时，请将 `ssl_mode` 参数值设置为 `verify_identity`，`sslca` 参数值设置为连接对话框下载的 CA 证书文件路径。 6. 保存 `.env` 文件。
-
+
1. 运行以下命令，复制 `.env.example` 并重命名为 `.env`： @@ -148,7 +148,7 @@ bundle add mysql2 dotenv cp .env.example .env ``` -2. 编辑 `.env` 文件，按如下格式设置 `DATABASE_URL` 环境变量，并将 `{user}`、`{password}`、`{host}`、`{port}` 和 `{database}` 替换为你自己的 TiDB 连接信息： +2. 编辑 `.env` 文件，按如下格式设置 `DATABASE_URL` 环境变量，并将 `{user}`、`{password}`、`{host}`、`{port}`、`{database}` 替换为你自己的 TiDB 连接信息： ```dotenv DATABASE_URL='mysql2://{user}:{password}@{host}:{port}/{database}' @@ -161,7 +161,7 @@ bundle add mysql2 dotenv
-### 步骤 4：运行代码并检查结果 +### 第 4 步：运行代码并检查结果 1. 创建数据库和数据表： @@ -185,7 +185,7 @@ bundle add mysql2 dotenv 如果连接成功，控制台会输出 TiDB 集群的版本信息，如下所示： ``` -🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v{{{ .tidb-version }}}) +🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.5.3) ⏳ Loading sample game data... ✅ Loaded sample game data. @@ -201,7 +201,7 @@ bundle add mysql2 dotenv 完整示例代码及运行方法请参考 [tidb-samples/tidb-ruby-rails-quickstart](https://github.com/tidb-samples/tidb-ruby-rails-quickstart) 仓库。 -### 通过连接参数连接 TiDB +### 使用连接参数连接 TiDB 以下 `config/database.yml` 文件中的代码，通过环境变量定义的参数建立与 TiDB 的连接： @@ -225,7 +225,7 @@ production: > **Note** > -> 对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，使用公共连接地址时，**必须** 在 `DATABASE_URL` 中通过设置 `ssl_mode` 参数为 `verify_identity` 启用 TLS 连接，但**不需要**通过 `DATABASE_URL` 指定 SSL CA 证书，因为 mysql2 gem 会按特定顺序自动查找本地已存在的 CA 证书文件。 +> 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，使用公网地址时，**必须** 在 `DATABASE_URL` 中通过设置 `ssl_mode` 参数为 `verify_identity` 启用 TLS 连接，但**不需要**通过 `DATABASE_URL` 指定 SSL CA 证书，因为 mysql2 gem 会按特定顺序自动查找本地已存在的 CA 证书文件。 ### 插入数据 @@ -269,7 +269,7 @@ player.destroy ## 最佳实践 -默认情况下，ActiveRecord ORM 连接 TiDB 时使用的 mysql2 gem 会按如下顺序查找本地已存在的 CA 证书文件，直到找到为止： +默认情况下，ActiveRecord ORM 连接 TiDB 时使用的 mysql2 gem 会按如下顺序查找本地已存在的 CA 证书文件，直到找到为止。 1. /etc/ssl/certs/ca-certificates.crt # Debian / Ubuntu / Gentoo / Arch / Slackware 2. /etc/pki/tls/certs/ca-bundle.crt # RedHat / Fedora / CentOS / Mageia / Vercel / Netlify @@ -282,7 +282,7 @@ player.destroy - 通过 [ActiveRecord 官方文档](https://guides.rubyonrails.org/active_record_basics.html) 学习更多 ActiveRecord ORM 的用法。 - 通过 [开发者指南](/develop/dev-guide-overview.md) 各章节学习 TiDB 应用开发最佳实践，例如：[插入数据](/develop/dev-guide-insert-data.md)、[更新数据](/develop/dev-guide-update-data.md)、[删除数据](/develop/dev-guide-delete-data.md)、[查询数据](/develop/dev-guide-get-data-from-single-table.md)、[事务](/develop/dev-guide-transaction-overview.md) 以及 [SQL 性能优化](/develop/dev-guide-optimize-sql-overview.md)。 -- 通过专业的 [TiDB 开发者课程](https://www.pingcap.com/education/) 学习，并在通过考试后获得 [TiDB 认证](https://www.pingcap.com/education/certification/)。 +- 通过专业的 [TiDB 开发者课程](https://www.pingcap.com/education/)，考试通过后获得 [TiDB 认证](https://www.pingcap.com/education/certification/)。 ## 需要帮助？ diff --git a/functions-and-operators/json-functions/json-functions-validate.md b/functions-and-operators/json-functions/json-functions-validate.md index b6a4ffc2cb660..2f78155a56d6c 100644 --- a/functions-and-operators/json-functions/json-functions-validate.md +++ b/functions-and-operators/json-functions/json-functions-validate.md @@ -1,6 +1,6 @@ --- -title: 用于验证 JSON 文档的 JSON 函数 -summary: 了解用于验证 JSON 文档的 JSON 函数。 +title: JSON Functions That Validate JSON Documents +summary: Learn about JSON functions that validate JSON documents. --- # 用于验证 JSON 文档的 JSON 函数 @@ -9,7 +9,7 @@ summary: 了解用于验证 JSON 文档的 JSON 函数。 > **Note:** > -> 目前，该功能在 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群上不可用。 +> 目前，该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## [JSON_SCHEMA_VALID()](https://dev.mysql.com/doc/refman/8.0/en/json-validation-functions.html#function_json-schema-valid) @@ -21,13 +21,13 @@ summary: 了解用于验证 JSON 文档的 JSON 函数。 支持的校验关键字如下： -| 校验关键字 | 适用类型 | 描述 | +| 校验关键字 | 适用类型 | 描述 | |---|---|---| -| `type` | 任意 | 检查类型（如 `array` 和 `string`） | -| `enum` | 任意 | 检查值是否在指定的值数组中 | -| `const` | 任意 | 类似于 `enum`，但只针对单个值 | -| `allOf` | 任意 | 匹配所有指定的 schema | -| `anyOf` | 任意 | 匹配任意一个指定的 schema | +| `type` | 任意类型 | 检查类型（如 `array` 和 `string`） | +| `enum` | 任意类型 | 检查值是否在指定的值数组中 | +| `const` | 任意类型 | 类似于 `enum`，但只针对单个值 | +| `allOf` | 任意类型 | 匹配所有指定的 schema | +| `anyOf` | 任意类型 | 匹配任意一个指定的 schema | | `multipleOf` | `number`/`integer` | 检查值是否为指定值的倍数 | | `maximum` | `number`/`integer` | 检查值是否小于等于最大值（包含） | | `exclusiveMaximum` | `number`/`integer` | 检查值是否小于最大值（不包含） | @@ -35,18 +35,18 @@ summary: 了解用于验证 JSON 文档的 JSON 函数。 | `exclusiveMinimum` | `number`/`integer` | 检查值是否大于最小值（不包含） | | `maxlength` | `string` | 检查值的长度是否不超过指定值 | | `minLength` | `string` | 检查值的长度是否至少为指定值 | -| `format` | `string` | 检查字符串是否匹配指定的格式 | -| `pattern` | `string` | 检查字符串是否匹配指定的正则表达式 | +| `format` | `string` | 检查字符串是否匹配命名格式 | +| `pattern` | `string` | 检查字符串是否匹配正则表达式 | | `items` | `array` | 应用于数组元素的 schema | | `prefixItems` | `array` | 应用于数组中按位置元素的 schema | -| `maxItems` | `array` | 检查数组元素数量是否不超过指定值 | -| `minItems` | `array` | 检查数组元素数量是否至少为指定值 | +| `maxItems` | `array` | 检查数组中的元素数量是否不超过指定值 | +| `minItems` | `array` | 检查数组中的元素数量是否至少为指定值 | | `uniqueItems` | `array` | 检查数组中的元素是否唯一，`true`/`false`| | `contains` | `array` | 为数组中包含的元素设置 schema | | `maxContains` | `array` | 与 `contains` 一起使用，检查某元素最多出现的次数 | | `minContains` | `array` | 与 `contains` 一起使用，检查某元素最少出现的次数 | | `properties` | `object` | 应用于对象属性的 schema | -| `patternProperties` | `object` | 根据属性名的模式匹配应用 schema | +| `patternProperties` | `object` | 基于属性名模式匹配应用于特定属性的 schema | | `additionalProperties` | `object` | 是否允许额外属性，`true`/`false` | | `minProperties` | `object` | 检查对象最少拥有的属性数量 | | `maxProperties` | `object` | 检查对象最多拥有的属性数量 | @@ -119,7 +119,7 @@ mysql> SELECT JSON_TYPE(@j); 如上输出所示，`@j` 的类型为 `object`。这与 [`JSON_TYPE()`](/functions-and-operators/json-functions/json-functions-return.md#json_type) 的输出一致。 -现在验证某些属性是否存在。 +现在验证某些属性的存在。 ```sql SELECT JSON_SCHEMA_VALID('{"required": ["fruits","vegetables"]}',@j); @@ -134,7 +134,7 @@ SELECT JSON_SCHEMA_VALID('{"required": ["fruits","vegetables"]}',@j); 1 row in set (0.00 sec) ``` -如上输出所示，`fruits` 和 `vegetables` 属性的存在性校验通过。 +从上面的输出可以看到，`fruits` 和 `vegetables` 属性存在的校验通过。 ```sql SELECT JSON_SCHEMA_VALID('{"required": ["fruits","vegetables","grains"]}',@j); @@ -149,7 +149,7 @@ SELECT JSON_SCHEMA_VALID('{"required": ["fruits","vegetables","grains"]}',@j); 1 row in set (0.00 sec) ``` -如上输出所示，`fruits`、`vegetables` 和 `grains` 属性的存在性校验失败，因为 `grains` 不存在。 +从上面的输出可以看到，`fruits`、`vegetables` 和 `grains` 属性存在的校验失败，因为 `grains` 不存在。 现在验证 `fruits` 是否为数组。 @@ -166,7 +166,7 @@ SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "array"}}}',@j); 1 row in set (0.01 sec) ``` -如上输出确认了 `fruits` 是一个数组。 +上面的输出确认了 `fruits` 是一个数组。 ```sql SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "string"}}}',@j); @@ -181,7 +181,7 @@ SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "string"}}}',@j); 1 row in set (0.00 sec) ``` -如上输出显示 `fruits` **不是** 字符串。 +上面的输出表明 `fruits` **不是** 字符串。 现在验证数组中的元素数量。 @@ -198,7 +198,7 @@ SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "array", "minItems" 1 row in set (0.00 sec) ``` -如上输出显示 `fruits` 是一个包含至少 3 个元素的数组。 +上面的输出表明 `fruits` 是一个包含至少 3 个元素的数组。 ```sql SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "array", "minItems": 4}}}',@j); @@ -213,9 +213,9 @@ SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "array", "minItems" 1 row in set (0.00 sec) ``` -如上输出显示 `fruits` **不是** 一个包含至少 4 个元素的数组。因为它不满足最小元素数量的要求。 +上面的输出表明 `fruits` **不是** 一个包含至少 4 个元素的数组。这是因为它不满足最小元素数量的要求。 -对于整数值，你可以检查其是否在某个范围内。 +对于整数值，可以检查其是否在某个范围内。 ```sql SELECT JSON_SCHEMA_VALID('{"type": "integer", "minimum": 40, "maximum": 45}', '42'); @@ -240,7 +240,7 @@ SELECT JSON_SCHEMA_VALID('{"type": "integer", "minimum": 40, "maximum": 45}', '1 1 row in set (0.00 sec) ``` -对于字符串，你可以验证其是否匹配某个模式。 +对于字符串，可以验证其是否匹配某个模式。 ```sql SELECT JSON_SCHEMA_VALID('{"type": "string", "pattern": "^Ti"}', '"TiDB"'); @@ -337,7 +337,7 @@ SELECT JSON_SCHEMA_VALID('{"enum": ["TiDB", "MySQL"]}', '"SQLite"'); 1 row in set (0.00 sec) ``` -通过 `anyOf`，你可以组合多个要求，并验证是否满足其中任意一个。 +通过 `anyOf`，你可以组合多个要求，并验证是否满足其中任意一个要求。 ```sql SELECT JSON_SCHEMA_VALID('{"anyOf": [{"type": "string"},{"type": "integer"}]}', '"TiDB"'); @@ -380,11 +380,11 @@ SELECT JSON_SCHEMA_VALID('{"anyOf": [{"type": "string"},{"type": "integer"}]}', ## MySQL 兼容性 -- 如果 `JSON_SCHEMA_VALID()` 中用于校验的 schema 是无效的（如 `{"type": "sting"}`），MySQL 可能会接受，但 TiDB 会返回错误。注意 `"sting"` 拼写错误，应该为 `"string"`。 +- 如果 `JSON_SCHEMA_VALID()` 中用于校验的 schema 无效（如 `{"type": "sting"}`），MySQL 可能会接受，但 TiDB 会返回错误。注意 `"sting"` 拼写错误，正确应为 `"string"`。 - MySQL 使用的是较早的 JSON Schema 标准草案版本。 -## 另请参阅 +## 参见 - [JSON Schema 参考](https://json-schema.org/understanding-json-schema/reference) - [JSON 函数总览](/functions-and-operators/json-functions.md) -- [JSON 数据类型](/data-type-json.md) \ No newline at end of file +- [JSON 数据类型](/data-type-json.md) diff --git a/functions-and-operators/miscellaneous-functions.md b/functions-and-operators/miscellaneous-functions.md index 3136e824fae9a..e263480d16772 100644 --- a/functions-and-operators/miscellaneous-functions.md +++ b/functions-and-operators/miscellaneous-functions.md @@ -5,7 +5,7 @@ summary: 了解 TiDB 中的杂项函数。 # 杂项函数 -TiDB 支持 MySQL 8.0 中大多数的 [杂项函数](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html)。 +TiDB 支持大多数 MySQL 8.0 中的 [杂项函数](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html)。 ## 支持的函数 @@ -25,8 +25,8 @@ TiDB 支持 MySQL 8.0 中大多数的 [杂项函数](https://dev.mysql.com/doc/r | [`IS_IPV6()`](#is_ipv6) | 判断参数是否为 IPv6 地址 | | [`IS_UUID()`](#is_uuid) | 判断参数是否为 UUID | | [`NAME_CONST()`](#name_const) | 可用于重命名列名 | -| [`SLEEP()`](#sleep) | 休眠指定秒数。注意，对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群，`SLEEP()` 函数有最大 300 秒的休眠时间限制。 | -| [`UUID()`](#uuid) | 返回一个全局唯一标识符（UUID） | +| [`SLEEP()`](#sleep) | 休眠指定秒数。注意，对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群，`SLEEP()` 函数有最大 300 秒的休眠时间限制。 | +| [`UUID()`](#uuid) | 返回全局唯一标识符（UUID） | | [`UUID_TO_BIN()`](#uuid_to_bin) | 将 UUID 从文本格式转换为二进制格式 | | [`VALUES()`](#values) | 定义在 INSERT 期间要使用的值 | @@ -57,14 +57,14 @@ SELECT ANY_VALUE(id),GROUP_CONCAT(id),name FROM fruits GROUP BY name; 4 rows in set (0.00 sec) ``` -在上述示例中，TiDB 对第一个 `SELECT` 语句返回错误，因为 `id` 列是非聚合列且未包含在 `GROUP BY` 子句中。为了解决该问题，第二个 `SELECT` 查询使用 `ANY_VALUE()` 从每个分组中获取任意一个值，并使用 `GROUP_CONCAT()` 将每个分组内的所有 `id` 列的值拼接为一个字符串。该方法可以在不更改 SQL 模式的情况下，获取每个分组的一个值以及该分组的所有值。 +在上述示例中，TiDB 对第一个 `SELECT` 语句返回错误，因为 `id` 列是非聚合列且未包含在 `GROUP BY` 子句中。为了解决该问题，第二个 `SELECT` 查询使用 `ANY_VALUE()` 从每个分组中获取任意一个值，并使用 `GROUP_CONCAT()` 将每个分组内的所有 `id` 列的值拼接为一个字符串。该方法可以让你在不更改 SQL 模式的情况下，获取每个分组的一个值以及该分组的所有值。 ### BIN_TO_UUID() -`BIN_TO_UUID()` 和 `UUID_TO_BIN()` 可用于在文本格式 UUID 和二进制格式之间进行转换。两个函数都接受两个参数。 +`BIN_TO_UUID()` 和 `UUID_TO_BIN()` 可用于在文本格式 UUID 和二进制格式之间进行转换。这两个函数都接受两个参数。 - 第一个参数指定要转换的值。 -- 第二个参数（可选）用于控制二进制格式中字段的排序。 +- 第二个参数（可选）控制二进制格式中字段的排序。 ```sql SET @a := UUID(); @@ -145,7 +145,7 @@ TABLE t1; ### INET_ATON() -`INET_ATON()` 函数将点分十进制表示的 IPv4 地址转换为可以高效存储的数值。 +`INET_ATON()` 函数将点分十进制表示的 IPv4 地址转换为可以高效存储的数值版本。 ```sql SELECT INET_ATON('127.0.0.1'); @@ -416,4 +416,4 @@ TABLE t1; | 名称 | 描述 | |:------------|:-----------------------------------------------------------------------------------------------| -| [`UUID_SHORT()`](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid-short) | 提供一个在特定假设下唯一的 UUID，但这些假设在 TiDB 中不成立 [TiDB #4620](https://github.com/pingcap/tidb/issues/4620) | \ No newline at end of file +| [`UUID_SHORT()`](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid-short) | 在某些假设成立的情况下提供唯一的 UUID，但这些假设在 TiDB 中不成立 [TiDB #4620](https://github.com/pingcap/tidb/issues/4620) | \ No newline at end of file diff --git a/index-advisor.md b/index-advisor.md index 919c30a0d9dd3..bd21f44886c6f 100644 --- a/index-advisor.md +++ b/index-advisor.md @@ -5,19 +5,19 @@ summary: 了解如何使用 TiDB Index Advisor 优化查询性能。 # Index Advisor -在 v8.5.0 版本中，TiDB 引入了 Index Advisor 功能，帮助你通过推荐索引来优化工作负载并提升查询性能。通过新的 SQL 语句 `RECOMMEND INDEX`，你可以为单条查询或整个工作负载生成索引推荐。为了避免物理创建索引进行评估时的高资源消耗，TiDB 支持 [假设索引](#hypothetical-indexes)，即不会实际落地的逻辑索引。 +在 v8.5.0 版本中，TiDB 引入了 Index Advisor（索引顾问）功能，帮助你通过推荐索引来优化工作负载并提升查询性能。通过新的 SQL 语句 `RECOMMEND INDEX`，你可以为单条查询或整个工作负载生成索引推荐。为了避免物理创建索引进行评估时的高资源消耗，TiDB 支持 [假设索引](#hypothetical-indexes)，即不会实际落地的逻辑索引。 > **注意：** > -> 目前，该功能不支持在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群上使用。 +> 目前，该功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 -Index Advisor 会分析查询，识别如 `WHERE`、`GROUP BY` 和 `ORDER BY` 等子句中的可建索引列。随后，它会生成索引候选项，并通过假设索引评估其性能收益。TiDB 使用遗传搜索算法，从单列索引开始，迭代探索多列索引，利用 “What-If” 分析根据优化器执行计划成本评估潜在索引。只有当推荐索引能降低整体查询成本时，Index Advisor 才会推荐这些索引。 +Index Advisor 会分析查询，从 `WHERE`、`GROUP BY` 和 `ORDER BY` 等子句中识别可建索引的列。随后，它会生成索引候选项，并通过假设索引评估其性能收益。TiDB 使用遗传搜索算法，从单列索引开始，迭代探索多列索引，利用 “What-If” 分析根据优化器执行计划的成本评估潜在索引。当索引能够降低整体查询成本时，Index Advisor 会推荐这些索引。 除了 [推荐新索引](#recommend-indexes-using-the-recommend-index-statement) 外，Index Advisor 还会建议 [移除未使用的索引](#remove-unused-indexes)，以确保高效的索引管理。 ## 使用 `RECOMMEND INDEX` 语句推荐索引 -TiDB 引入了 `RECOMMEND INDEX` SQL 语句用于索引推荐任务。`RUN` 子命令会分析历史工作负载，并将推荐结果保存到系统表中。通过 `FOR` 选项，你可以针对特定 SQL 语句生成推荐，即使该语句之前未被执行过。你还可以使用额外的 [选项](#recommend-index-options) 进行高级控制。语法如下： +TiDB 引入了 `RECOMMEND INDEX` SQL 语句用于索引顾问相关任务。`RUN` 子命令会分析历史工作负载，并将推荐结果保存到系统表中。通过 `FOR` 选项，你可以针对特定 SQL 语句生成推荐，即使该语句之前未被执行过。你还可以使用额外的 [选项](#recommend-index-options) 进行高级控制。语法如下： ```sql RECOMMEND INDEX RUN [ FOR ] [] @@ -88,9 +88,9 @@ RECOMMEND INDEX RUN; +----------+-------+------------+---------------+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------+ ``` -在此场景下，Index Advisor 针对整个工作负载（而非单条查询）识别最优索引。工作负载中的查询来源于 TiDB 系统表 `INFORMATION_SCHEMA.STATEMENTS_SUMMARY`。 +在此场景下，Index Advisor 针对整个工作负载（而非单条查询）识别出最优索引。工作负载中的查询来源于 TiDB 系统表 `INFORMATION_SCHEMA.STATEMENTS_SUMMARY`。 -该表可能包含数万到数十万条查询，这可能会影响 Index Advisor 的性能。为解决此问题，Index Advisor 会优先分析执行频率最高的查询，因为这些查询对整体工作负载性能影响更大。默认情况下，Index Advisor 会选择前 1,000 条查询。你可以通过 [`max_num_query`](#recommend-index-options) 参数调整该值。 +该表可能包含数万到数十万条查询，这可能会影响 Index Advisor 的性能。为了解决这个问题，Index Advisor 会优先分析执行频率最高的查询，因为这些查询对整体工作负载性能影响更大。默认情况下，Index Advisor 会选择前 1,000 条查询。你可以通过 [`max_num_query`](#recommend-index-options) 参数调整该值。 `RECOMMEND INDEX` 语句的结果会存储在 `mysql.index_advisor_results` 表中。你可以查询该表以查看推荐的索引。以下示例展示了前述两次 `RECOMMEND INDEX` 语句执行后的系统表内容： @@ -117,7 +117,7 @@ RECOMMEND INDEX SHOW OPTION; 可用的选项包括： - `timeout`：指定执行 `RECOMMEND INDEX` 命令的最大允许时间。 -- `max_num_index`：指定 `RECOMMEND INDEX` 结果中包含的最大索引数量。 +- `max_num_index`：指定 `RECOMMEND INDEX` 结果中最多包含的索引数量。 - `max_index_columns`：指定结果中多列索引允许的最大列数。 - `max_num_query`：指定从语句摘要工作负载中选取的最大查询数量。 @@ -136,7 +136,7 @@ RECOMMEND INDEX SHOW OPTION; 4 rows in set (0.00 sec) ``` -要修改选项，可使用 `RECOMMEND INDEX SET` 语句。例如，修改 `timeout` 选项： +要修改某个选项，可使用 `RECOMMEND INDEX SET` 语句。例如，修改 `timeout` 选项： ```sql RECOMMEND INDEX SET timeout='20s'; @@ -145,23 +145,23 @@ Query OK, 1 row affected (0.00 sec) ### 限制 -索引推荐功能存在以下限制： +索引推荐功能目前存在以下限制： -- 目前不支持 [预处理语句](/develop/dev-guide-prepared-statement.md)。`RECOMMEND INDEX RUN` 语句无法为通过 `Prepare` 和 `Execute` 协议执行的查询推荐索引。 -- 目前不提供删除索引的推荐。 +- 暂不支持 [预处理语句](/develop/dev-guide-prepared-statement.md)。`RECOMMEND INDEX RUN` 语句无法为通过 `Prepare` 和 `Execute` 协议执行的查询推荐索引。 +- 暂不支持删除索引的推荐。 - 目前尚未提供 Index Advisor 的用户界面（UI）。 ## 移除未使用的索引 -在 v8.0.0 或更高版本中，你可以通过 [`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md) 和 [`INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) 识别工作负载中的未活跃索引。移除这些索引可以节省存储空间并减少开销。对于生产环境，强烈建议先将目标索引设置为不可见，并观察一个完整业务周期的影响后再彻底删除。 +在 v8.0.0 及更高版本中，你可以通过 [`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md) 和 [`INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) 识别工作负载中的未活跃索引。移除这些索引可以节省存储空间并减少开销。对于生产环境，强烈建议先将目标索引设置为不可见，并观察一个完整业务周期的影响后再永久删除。 ### 使用 `sys.schema_unused_indexes` -[`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md) 视图用于识别自所有 TiDB 实例上次启动以来未被使用过的索引。该视图基于包含 schema、表和列信息的系统表，提供每个索引的完整规格，包括 schema、表和索引名。你可以查询该视图，决定哪些索引需要设置为不可见或删除。 +[`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md) 视图用于识别自所有 TiDB 实例上次启动以来未被使用过的索引。该视图基于包含 schema、表和列信息的系统表，提供每个索引的完整规范，包括 schema、表和索引名称。你可以查询该视图，决定哪些索引需要设置为不可见或删除。 > **警告：** > -> 由于 `sys.schema_unused_indexes` 视图展示的是自所有 TiDB 实例上次启动以来未被使用的索引，请确保 TiDB 实例已运行足够长时间。否则，如果某些工作负载尚未运行，视图可能会显示误报。可使用以下 SQL 查询所有 TiDB 实例的运行时长。 +> 由于 `sys.schema_unused_indexes` 视图展示的是自所有 TiDB 实例上次启动以来未被使用的索引，请确保 TiDB 实例已运行足够长时间。否则，如果某些工作负载尚未运行，视图可能会显示误报。你可以使用以下 SQL 查询所有 TiDB 实例的运行时长。 > > ```sql > SELECT START_TIME,UPTIME FROM INFORMATION_SCHEMA.CLUSTER_INFO WHERE TYPE='tidb'; @@ -169,7 +169,7 @@ Query OK, 1 row affected (0.00 sec) ### 使用 `INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE` -[`INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) 表提供了选择性分桶、最后访问时间和访问行数等指标。以下示例展示了如何基于该表查询未使用或低效索引： +[`INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) 表提供了选择性分桶、最后访问时间和访问行数等指标。以下示例展示了如何基于该表查询未使用或低效的索引： ```sql -- Find indexes that have not been accessed in the last 30 days. @@ -192,11 +192,11 @@ WHERE last_access_time IS NOT NULL AND percentage_access_0 + percentage_access_0 ## 假设索引 -假设索引（Hypo Indexes）是通过 SQL 注释（类似于 [查询提示](/optimizer-hints.md)）而非 `CREATE INDEX` 语句创建的。这种方式可以让你在不实际落地索引的情况下轻量级地进行索引实验。 +假设索引（Hypothetical Indexes，简称 Hypo Indexes）是通过 SQL 注释（类似于 [查询提示](/optimizer-hints.md)）而非 `CREATE INDEX` 语句创建的。这种方式可以让你在不实际落地索引的情况下，轻量级地进行索引实验。 -例如，`/*+ HYPO_INDEX(t, idx_ab, a, b) */` 注释会指示查询优化器为表 `t` 的 `a`、`b` 列创建名为 `idx_ab` 的假设索引。优化器会生成该索引的元数据，但不会实际创建物理索引。如果适用，优化器会在查询优化过程中考虑该假设索引，而不会产生索引创建的相关开销。 +例如，`/*+ HYPO_INDEX(t, idx_ab, a, b) */` 注释会指示查询优化器为表 `t` 的列 `a` 和 `b` 创建一个名为 `idx_ab` 的假设索引。优化器会生成该索引的元数据，但不会实际创建物理索引。如果适用，优化器会在查询优化阶段考虑该假设索引，而不会产生索引创建的相关开销。 -`RECOMMEND INDEX` Advisor 会利用假设索引进行 “What-If” 分析，评估不同索引的潜在收益。你也可以直接使用假设索引，在正式创建索引前进行设计实验。 +`RECOMMEND INDEX` 顾问会利用假设索引进行 “What-If” 分析，以评估不同索引的潜在收益。你也可以直接使用假设索引，在正式创建索引前进行设计实验。 以下示例展示了如何在查询中使用假设索引： @@ -222,6 +222,6 @@ EXPLAIN FORMAT='verbose' SELECT /*+ HYPO_INDEX(t, idx_ab, a, b) */ a, b FROM t W +------------------------+---------+---------+-----------+-----------------------------+-------------------------------------------------+ ``` -在该示例中，`HYPO_INDEX` 注释指定了一个假设索引。使用该索引后，估算成本从 `392133.42` 降低到 `2.20`，实现了由全表扫描（`TableFullScan`）到索引范围扫描（`IndexRangeScan`）的优化。 +在该示例中，`HYPO_INDEX` 注释指定了一个假设索引。使用该索引后，估算成本从 `392133.42` 降低到 `2.20`，因为优化器可以采用索引范围扫描（`IndexRangeScan`）而非全表扫描（`TableFullScan`）。 基于你工作负载中的查询，TiDB 可以自动生成可能带来收益的索引候选项。它会利用假设索引评估这些索引的潜在收益，并推荐最有效的索引。 \ No newline at end of file diff --git a/information-schema/information-schema-cluster-info.md b/information-schema/information-schema-cluster-info.md index b91492fc5b0a2..9c7f66cca38cd 100644 --- a/information-schema/information-schema-cluster-info.md +++ b/information-schema/information-schema-cluster-info.md @@ -5,11 +5,11 @@ summary: 了解 `CLUSTER_INFO` 集群拓扑信息表。 # CLUSTER_INFO -`CLUSTER_INFO` 集群拓扑表提供了当前集群的拓扑信息、每个实例的版本信息、实例版本对应的 Git Hash、每个实例的启动时间以及每个实例的运行时间。 +`CLUSTER_INFO` 集群拓扑表提供了当前集群的拓扑信息、每个实例的版本信息、实例版本对应的 Git Hash、每个实例的启动时间以及每个实例的运行时长。 > **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ```sql @@ -39,7 +39,7 @@ desc cluster_info; * `INSTANCE`：实例地址，格式为 `IP:PORT` 的字符串。 * `STATUS_ADDRESS`：HTTP API 的服务地址。tikv-ctl、pd-ctl 或 tidb-ctl 中的一些命令可能会使用该 API 及其地址。你也可以通过该地址获取更多集群信息。详细信息请参考 [TiDB HTTP API 文档](https://github.com/pingcap/tidb/blob/release-8.5/docs/tidb_http_api.md)。 * `VERSION`：对应实例的语义化版本号。为了兼容 MySQL 版本号，TiDB 版本以 `${mysql-version}-${tidb-version}` 的格式展示。 -* `GIT_HASH`：编译实例版本时的 Git Commit Hash，用于标识两个实例是否为绝对一致的版本。 +* `GIT_HASH`：编译该实例版本时的 Git Commit Hash，用于标识两个实例是否为绝对一致的版本。 * `START_TIME`：对应实例的启动时间。 * `UPTIME`：对应实例的运行时长。 * `SERVER_ID`：对应实例的 server ID。 diff --git a/information-schema/information-schema-placement-policies.md b/information-schema/information-schema-placement-policies.md index e00709ab495b5..0f6ff1a888d31 100644 --- a/information-schema/information-schema-placement-policies.md +++ b/information-schema/information-schema-placement-policies.md @@ -9,7 +9,7 @@ summary: 了解 `PLACEMENT_POLICIES` information_schema 表。 > **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ```sql @@ -46,8 +46,8 @@ DESC placement_policies; CREATE TABLE t1 (a INT); CREATE PLACEMENT POLICY p1 primary_region="us-east-1" regions="us-east-1"; CREATE TABLE t3 (a INT) PLACEMENT POLICY=p1; -SHOW PLACEMENT; -- Shows all information, including table t3. -SELECT * FROM information_schema.placement_policies; -- Only shows placement policies, excluding t3. +SHOW PLACEMENT; -- 显示所有信息，包括表 t3。 +SELECT * FROM information_schema.placement_policies; -- 仅显示放置策略，不包括 t3。 ``` ```sql diff --git a/information-schema/information-schema-resource-groups.md b/information-schema/information-schema-resource-groups.md index 02d93e0b7b3f9..b378506ae5162 100644 --- a/information-schema/information-schema-resource-groups.md +++ b/information-schema/information-schema-resource-groups.md @@ -9,7 +9,7 @@ summary: 了解 `RESOURCE_GROUPS` information_schema 表。 > **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ```sql USE information_schema; @@ -51,7 +51,7 @@ Query OK, 0 rows affected (0.34 sec) ``` ```sql -SHOW CREATE RESOURCE GROUP rg1; -- 查看 `rg1` 资源组的定义 +SHOW CREATE RESOURCE GROUP rg1; -- 查看资源组 `rg1` 的定义 ``` ```sql @@ -81,7 +81,7 @@ SELECT * FROM information_schema.resource_groups WHERE NAME = 'rg1'; -- 查看 * `NAME`：资源组的名称。 * `RU_PER_SEC`：资源组的回填速率，单位为 RU/秒，其中 RU 表示 [Request Unit](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)。 * `PRIORITY`：在 TiKV 上待处理任务的绝对优先级。不同资源会根据 `PRIORITY` 设置进行调度。`PRIORITY` 高的任务会优先调度。对于 `PRIORITY` 相同的资源组，任务会根据 `RU_PER_SEC` 配置按比例调度。如果未指定 `PRIORITY`，则默认优先级为 `MEDIUM`。 -* `BURSTABLE`：是否允许该资源组超额使用可用的系统资源。 +* `BURSTABLE`：是否允许该资源组超额使用系统可用资源。 > **Note:** > diff --git a/information-schema/information-schema-runaway-watches.md b/information-schema/information-schema-runaway-watches.md index 57cfd3ebf833b..763c14271ec02 100644 --- a/information-schema/information-schema-runaway-watches.md +++ b/information-schema/information-schema-runaway-watches.md @@ -9,7 +9,7 @@ summary: 了解 `RUNAWAY_WATCHES` INFORMATION_SCHEMA 表。 > **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ```sql USE INFORMATION_SCHEMA; @@ -140,7 +140,7 @@ RESOURCE_GROUP_NAME: default - `ID`：监控项的 ID。 - `RESOURCE_GROUP_NAME`：资源组名称。 - `START_TIME`：开始时间。 -- `END_TIME`：结束时间。`UNLIMITED` 表示该监控项有效期为无限。 +- `END_TIME`：结束时间。`UNLIMITED` 表示该监控项的有效期为无限。 - `WATCH`：快速识别的匹配类型。取值如下： - `Plan` 表示匹配 Plan Digest，此时 `WATCH_TEXT` 列显示 Plan Digest。 - `Similar` 表示匹配 SQL Digest，此时 `WATCH_TEXT` 列显示 SQL Digest。 diff --git a/information-schema/information-schema-slow-query.md b/information-schema/information-schema-slow-query.md index 2cdc3cee79b95..9111ea584cd4a 100644 --- a/information-schema/information-schema-slow-query.md +++ b/information-schema/information-schema-slow-query.md @@ -7,19 +7,19 @@ summary: 了解 `SLOW_QUERY` INFORMATION_SCHEMA 表。 -`SLOW_QUERY` 表提供当前节点的慢查询信息，这些信息是 TiDB [慢日志文件](/tidb-configuration-file.md#slow-query-file) 的解析结果。表中的列名与慢日志中的字段名一一对应。 +`SLOW_QUERY` 表提供当前节点的慢查询信息，这些信息是 TiDB [慢日志文件](/tidb-configuration-file.md#slow-query-file)的解析结果。表中的列名与慢日志中的字段名一一对应。 -`SLOW_QUERY` 表提供当前节点的慢查询信息，这些信息是 TiDB [慢日志文件](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#slow-query-file) 的解析结果。表中的列名与慢日志中的字段名一一对应。 +`SLOW_QUERY` 表提供当前节点的慢查询信息，这些信息是 TiDB [慢日志文件](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#slow-query-file)的解析结果。表中的列名与慢日志中的字段名一一对应。 -> **注意：** +> **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 @@ -129,9 +129,9 @@ DESC SLOW_QUERY; `CLUSTER_SLOW_QUERY` 表提供整个集群所有节点的慢查询信息，这些信息是 TiDB 慢日志文件的解析结果。你可以像使用 `SLOW_QUERY` 表一样使用 `CLUSTER_SLOW_QUERY` 表。`CLUSTER_SLOW_QUERY` 表的表结构与 `SLOW_QUERY` 表的区别在于多了一个 `INSTANCE` 列。`INSTANCE` 列表示该慢查询信息所在的 TiDB 节点地址。 -> **注意：** +> **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 @@ -257,7 +257,7 @@ DESC SELECT COUNT(*) FROM CLUSTER_SLOW_QUERY WHERE user = 'u1'; 在上述执行计划中，`user = u1` 条件被下推到其他（`cop`）TiDB 节点，聚合算子也被下推（图中的 `StreamAgg` 算子）。 -目前，由于系统表没有收集统计信息，有时某些聚合算子无法下推，导致执行较慢。此时，你可以手动指定 SQL HINT，将聚合算子下推。例如： +目前，由于系统表没有统计信息，有时某些聚合算子无法下推，导致执行较慢。此时，你可以手动指定 SQL HINT，将聚合算子下推。例如： ```sql SELECT /*+ AGG_TO_COP() */ COUNT(*) FROM CLUSTER_SLOW_QUERY GROUP BY user; @@ -265,7 +265,7 @@ SELECT /*+ AGG_TO_COP() */ COUNT(*) FROM CLUSTER_SLOW_QUERY GROUP BY user; ## 查看执行信息 -通过在 `SLOW_QUERY` 表上执行 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 查询，你可以获得数据库获取慢查询信息的详细过程信息。但在 `CLUSTER_SLOW_QUERY` 表上执行 `EXPLAIN ANALYZE` 时**不会**返回这些信息。 +通过在 `SLOW_QUERY` 表上执行 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 查询，你可以获得数据库获取慢查询信息的详细过程信息。但在 `CLUSTER_SLOW_QUERY` 表上执行 `EXPLAIN ANALYZE` 时，**不会**返回这些信息。 示例： @@ -313,10 +313,10 @@ read_size: 4.06 MB | 字段 | 说明 | |---|---| -| `initialize` | 初始化耗时 | -| `read_file` | 读取慢日志文件耗时 | -| `parse_log.time` | 解析慢日志文件耗时 | +| `initialize` | 初始化所花费的时间 | +| `read_file` | 读取慢日志文件所花费的时间 | +| `parse_log.time` | 解析慢日志文件所花费的时间 | | `parse_log.concurrency` | 解析慢日志文件的并发度（由 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) 设置） | -| `total_file` | 慢日志文件总数 | +| `total_file` | 慢日志文件的总数 | | `read_file` | 实际读取的慢日志文件数 | -| `read_size` | 从日志文件读取的字节数 | +| `read_size` | 从日志文件中读取的字节数 | \ No newline at end of file diff --git a/information-schema/information-schema-tidb-hot-regions-history.md b/information-schema/information-schema-tidb-hot-regions-history.md index 5be9726168edb..349e14e502bc7 100644 --- a/information-schema/information-schema-tidb-hot-regions-history.md +++ b/information-schema/information-schema-tidb-hot-regions-history.md @@ -9,7 +9,7 @@ summary: 了解 `TIDB_HOT_REGIONS_HISTORY` information_schema 表。 > **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 @@ -19,7 +19,7 @@ summary: 了解 `TIDB_HOT_REGIONS_HISTORY` information_schema 表。 -默认情况下，记录间隔为 10 分钟，热点 Region 历史信息的保留周期为 7 天。 +默认情况下，记录间隔为 10 分钟，保留热点 Region 历史信息的周期为 7 天。 @@ -76,7 +76,7 @@ DESC tidb_hot_regions_history; > > `UPDATE_TIME`、`REGION_ID`、`STORE_ID`、`PEER_ID`、`IS_LEARNER`、`IS_LEADER` 和 `TYPE` 字段会下推到 PD 服务器执行。为了减少使用该表的开销，你必须指定查询的时间范围，并尽可能多地指定查询条件。例如：`select * from tidb_hot_regions_history where store_id = 11 and update_time > '2020-05-18 20:40:00' and update_time < '2020-05-18 21:40:00' and type='write'`。 -## 常见使用场景 +## 常见用户场景 * 查询指定时间段内的热点 Region。请将 `update_time` 替换为你的实际时间。 diff --git a/information-schema/information-schema-tidb-servers-info.md b/information-schema/information-schema-tidb-servers-info.md index 30c92f02121ff..1a9a0b6b30213 100644 --- a/information-schema/information-schema-tidb-servers-info.md +++ b/information-schema/information-schema-tidb-servers-info.md @@ -9,7 +9,7 @@ summary: 了解 `TIDB_SERVERS_INFO` INFORMATION_SCHEMA 表。 > **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ```sql USE INFORMATION_SCHEMA; @@ -50,7 +50,7 @@ SELECT * FROM TIDB_SERVERS_INFO\G PORT: 4000 STATUS_PORT: 10080 LEASE: 45s - VERSION: 8.0.11-TiDB-v{{{ .tidb-version }}} + VERSION: 8.0.11-TiDB-v8.5.3 GIT_HASH: 827d8ff2d22ac4c93ae1b841b79d468211e1d393 BINLOG_STATUS: Off LABELS: diff --git a/information-schema/information-schema-tikv-region-peers.md b/information-schema/information-schema-tikv-region-peers.md index af72a6e693c56..be9e9d86dfd6e 100644 --- a/information-schema/information-schema-tikv-region-peers.md +++ b/information-schema/information-schema-tikv-region-peers.md @@ -9,7 +9,7 @@ summary: 了解 `TIKV_REGION_PEERS` INFORMATION_SCHEMA 表。 > **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 此表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ```sql USE INFORMATION_SCHEMA; @@ -33,7 +33,7 @@ DESC TIKV_REGION_PEERS; 7 rows in set (0.01 sec) ``` -例如，你可以使用以下 SQL 语句查询 `WRITTEN_BYTES` 最大的前 3 个 Region 的具体 TiKV 地址： +例如，你可以使用以下 SQL 语句，查询 `WRITTEN_BYTES` 最大的前 3 个 Region 的具体 TiKV 地址： ```sql SELECT @@ -61,4 +61,4 @@ WHERE * PENDING：暂时不可用。 * DOWN：已下线并已转换。该副本不再提供服务。 * NORMAL：正常运行。 -* DOWN_SECONDS：下线持续时间，单位为秒。 \ No newline at end of file +* DOWN_SECONDS：下线持续的时间，单位为秒。 \ No newline at end of file diff --git a/information-schema/information-schema-tikv-region-status.md b/information-schema/information-schema-tikv-region-status.md index 353fb8ed17f7b..04c85c4091704 100644 --- a/information-schema/information-schema-tikv-region-status.md +++ b/information-schema/information-schema-tikv-region-status.md @@ -9,7 +9,7 @@ summary: 了解 `TIKV_REGION_STATUS` information_schema 表。 > **Note:** > -> 该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ```sql USE INFORMATION_SCHEMA; @@ -60,16 +60,16 @@ DESC TIKV_REGION_STATUS; * `IS_PARTITION`：Region 所属的表是否为分区表。 * `PARTITION_ID`：如果 Region 所属的表为分区表，则该列显示 Region 所属分区的 ID。 * `PARTITION_NAME`：如果 Region 所属的表为分区表，则该列显示 Region 所属分区的名称。 -* `EPOCH_CONF_VER`：Region 配置的版本号。当有 peer 增加或移除时，版本号会增加。 +* `EPOCH_CONF_VER`：Region 配置的版本号。当有 peer 被添加或移除时，版本号会增加。 * `EPOCH_VERSION`：Region 当前的版本号。当 Region 被分裂或合并时，版本号会增加。 * `WRITTEN_BYTES`：写入到 Region 的数据量（字节数）。 * `READ_BYTES`：从 Region 读取的数据量（字节数）。 * `APPROXIMATE_SIZE`：Region 的近似数据大小（MB）。 -* `APPROXIMATE_KEYS`：Region 中的近似键数量。 +* `APPROXIMATE_KEYS`：Region 的近似键数量。 * `REPLICATIONSTATUS_STATE`：Region 当前的副本状态。状态可能为 `UNKNOWN`、`SIMPLE_MAJORITY` 或 `INTEGRITY_OVER_LABEL`。 * `REPLICATIONSTATUS_STATEID`：与 `REPLICATIONSTATUS_STATE` 对应的标识符。 -此外，你还可以通过对 `EPOCH_CONF_VER`、`WRITTEN_BYTES` 和 `READ_BYTES` 列进行 `ORDER BY X LIMIT Y` 操作，实现 pd-ctl 中的 `top confver`、`top read` 和 `top write` 操作。 +此外，你可以通过对 `EPOCH_CONF_VER`、`WRITTEN_BYTES` 和 `READ_BYTES` 列进行 `ORDER BY X LIMIT Y` 操作，实现 pd-ctl 中的 `top confver`、`top read` 和 `top write` 操作。 你可以使用以下 SQL 语句查询写入数据量最多的前 3 个 Region： diff --git a/information-schema/information-schema-tikv-store-status.md b/information-schema/information-schema-tikv-store-status.md index 8163ff9919940..992f60084e606 100644 --- a/information-schema/information-schema-tikv-store-status.md +++ b/information-schema/information-schema-tikv-store-status.md @@ -9,7 +9,7 @@ summary: 了解 `TIKV_STORE_STATUS` INFORMATION_SCHEMA 表。 > **Note:** > -> 该表在 [Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ```sql USE INFORMATION_SCHEMA; @@ -51,7 +51,7 @@ DESC TIKV_STORE_STATUS; * `ADDRESS`：Store 的地址。 * `STORE_STATE`：Store 状态的标识符，对应 `STORE_STATE_NAME`。 * `STORE_STATE_NAME`：Store 状态的名称。名称为 `Up`、`Offline` 或 `Tombstone`。 -* `LABEL`：为 Store 设置的标签。 +* `LABEL`：为 Store 设置的标签集合。 * `VERSION`：Store 的版本号。 * `CAPACITY`：Store 的存储容量。 * `AVAILABLE`：Store 剩余的存储空间。 diff --git a/information-schema/information-schema.md b/information-schema/information-schema.md index 2669200599936..bfd2dc9f36b48 100644 --- a/information-schema/information-schema.md +++ b/information-schema/information-schema.md @@ -33,14 +33,14 @@ Information Schema 提供了一种符合 ANSI 标准的方式来查看系统元 | `PARAMETERS` | TiDB 未实现。返回零行。 | | [`PARTITIONS`](/information-schema/information-schema-partitions.md) | 提供表分区列表。 | | `PLUGINS` | TiDB 未实现。返回零行。 | -| [`PROCESSLIST`](/information-schema/information-schema-processlist.md) | 提供与命令 `SHOW PROCESSLIST` 类似的信息。 | +| [`PROCESSLIST`](/information-schema/information-schema-processlist.md) | 提供与 `SHOW PROCESSLIST` 命令类似的信息。 | | `PROFILING` | TiDB 未实现。返回零行。 | | `REFERENTIAL_CONSTRAINTS` | 提供 `FOREIGN KEY` 约束的信息。 | | `ROUTINES` | TiDB 未实现。返回零行。 | | [`SCHEMATA`](/information-schema/information-schema-schemata.md) | 提供与 `SHOW DATABASES` 类似的信息。 | | `SCHEMA_PRIVILEGES` | TiDB 未实现。返回零行。 | | `SESSION_STATUS` | TiDB 未实现。返回零行。 | -| [`SESSION_VARIABLES`](/information-schema/information-schema-session-variables.md) | 提供与命令 `SHOW SESSION VARIABLES` 类似的功能。 | +| [`SESSION_VARIABLES`](/information-schema/information-schema-session-variables.md) | 提供与 `SHOW SESSION VARIABLES` 命令类似的功能。 | | [`STATISTICS`](/information-schema/information-schema-statistics.md) | 提供表索引的信息。 | | [`TABLES`](/information-schema/information-schema-tables.md) | 提供当前用户可见的表列表。类似于 `SHOW TABLES`。 | | `TABLESPACES` | TiDB 未实现。返回零行。 | @@ -75,14 +75,14 @@ Information Schema 提供了一种符合 ANSI 标准的方式来查看系统元 | `PARAMETERS` | TiDB 未实现。返回零行。 | | [`PARTITIONS`](/information-schema/information-schema-partitions.md) | 提供表分区列表。 | | `PLUGINS` | TiDB 未实现。返回零行。 | -| [`PROCESSLIST`](/information-schema/information-schema-processlist.md) | 提供与命令 `SHOW PROCESSLIST` 类似的信息。 | +| [`PROCESSLIST`](/information-schema/information-schema-processlist.md) | 提供与 `SHOW PROCESSLIST` 命令类似的信息。 | | `PROFILING` | TiDB 未实现。返回零行。 | | `REFERENTIAL_CONSTRAINTS` | 提供 `FOREIGN KEY` 约束的信息。 | | `ROUTINES` | TiDB 未实现。返回零行。 | | [`SCHEMATA`](/information-schema/information-schema-schemata.md) | 提供与 `SHOW DATABASES` 类似的信息。 | | `SCHEMA_PRIVILEGES` | TiDB 未实现。返回零行。 | | `SESSION_STATUS` | TiDB 未实现。返回零行。 | -| [`SESSION_VARIABLES`](/information-schema/information-schema-session-variables.md) | 提供与命令 `SHOW SESSION VARIABLES` 类似的功能。 | +| [`SESSION_VARIABLES`](/information-schema/information-schema-session-variables.md) | 提供与 `SHOW SESSION VARIABLES` 命令类似的功能。 | | [`STATISTICS`](/information-schema/information-schema-statistics.md) | 提供表索引的信息。 | | [`TABLES`](/information-schema/information-schema-tables.md) | 提供当前用户可见的表列表。类似于 `SHOW TABLES`。 | | `TABLESPACES` | TiDB 未实现。返回零行。 | @@ -102,7 +102,7 @@ Information Schema 提供了一种符合 ANSI 标准的方式来查看系统元 > **注意：** > -> 下列部分表仅在 TiDB 自建版中支持，在 TiDB Cloud 中不支持。要获取 TiDB Cloud 上不支持的系统表完整列表，请参见 [System tables](https://docs.pingcap.com/tidbcloud/limited-sql-features#system-tables)。 +> 下列部分表仅支持 TiDB 自建版，不支持 TiDB Cloud。要获取 TiDB Cloud 上不支持的系统表完整列表，请参见 [System tables](https://docs.pingcap.com/tidbcloud/limited-sql-features#system-tables)。 | 表名 | 描述 | |-----------------------------------------------------------------------------------|------| @@ -110,37 +110,37 @@ Information Schema 提供了一种符合 ANSI 标准的方式来查看系统元 | [`CLIENT_ERRORS_SUMMARY_BY_HOST`](/information-schema/client-errors-summary-by-host.md) | 汇总客户端请求产生并返回给客户端的错误和警告信息。 | | [`CLIENT_ERRORS_SUMMARY_BY_USER`](/information-schema/client-errors-summary-by-user.md) | 汇总客户端产生的错误和警告信息。 | | [`CLIENT_ERRORS_SUMMARY_GLOBAL`](/information-schema/client-errors-summary-global.md) | 汇总客户端产生的错误和警告信息。 | -| [`CLUSTER_CONFIG`](/information-schema/information-schema-cluster-config.md) | 提供整个 TiDB 集群的配置详情。该表不适用于 TiDB Cloud。 | +| [`CLUSTER_CONFIG`](/information-schema/information-schema-cluster-config.md) | 提供整个 TiDB 集群的配置信息。该表不适用于 TiDB Cloud。 | | `CLUSTER_DEADLOCKS` | 提供 `DEADLOCKS` 表的集群级视图。 | -| [`CLUSTER_HARDWARE`](/information-schema/information-schema-cluster-hardware.md) | 提供在每个 TiDB 组件上发现的底层物理硬件详情。该表不适用于 TiDB Cloud。 | -| [`CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md) | 提供当前集群拓扑的详情。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`CLUSTER_HARDWARE`](/information-schema/information-schema-cluster-hardware.md) | 提供每个 TiDB 组件发现的底层物理硬件详情。该表不适用于 TiDB Cloud。 | +| [`CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md) | 提供当前集群拓扑的详细信息。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | | [`CLUSTER_LOAD`](/information-schema/information-schema-cluster-load.md) | 提供集群中 TiDB 服务器的当前负载信息。该表不适用于 TiDB Cloud。 | | [`CLUSTER_LOG`](/information-schema/information-schema-cluster-log.md) | 提供整个 TiDB 集群的日志。该表不适用于 TiDB Cloud。 | | `CLUSTER_MEMORY_USAGE` | 提供 `MEMORY_USAGE` 表的集群级视图。 | | `CLUSTER_MEMORY_USAGE_OPS_HISTORY` | 提供 `MEMORY_USAGE_OPS_HISTORY` 表的集群级视图。 | | `CLUSTER_PROCESSLIST` | 提供 `PROCESSLIST` 表的集群级视图。 | -| `CLUSTER_SLOW_QUERY` | 提供 `SLOW_QUERY` 表的集群级视图。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | -| `CLUSTER_STATEMENTS_SUMMARY` | 提供 `STATEMENTS_SUMMARY` 表的集群级视图。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | -| `CLUSTER_STATEMENTS_SUMMARY_HISTORY` | 提供 `STATEMENTS_SUMMARY_HISTORY` 表的集群级视图。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| `CLUSTER_SLOW_QUERY` | 提供 `SLOW_QUERY` 表的集群级视图。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| `CLUSTER_STATEMENTS_SUMMARY` | 提供 `STATEMENTS_SUMMARY` 表的集群级视图。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| `CLUSTER_STATEMENTS_SUMMARY_HISTORY` | 提供 `STATEMENTS_SUMMARY_HISTORY` 表的集群级视图。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | | `CLUSTER_TIDB_INDEX_USAGE` | 提供 `TIDB_INDEX_USAGE` 表的集群级视图。 | | `CLUSTER_TIDB_TRX` | 提供 `TIDB_TRX` 表的集群级视图。 | -| [`CLUSTER_SYSTEMINFO`](/information-schema/information-schema-cluster-systeminfo.md) | 提供集群中服务器内核参数配置的详情。该表不适用于 TiDB Cloud。 | +| [`CLUSTER_SYSTEMINFO`](/information-schema/information-schema-cluster-systeminfo.md) | 提供集群中服务器内核参数配置信息。该表不适用于 TiDB Cloud。 | | [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) | 提供 TiKV 服务器上的锁等待信息。 | | [`DDL_JOBS`](/information-schema/information-schema-ddl-jobs.md) | 提供与 `ADMIN SHOW DDL JOBS` 类似的输出。 | -| [`DEADLOCKS`](/information-schema/information-schema-deadlocks.md) | 提供最近发生的若干死锁错误的信息。 | +| [`DEADLOCKS`](/information-schema/information-schema-deadlocks.md) | 提供最近发生的若干死锁错误信息。 | | [`INSPECTION_RESULT`](/information-schema/information-schema-inspection-result.md) | 触发内部诊断检查。该表不适用于 TiDB Cloud。 | | [`INSPECTION_RULES`](/information-schema/information-schema-inspection-rules.md) | 已执行的内部诊断检查列表。该表不适用于 TiDB Cloud。 | | [`INSPECTION_SUMMARY`](/information-schema/information-schema-inspection-summary.md) | 重要监控指标的汇总报告。该表不适用于 TiDB Cloud。 | -| [`MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md) | 当前 TiDB 实例的内存使用情况。 | +| [`MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md) | 当前 TiDB 实例的内存使用情况。 | | [`MEMORY_USAGE_OPS_HISTORY`](/information-schema/information-schema-memory-usage-ops-history.md) | 当前 TiDB 实例内存相关操作的历史及执行依据。 | | [`METRICS_SUMMARY`](/information-schema/information-schema-metrics-summary.md) | 从 Prometheus 提取的指标汇总。该表不适用于 TiDB Cloud。 | | `METRICS_SUMMARY_BY_LABEL` | 参见 `METRICS_SUMMARY` 表。该表不适用于 TiDB Cloud。 | | [`METRICS_TABLES`](/information-schema/information-schema-metrics-tables.md) | 提供 `METRICS_SCHEMA` 中表的 PromQL 定义。该表不适用于 TiDB Cloud。 | -| [`PLACEMENT_POLICIES`](/information-schema/information-schema-placement-policies.md) | 提供所有放置策略的信息。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`PLACEMENT_POLICIES`](/information-schema/information-schema-placement-policies.md) | 提供所有放置策略的信息。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | | [`SEQUENCES`](/information-schema/information-schema-sequences.md) | TiDB 的序列实现基于 MariaDB。 | -| [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md) | 提供当前 TiDB 服务器上的慢查询信息。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | -| [`STATEMENTS_SUMMARY`](/statement-summary-tables.md) | 类似于 MySQL 的 performance_schema 语句汇总表。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | -| [`STATEMENTS_SUMMARY_HISTORY`](/statement-summary-tables.md) | 类似于 MySQL 的 performance_schema 语句汇总历史表。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md) | 提供当前 TiDB 服务器上的慢查询信息。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`STATEMENTS_SUMMARY`](/statement-summary-tables.md) | 类似于 MySQL 的 performance_schema 语句汇总。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`STATEMENTS_SUMMARY_HISTORY`](/statement-summary-tables.md) | 类似于 MySQL 的 performance_schema 语句汇总历史。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | | [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-storage-stats.md) | 提供存储中表大小的详细信息。 | | [`TIDB_HOT_REGIONS`](/information-schema/information-schema-tidb-hot-regions.md) | 提供哪些 Region 为热点的统计信息。 | | [`TIDB_HOT_REGIONS_HISTORY`](/information-schema/information-schema-tidb-hot-regions-history.md) | 提供哪些 Region 为热点的历史统计信息。 | @@ -163,36 +163,36 @@ Information Schema 提供了一种符合 ANSI 标准的方式来查看系统元 | [`CLIENT_ERRORS_SUMMARY_BY_HOST`](/information-schema/client-errors-summary-by-host.md) | 汇总客户端请求产生并返回给客户端的错误和警告信息。 | | [`CLIENT_ERRORS_SUMMARY_BY_USER`](/information-schema/client-errors-summary-by-user.md) | 汇总客户端产生的错误和警告信息。 | | [`CLIENT_ERRORS_SUMMARY_GLOBAL`](/information-schema/client-errors-summary-global.md) | 汇总客户端产生的错误和警告信息。 | -| [`CLUSTER_CONFIG`](https://docs.pingcap.com/tidb/stable/information-schema-cluster-config) | 提供整个 TiDB 集群的配置详情。该表不适用于 TiDB Cloud。 | +| [`CLUSTER_CONFIG`](https://docs.pingcap.com/tidb/stable/information-schema-cluster-config) | 提供整个 TiDB 集群的配置信息。该表不适用于 TiDB Cloud。 | | `CLUSTER_DEADLOCKS` | 提供 `DEADLOCKS` 表的集群级视图。 | -| [`CLUSTER_HARDWARE`](https://docs.pingcap.com/tidb/stable/information-schema-cluster-hardware) | 提供在每个 TiDB 组件上发现的底层物理硬件详情。该表不适用于 TiDB Cloud。 | -| [`CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md) | 提供当前集群拓扑的详情。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`CLUSTER_HARDWARE`](https://docs.pingcap.com/tidb/stable/information-schema-cluster-hardware) | 提供每个 TiDB 组件发现的底层物理硬件详情。该表不适用于 TiDB Cloud。 | +| [`CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md) | 提供当前集群拓扑的详细信息。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | | [`CLUSTER_LOAD`](https://docs.pingcap.com/tidb/stable/information-schema-cluster-load) | 提供集群中 TiDB 服务器的当前负载信息。该表不适用于 TiDB Cloud。 | | [`CLUSTER_LOG`](https://docs.pingcap.com/tidb/stable/information-schema-cluster-log) | 提供整个 TiDB 集群的日志。该表不适用于 TiDB Cloud。 | | `CLUSTER_MEMORY_USAGE` | 提供 `MEMORY_USAGE` 表的集群级视图。该表不适用于 TiDB Cloud。 | | `CLUSTER_MEMORY_USAGE_OPS_HISTORY` | 提供 `MEMORY_USAGE_OPS_HISTORY` 表的集群级视图。该表不适用于 TiDB Cloud。 | | `CLUSTER_PROCESSLIST` | 提供 `PROCESSLIST` 表的集群级视图。 | -| `CLUSTER_SLOW_QUERY` | 提供 `SLOW_QUERY` 表的集群级视图。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | -| `CLUSTER_STATEMENTS_SUMMARY` | 提供 `STATEMENTS_SUMMARY` 表的集群级视图。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | -| `CLUSTER_STATEMENTS_SUMMARY_HISTORY` | 提供 `STATEMENTS_SUMMARY_HISTORY` 表的集群级视图。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| `CLUSTER_SLOW_QUERY` | 提供 `SLOW_QUERY` 表的集群级视图。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| `CLUSTER_STATEMENTS_SUMMARY` | 提供 `STATEMENTS_SUMMARY` 表的集群级视图。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| `CLUSTER_STATEMENTS_SUMMARY_HISTORY` | 提供 `STATEMENTS_SUMMARY_HISTORY` 表的集群级视图。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | | `CLUSTER_TIDB_TRX` | 提供 `TIDB_TRX` 表的集群级视图。 | -| [`CLUSTER_SYSTEMINFO`](https://docs.pingcap.com/tidb/stable/information-schema-cluster-systeminfo) | 提供集群中服务器内核参数配置的详情。该表不适用于 TiDB Cloud。 | +| [`CLUSTER_SYSTEMINFO`](https://docs.pingcap.com/tidb/stable/information-schema-cluster-systeminfo) | 提供集群中服务器内核参数配置信息。该表不适用于 TiDB Cloud。 | | [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) | 提供 TiKV 服务器上的锁等待信息。 | | [`DDL_JOBS`](/information-schema/information-schema-ddl-jobs.md) | 提供与 `ADMIN SHOW DDL JOBS` 类似的输出。 | -| [`DEADLOCKS`](/information-schema/information-schema-deadlocks.md) | 提供最近发生的若干死锁错误的信息。 | +| [`DEADLOCKS`](/information-schema/information-schema-deadlocks.md) | 提供最近发生的若干死锁错误信息。 | | [`INSPECTION_RESULT`](https://docs.pingcap.com/tidb/stable/information-schema-inspection-result) | 触发内部诊断检查。该表不适用于 TiDB Cloud。 | | [`INSPECTION_RULES`](https://docs.pingcap.com/tidb/stable/information-schema-inspection-rules) | 已执行的内部诊断检查列表。该表不适用于 TiDB Cloud。 | | [`INSPECTION_SUMMARY`](https://docs.pingcap.com/tidb/stable/information-schema-inspection-summary) | 重要监控指标的汇总报告。该表不适用于 TiDB Cloud。 | -| [`MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md) | 当前 TiDB 实例的内存使用情况。 | +| [`MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md) | 当前 TiDB 实例的内存使用情况。 | | [`MEMORY_USAGE_OPS_HISTORY`](/information-schema/information-schema-memory-usage-ops-history.md) | 当前 TiDB 实例内存相关操作的历史及执行依据。 | | [`METRICS_SUMMARY`](https://docs.pingcap.com/tidb/stable/information-schema-metrics-summary) | 从 Prometheus 提取的指标汇总。该表不适用于 TiDB Cloud。 | | `METRICS_SUMMARY_BY_LABEL` | 参见 `METRICS_SUMMARY` 表。该表不适用于 TiDB Cloud。 | | [`METRICS_TABLES`](https://docs.pingcap.com/tidb/stable/information-schema-metrics-tables) | 提供 `METRICS_SCHEMA` 中表的 PromQL 定义。该表不适用于 TiDB Cloud。 | -| [`PLACEMENT_POLICIES`](https://docs.pingcap.com/tidb/stable/information-schema-placement-policies) | 提供所有放置策略的信息。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`PLACEMENT_POLICIES`](https://docs.pingcap.com/tidb/stable/information-schema-placement-policies) | 提供所有放置策略的信息。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | | [`SEQUENCES`](/information-schema/information-schema-sequences.md) | TiDB 的序列实现基于 MariaDB。 | -| [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md) | 提供当前 TiDB 服务器上的慢查询信息。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | -| [`STATEMENTS_SUMMARY`](/statement-summary-tables.md) | 类似于 MySQL 的 performance_schema 语句汇总表。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | -| [`STATEMENTS_SUMMARY_HISTORY`](/statement-summary-tables.md) | 类似于 MySQL 的 performance_schema 语句汇总历史表。该表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。| +| [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md) | 提供当前 TiDB 服务器上的慢查询信息。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`STATEMENTS_SUMMARY`](/statement-summary-tables.md) | 类似于 MySQL 的 performance_schema 语句汇总。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 | +| [`STATEMENTS_SUMMARY_HISTORY`](/statement-summary-tables.md) | 类似于 MySQL 的 performance_schema 语句汇总历史。该表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。| | [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-storage-stats.md) | 提供存储中表大小的详细信息。 | | [`TIDB_HOT_REGIONS`](https://docs.pingcap.com/tidb/stable/information-schema-tidb-hot-regions) | 提供哪些 Region 为热点的统计信息。该表不适用于 TiDB Cloud。 | | [`TIDB_HOT_REGIONS_HISTORY`](/information-schema/information-schema-tidb-hot-regions-history.md) | 提供哪些 Region 为热点的历史统计信息。 | diff --git a/latest_translation_commit.json b/latest_translation_commit.json index 6afb64e6700b3..d8f4b2e3b3ebf 100644 --- a/latest_translation_commit.json +++ b/latest_translation_commit.json @@ -1 +1 @@ -{"target":"release-8.5","sha":"811c6140bb8d4e57c7651dbe9ccdf66806aaec12"} \ No newline at end of file +{"target":"release-8.5","sha":"0e643ecb734811cbeb4c03fc66225906b444b0d4"} \ No newline at end of file diff --git a/optimistic-transaction.md b/optimistic-transaction.md index a699bec983e00..bae83eed7d5ea 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -1,52 +1,52 @@ --- -title: TiDB 乐观事务模型 +title: TiDB Optimistic Transaction Model summary: 了解 TiDB 中的乐观事务模型。 --- # TiDB 乐观事务模型 -采用乐观事务时，冲突的变更会在事务提交时被检测到。这有助于在并发事务很少修改相同行的情况下提高性能，因为可以跳过获取行锁的过程。在并发事务频繁修改相同行（冲突）的情况下，乐观事务可能比 [Pessimistic Transactions](/pessimistic-transaction.md) 表现更差。 +在乐观事务中，冲突的变更会在事务提交阶段被检测出来。当并发事务很少修改相同行时，这有助于提升性能，因为可以跳过获取行锁的过程。如果并发事务频繁修改相同行（即发生冲突），乐观事务的性能可能会比 [悲观事务](/pessimistic-transaction.md) 更差。 -在启用乐观事务之前，请确保你的应用程序正确处理 `COMMIT` 语句可能返回的错误。如果你不确定你的应用程序如何处理，建议改用 Pessimistic Transactions。 +在启用乐观事务之前，请确保你的应用程序能够正确处理 `COMMIT` 语句可能返回的错误。如果你不确定应用程序的处理方式，建议使用悲观事务。 -> **Note:** +> **注意：** > -> 从 v3.0.8 版本开始，TiDB 默认使用 [pessimistic transaction mode](/pessimistic-transaction.md)。但这不会影响你从 v3.0.7 或更早版本升级到 v3.0.8 或更高版本的现有集群。换句话说，**只有新创建的集群默认使用悲观事务模式**。 +> 从 v3.0.8 开始，TiDB 默认使用 [悲观事务模式](/pessimistic-transaction.md)。但如果你是从 v3.0.7 或更早版本升级到 v3.0.8 或更高版本，这一更改不会影响现有集群。换句话说，**只有新创建的集群默认使用悲观事务模式**。 ## 乐观事务的原理 -为了支持分布式事务，TiDB 在乐观事务中采用两阶段提交（2PC）。其流程如下： +为了支持分布式事务，TiDB 在乐观事务中采用了两阶段提交（2PC）。流程如下： ![2PC in TiDB](/media/2pc-in-tidb.png) 1. 客户端开始一个事务。 - TiDB 从 PD 获取一个时间戳（单调递增且全局唯一），作为当前事务的唯一事务ID，称为 `start_ts`。TiDB 实现了多版本并发控制（MVCC），因此 `start_ts` 也作为该事务所获得的数据库快照的版本。这意味着事务只能读取在 `start_ts` 时刻的数据库数据。 + TiDB 从 PD 获取一个时间戳（单调递增且全局唯一），作为当前事务的唯一事务 ID，称为 `start_ts`。TiDB 实现了多版本并发控制，因此 `start_ts` 也作为该事务获取的数据库快照的版本。这意味着该事务只能读取 `start_ts` 时刻数据库中的数据。 -2. 客户端发起读取请求。 +2. 客户端发起读请求。 1. TiDB 从 PD 获取路由信息（数据在 TiKV 节点间的分布情况）。 2. TiDB 从 TiKV 获取 `start_ts` 版本的数据。 -3. 客户端发起写入请求。 +3. 客户端发起写请求。 - TiDB 检查写入的数据是否满足约束（确保数据类型正确，满足 NOT NULL 约束）。**有效数据存储在 TiDB 事务的私有内存中**。 + TiDB 检查写入的数据是否满足约束条件（确保数据类型正确、满足 NOT NULL 约束）。**合法的数据会存储在 TiDB 中该事务的私有内存中**。 4. 客户端发起提交请求。 -5. TiDB 开始 2PC，并在存储中持久化数据，同时保证事务的原子性。 +5. TiDB 开始两阶段提交，并在保证事务原子性的同时将数据持久化到存储中。 1. TiDB 从待写入的数据中选择一个主键（Primary Key）。 - 2. TiDB 从 PD 获取 Region 分布信息，并将所有键按 Region 分组。 - 3. TiDB 向所有涉及的 TiKV 节点发送 prewrite 请求。然后，TiKV 检查是否存在冲突或过期版本。有效数据被锁定。 - 4. TiDB 收到所有 prewrite 阶段的响应，prewrite 成功。 - 5. TiDB 从 PD 获取提交版本号，并标记为 `commit_ts`。 - 6. TiDB 向主键所在的 TiKV 节点发起第二阶段提交。TiKV 检查数据，并清理 prewrite 阶段留下的锁。 - 7. TiDB 收到第二阶段成功完成的通知。 + 2. TiDB 从 PD 获取 Region 分布信息，并按 Region 对所有 key 进行分组。 + 3. TiDB 向所有涉及的 TiKV 节点发送 prewrite 请求。随后，TiKV 检查是否存在冲突或过期的版本。合法数据会被加锁。 + 4. TiDB 收到 prewrite 阶段的所有响应，prewrite 成功。 + 5. TiDB 从 PD 获取一个提交版本号，标记为 `commit_ts`。 + 6. TiDB 向主键所在的 TiKV 节点发起第二次提交。TiKV 检查数据，并清理 prewrite 阶段遗留的锁。 + 7. TiDB 收到第二阶段成功完成的消息。 6. TiDB 返回消息，通知客户端事务已成功提交。 -7. TiDB 异步清理该事务留下的锁。 +7. TiDB 异步清理本次事务遗留的锁。 ## 优缺点 @@ -58,31 +58,36 @@ summary: 了解 TiDB 中的乐观事务模型。 但 TiDB 事务也存在以下缺点： -* 由于 2PC 导致的事务延迟 -* 需要集中式的时间戳分配服务 -* 在大量数据写入内存时可能出现 OOM（内存溢出） +* 由于两阶段提交导致的事务延迟 +* 需要一个中心化的时间戳分配服务 +* 当内存中写入大量数据时，可能发生 OOM（内存溢出） ## 事务重试 -> **Note:** +> **注意：** > -> 从 v8.0.0 版本开始，系统变量 [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) 已被废弃，TiDB 不再支持乐观事务的自动重试。建议使用 [Pessimistic transaction mode](/pessimistic-transaction.md)。如果遇到乐观事务冲突，可以捕获错误并在应用层重试事务。 +> 从 v8.0.0 开始，[`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) 系统变量已废弃，TiDB 不再支持乐观事务的自动重试。建议使用 [悲观事务模式](/pessimistic-transaction.md)。如果你遇到乐观事务冲突，可以在应用层捕获错误并重试事务。 -在乐观事务模型中，由于写入冲突，事务可能无法提交，特别是在高争用场景下。TiDB 默认采用乐观并发控制，而 MySQL 则应用悲观并发控制。这意味着 MySQL 在执行写操作的 SQL 语句时会加锁，其 Repeatable Read 隔离级别允许当前读取，因此提交时通常不会遇到异常。为了降低应用适配难度，TiDB 提供了内部重试机制。 +在乐观事务模型下，在高并发争用场景中，事务可能因为写-写冲突而提交失败。从 v3.0.8 开始，TiDB 默认使用 [悲观事务模式](/pessimistic-transaction.md)，与 MySQL 一致。这意味着 TiDB 和 MySQL 在执行写类型 SQL 语句时会加锁，并且其可重复读隔离级别允许当前读，因此提交通常不会遇到异常。 ### 自动重试 -如果在事务提交过程中发生写写冲突，TiDB 会自动重试包含写操作的 SQL 语句。你可以通过设置 `tidb_disable_txn_auto_retry` 为 `OFF` 来启用自动重试，并通过配置 `tidb_retry_limit` 来设置重试次数限制： +> **注意：** +> +> - 从 TiDB v3.0.0 开始，事务的自动重试默认关闭，因为它可能**破坏事务隔离级别**。 +> - 从 TiDB v8.0.0 开始，不再支持乐观事务的自动重试。 + +如果在事务提交时发生写-写冲突，TiDB 会自动重试包含写操作的 SQL 语句。你可以通过将 `tidb_disable_txn_auto_retry` 设置为 `OFF` 来开启自动重试，并通过配置 `tidb_retry_limit` 设置重试次数上限： ```toml -# Whether to disable automatic retry. ("on" by default) +# 是否禁用自动重试。（默认 "on"） tidb_disable_txn_auto_retry = OFF -# Set the maximum number of the retries. ("10" by default) -# When "tidb_retry_limit = 0", automatic retry is completely disabled. +# 设置最大重试次数。（默认 "10"） +# 当 "tidb_retry_limit = 0" 时，完全禁用自动重试。 tidb_retry_limit = 10 ``` -你可以在会话级别或全局级别启用自动重试： +你可以在会话级别或全局级别开启自动重试： 1. 会话级别： @@ -108,37 +113,37 @@ tidb_retry_limit = 10 SET GLOBAL tidb_retry_limit = 10; ``` -> **Note:** +> **注意：** > -> `tidb_retry_limit` 变量决定最大重试次数。当设置为 `0` 时，所有事务（包括自动提交的隐式单语句事务）都不会自动重试。这是完全禁用 TiDB 自动重试机制的方式。禁用后，所有冲突事务会以最快速度向应用层报告失败（包括 `try again later` 消息）。 +> `tidb_retry_limit` 变量决定了最大重试次数。当该变量设置为 `0` 时，所有事务都不会自动重试，包括自动提交的隐式单语句事务。这是完全禁用 TiDB 自动重试机制的方式。自动重试被禁用后，所有冲突事务会以最快的方式向应用层报告失败（包括 `try again later` 消息）。 ### 重试的限制 -默认情况下，TiDB 不会重试事务，以避免出现丢失更新和破坏 [`REPEATABLE READ` isolation](/transaction-isolation-levels.md)。 +默认情况下，TiDB 不会重试事务，因为这可能导致更新丢失并破坏 [`REPEATABLE READ` 隔离级别](/transaction-isolation-levels.md)。 -重试流程如下： +原因可以从重试流程中看出： -1. 分配一个新时间戳，标记为 `start_ts`。 +1. 分配一个新的时间戳，标记为 `start_ts`。 2. 重试包含写操作的 SQL 语句。 -3. 实现两阶段提交。 +3. 执行两阶段提交。 -在第 2 步中，TiDB 只会重试包含写操作的 SQL 语句。然而，在重试过程中，TiDB 会获取一个新的版本号，标记事务的开始。这意味着 TiDB 会用新的 `start_ts` 版本中的数据重试 SQL 语句。如果事务使用其他查询结果更新数据，可能会导致结果不一致，因为违反了 `REPEATABLE READ` 隔离级别。 +在第 2 步，TiDB 只会重试包含写操作的 SQL 语句。然而，在重试过程中，TiDB 会收到一个新的版本号作为事务的起始点。这意味着 TiDB 会在新的 `start_ts` 版本下重试 SQL 语句。在这种情况下，如果事务是基于其他查询结果进行数据更新，结果可能会不一致，因为违反了 `REPEATABLE READ` 隔离级别。 -如果你的应用可以容忍丢失更新，并且不需要 `REPEATABLE READ` 一致性，可以通过设置 `tidb_disable_txn_auto_retry = OFF` 来启用此功能。 +如果你的应用可以容忍更新丢失，并且不需要 `REPEATABLE READ` 隔离级别的一致性，可以通过设置 `tidb_disable_txn_auto_retry = OFF` 启用该特性。 ## 冲突检测 -作为一个分布式数据库，TiDB 在 TiKV 层进行内存中的冲突检测，主要在 prewrite 阶段。TiDB 实例是无状态的，彼此不知情，这意味着它们无法知道其写入是否在集群中引发冲突。因此，冲突检测在 TiKV 层进行。 +作为分布式数据库，TiDB 在 TiKV 层进行内存冲突检测，主要发生在 prewrite 阶段。TiDB 实例是无状态的，彼此之间也不了解对方的存在，这意味着它们无法知道自己的写入是否会在整个集群中产生冲突。因此，冲突检测是在 TiKV 层完成的。 -配置如下： +相关配置如下： ```toml -# Controls the number of slots. ("2048000" by default） +# 控制槽的数量。（默认 "2048000"） scheduler-concurrency = 2048000 ``` -此外，TiKV 还支持监控调度器中等待锁的时间。 +此外，TiKV 支持监控调度器中等待 latch 的耗时。 ![Scheduler latch wait duration](/media/optimistic-transaction-metric.png) -当 `Scheduler latch wait duration` 较高且没有慢写时，可以安全地判断此时存在大量写冲突。 \ No newline at end of file +当 `Scheduler latch wait duration` 较高且没有慢写入时，可以安全地判断此时存在大量写入冲突。 \ No newline at end of file diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index ff6f6f35d40c4..438ee191e6cb9 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -8,17 +8,17 @@ summary: 了解优化器修复控制功能，以及如何使用 `tidb_opt_fix_co 随着产品的迭代演进，TiDB 优化器的行为也在不断变化，从而生成更合理的执行计划。但在某些特定场景下，新的行为可能会导致意外的结果。例如： - 某些行为的效果依赖于特定场景，对大多数场景带来提升的变更，可能会对其他场景造成回退。 -- 有时，行为细节的变化与其后果之间的关系非常复杂，对某一行为的改进可能会导致整体回退。 +- 有时，行为细节的变更与其后果之间的关系非常复杂，对某一行为的改进可能会导致整体回退。 -因此，TiDB 提供了优化器修复控制功能，允许你通过为一组修复项设置值，对 TiDB 优化器的行为进行细粒度控制。本文档介绍了优化器修复控制功能及其使用方法，并列出了 TiDB 当前支持的所有优化器修复控制项。 +因此，TiDB 提供了优化器修复控制功能，允许你通过为一组修复项设置值，对 TiDB 优化器的行为进行细粒度的控制。本文档介绍了优化器修复控制功能及其使用方法，并列出了 TiDB 当前支持的所有优化器修复控制项。 ## `tidb_opt_fix_control` 简介 -自 v6.5.3 和 v7.1.0 起，TiDB 提供了 [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) 系统变量，用于以更细粒度的方式控制优化器的行为。 +自 v6.5.3 和 v7.1.0 起，TiDB 提供了 [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) 系统变量，以更细粒度地控制优化器的行为。 每个修复项都是用于调整 TiDB 优化器某一特定行为的控制项。它以一个数字表示，该数字对应一个包含行为变更技术细节的 GitHub Issue。例如，对于修复项 `44262`，你可以在 [Issue 44262](https://github.com/pingcap/tidb/issues/44262) 中查看其控制内容。 -[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) 系统变量可以同时接受多个修复项，使用逗号（`,`）分隔。格式为 `"<#issue1>:,<#issue2>:,...,<#issueN>:"`，其中 `<#issueN>` 为修复项编号。例如： +[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) 系统变量可以接受多个修复项作为一个值，使用逗号（`,`）分隔。格式为 `"<#issue1>:,<#issue2>:,...,<#issueN>:"`，其中 `<#issueN>` 是修复项编号。例如： ```sql SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; @@ -36,7 +36,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - 默认值：`OFF` - 可选值：`ON`、`OFF` -- 该变量控制当 [全局统计信息](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode) 缺失时，是否允许使用 [动态裁剪模式](/partitioned-table.md#dynamic-pruning-mode) 访问分区表。 +- 该变量控制当 [分区表](/partitioned-table.md) 缺少 [全局统计信息](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode) 时，是否允许使用 [动态裁剪模式](/partitioned-table.md#dynamic-pruning-mode) 访问分区表。 ### [`44389`](https://github.com/pingcap/tidb/issues/44389) v6.5.3 和 v7.2.0 新增 @@ -61,15 +61,15 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - 默认值：`OFF` - 可选值：`ON`、`OFF` - 在某些场景下，当 `IndexJoin` 算子的 `Probe` 端包含 `Selection` 算子时，TiDB 会严重高估 `IndexScan` 的行数。这可能导致选择了次优的查询计划而不是 `IndexJoin`。 -- 为缓解该问题，TiDB 引入了相关改进。但由于存在查询计划回退的风险，该改进默认关闭。 +- 为缓解该问题，TiDB 引入了一个改进。但由于存在查询计划回退的风险，该改进默认关闭。 - 该变量用于控制是否启用上述改进。 ### [`45132`](https://github.com/pingcap/tidb/issues/45132) v7.4.0 新增 - 默认值：`1000` - 可选值：`[0, 2147483647]` -- 该变量用于设置优化器启发式选择访问路径的阈值。如果某个访问路径（如 `Index_A`）的估算行数远小于其他访问路径（默认 `1000` 倍），优化器会跳过成本比较，直接选择 `Index_A`。 -- `0` 表示关闭该启发式策略。 +- 该变量设置优化器启发式选择访问路径的阈值。如果某个访问路径（如 `Index_A`）的估算行数远小于其他访问路径（默认 `1000` 倍），优化器会跳过成本比较，直接选择 `Index_A`。 +- `0` 表示禁用该启发式策略。 ### [`45798`](https://github.com/pingcap/tidb/issues/45798) v7.5.0 新增 @@ -87,7 +87,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - 默认值：`ON` - 可选值：`ON`、`OFF` -- 由于难以准确估算查询计划中每一步的合格行数，优化器可能会低估 `estRows` 的值。该变量用于控制是否限制 `estRows` 的最小值。 +- 由于在查询计划中准确估算每一步合格行数存在挑战，优化器可能会低估 `estRows` 的值。该变量控制是否限制 `estRows` 的最小值。 - `ON`：将 `estRows` 的最小值限制为 1，这是 v8.4.0 引入的新行为，并与 Oracle、Db2 等其他数据库保持一致。 - `OFF`：不限制最小行数估算，行为与 v8.4.0 之前版本一致，此时 `estRows` 可能为 0。 @@ -95,31 +95,31 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - 默认值：`OFF` - 可选值：`ON`、`OFF` -- 该变量控制是否禁用查询执行中的 `Point Get` 和 `Batch Point Get` 算子。默认值 `OFF` 表示允许使用 `Point Get` 和 `Batch Point Get` 执行查询。如果设置为 `ON`，优化器会禁用 `Point Get` 和 `Batch Point Get`，强制选择 Coprocessor 执行查询。 -- `Point Get` 和 `Batch Point Get` 不支持列裁剪（即无法只返回部分列），因此在某些场景下，其执行效率可能低于 Coprocessor，将该变量设置为 `ON` 可以提升查询性能。推荐在以下场景下设置为 `ON`： +- 该变量控制是否禁用查询执行中的 `Point Get` 和 `Batch Point Get` 算子。默认值 `OFF` 表示允许使用 `Point Get` 和 `Batch Point Get` 进行查询执行。如果设置为 `ON`，优化器会禁用 `Point Get` 和 `Batch Point Get`，强制选择 Coprocessor 进行查询执行。 +- `Point Get` 和 `Batch Point Get` 不支持列裁剪（即无法只返回部分列），因此在某些场景下，其执行效率可能低于 Coprocessor，将该变量设置为 `ON` 可以提升查询性能。以下场景推荐将该变量设置为 `ON`： - - 宽表，包含大量列，但只查询少量列。 + - 宽表，列数较多，但只查询少量列。 - 表中包含大体积 JSON 字段，但查询时不涉及该 JSON 字段，或只查询 JSON 字段的一小部分。 ### [`52869`](https://github.com/pingcap/tidb/issues/52869) v8.1.0 新增 - 默认值：`OFF` - 可选值：`ON`、`OFF` -- 如 [Explain Statements Using Index Merge](/explain-index-merge.md#examples) 的 **Note** 所述，如果优化器能够为查询计划选择单一索引扫描方式（非全表扫描），则不会自动使用索引合并。 -- 你可以通过启用该修复控制项移除此限制。移除该限制后，优化器可以在更多查询中自动选择索引合并，但也可能导致优化器忽略最优的执行计划。因此，建议在实际用例上充分测试，确保不会引发性能回退后再移除该限制。 +- 如 [Explain Statements Using Index Merge](/explain-index-merge.md#examples) **Note** 所述，如果优化器能够为查询计划选择单一索引扫描方式（非全表扫描），则不会自动使用索引合并。 +- 你可以通过开启该修复控制项移除此限制。移除该限制后，优化器可以在更多查询中自动选择索引合并，但也可能导致优化器忽略最优执行计划。因此，建议在实际使用场景中充分测试，确保不会引发性能回退后再移除该限制。 ### [`54337`](https://github.com/pingcap/tidb/issues/54337) v8.3.0 新增 - 默认值：`OFF` - 可选值：`ON`、`OFF` - 目前，TiDB 优化器在推导每个合取项均为区间列表的复杂合取条件的索引范围时存在一定限制。通过应用通用区间交集可以解决该问题。 -- 你可以通过启用该修复控制项移除此限制，使优化器能够处理复杂的区间交集。但对于合取项数量较多（超过 10 个）的条件，优化时间可能会略有增加。 +- 你可以通过开启该修复控制项移除此限制，使优化器能够处理复杂的区间交集。但对于合取项数量较多（超过 10 个）的条件，优化时间可能会略有增加。 ### [`56318`](https://github.com/pingcap/tidb/issues/56318) > **Note:** > -> 仅适用于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless)。 +> 仅适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)。 - 默认值：`ON` - 可选值：`ON`、`OFF` diff --git a/placement-rules-in-sql.md b/placement-rules-in-sql.md index 111e847e5b2e2..7eba96c49d23d 100644 --- a/placement-rules-in-sql.md +++ b/placement-rules-in-sql.md @@ -1,42 +1,42 @@ --- -title: SQL 中的放置规则 +title: Placement Rules in SQL summary: 了解如何使用 SQL 语句调度表和分区的数据放置。 --- -# SQL 中的放置规则 +# Placement Rules in SQL -SQL 中的放置规则是一项功能，允许你通过 SQL 语句指定数据在 TiKV 集群中的存储位置。通过该功能，你可以将集群、数据库、表或分区的数据调度到特定的区域、数据中心、机架或主机。 +Placement Rules in SQL 是一项功能，允许你通过 SQL 语句指定数据在 TiKV 集群中的存储位置。通过该功能，你可以将集群、数据库、表或分区的数据调度到特定的区域、数据中心、机架或主机上。 该功能可以满足以下使用场景： - 跨多个数据中心部署数据，并配置规则以优化高可用性策略。 - 合并来自不同应用的多个数据库，并物理隔离不同用户的数据，满足实例内不同用户的数据隔离需求。 -- 为重要数据增加副本数量，提高应用可用性和数据可靠性。 +- 为重要数据增加副本数，提高应用可用性和数据可靠性。 > **Note:** > -> 该功能不适用于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 +> 该功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 ## 概述 -通过 SQL 中的放置规则功能，你可以[创建放置策略](#创建和绑定放置策略)，并为不同层级的数据配置所需的放置策略，粒度从粗到细如下： +通过 Placement Rules in SQL 功能，你可以[创建放置策略](#create-and-attach-placement-policies)，并为不同层级的数据配置所需的放置策略，粒度从粗到细如下： -| 层级 | 描述 | +| Level | Description | |------------------|--------------------------------------------------------------------------------------| -| 集群 | 默认情况下，TiDB 为集群配置 3 副本的策略。你可以为集群配置全局放置策略。更多信息，参见 [为集群全局指定副本数](#为集群全局指定副本数)。 | -| 数据库 | 你可以为特定数据库配置放置策略。更多信息，参见 [为数据库指定默认放置策略](#为数据库指定默认放置策略)。 | -| 表 | 你可以为特定表配置放置策略。更多信息，参见 [为表指定放置策略](#为表指定放置策略)。 | -| 分区 | 你可以为表中的不同行创建分区，并分别为分区配置放置策略。更多信息，参见 [为分区表指定放置策略](#为分区表指定放置策略)。 | +| Cluster | 默认情况下，TiDB 为集群配置 3 个副本的策略。你可以为集群配置全局放置策略。更多信息，参见 [为集群全局指定副本数](#specify-the-number-of-replicas-globally-for-a-cluster)。 | +| Database | 你可以为特定数据库配置放置策略。更多信息，参见 [为数据库指定默认放置策略](#specify-a-default-placement-policy-for-a-database)。 | +| Table | 你可以为特定表配置放置策略。更多信息，参见 [为表指定放置策略](#specify-a-placement-policy-for-a-table)。 | +| Partition | 你可以为表中的不同行创建分区，并分别为分区配置放置策略。更多信息，参见 [为分区表指定放置策略](#specify-a-placement-policy-for-a-partitioned-table)。 | > **Tip:** > -> *SQL 中的放置规则* 的实现依赖于 PD 的 *placement rules feature*。详情可参考 [配置放置规则](https://docs.pingcap.com/tidb/stable/configure-placement-rules)。在 SQL 中的放置规则语境下，*placement rules* 可能指的是附加到其他对象的 *placement policies*，也可能指的是 TiDB 发送到 PD 的规则。 +> *Placement Rules in SQL* 的实现依赖于 PD 的 *placement rules feature*。详情可参考 [配置 Placement Rules](https://docs.pingcap.com/tidb/stable/configure-placement-rules)。在 Placement Rules in SQL 的上下文中，*placement rules* 可能指附加到其他对象的 *placement policies*，也可能指 TiDB 发送到 PD 的规则。 ## 限制 -- 为简化运维，建议每个集群内的放置策略数量控制在 10 个及以下。 -- 建议附加放置策略的表和分区总数控制在 10,000 个及以下。为过多的表和分区附加策略会增加 PD 的计算负载，进而影响服务性能。 -- 建议按照本文档提供的示例使用 SQL 中的放置规则功能，避免使用其他复杂的放置策略。 +- 为简化运维，建议集群内的放置策略数量限制在 10 个以内。 +- 建议附加放置策略的表和分区总数限制在 10,000 个以内。为过多的表和分区附加策略会增加 PD 的计算负载，进而影响服务性能。 +- 建议按照本文档提供的示例使用 Placement Rules in SQL 功能，不建议使用其他复杂的放置策略。 ## 前提条件 @@ -44,7 +44,7 @@ SQL 中的放置规则是一项功能，允许你通过 SQL 语句指定数据 -当你创建放置策略时，TiDB 不会检查策略中指定的 label 是否存在，而是在你绑定策略时进行检查。因此，在绑定放置策略前，请确保每个 TiKV 节点都已正确配置 label。TiDB 自建集群的配置方法如下： +当你创建放置策略时，TiDB 不会检查策略中指定的 label 是否存在，而是在附加策略时进行检查。因此，在附加放置策略前，请确保每个 TiKV 节点都已配置正确的 label。TiDB 自建集群的配置方法如下： ``` tikv-server --labels region=,zone=,host= @@ -54,7 +54,7 @@ tikv-server --labels region=,zone=,host= | 部署方式 | 示例 | | --- | --- | -| 手动部署 | [通过拓扑 label 调度副本](/schedule-replicas-by-topology-labels.md) | +| 手动部署 | [通过拓扑标签调度副本](/schedule-replicas-by-topology-labels.md) | | 使用 TiUP 部署 | [跨地域部署拓扑](/geo-distributed-deployment-topology.md) | | 使用 TiDB Operator 部署 | [在 Kubernetes 中配置 TiDB 集群](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#high-availability-of-data) | @@ -86,9 +86,9 @@ SHOW PLACEMENT LABELS; ## 使用方法 -本节介绍如何通过 SQL 语句创建、绑定、查看、修改和删除放置策略。 +本节介绍如何通过 SQL 语句创建、附加、查看、修改和删除放置策略。 -### 创建和绑定放置策略 +### 创建并附加放置策略 1. 要创建放置策略，使用 [`CREATE PLACEMENT POLICY`](/sql-statements/sql-statement-create-placement-policy.md) 语句： @@ -101,9 +101,9 @@ SHOW PLACEMENT LABELS; - `PRIMARY_REGION="us-east-1"` 选项表示将 Raft Leader 放置在 `region` label 为 `us-east-1` 的节点上。 - `REGIONS="us-east-1,us-west-1"` 选项表示将 Raft Follower 放置在 `region` label 为 `us-east-1` 和 `us-west-1` 的节点上。 - 更多可配置的放置选项及其含义，参见 [放置选项参考](#放置选项参考)。 + 更多可配置的放置选项及其含义，参见 [放置选项参考](#placement-option-reference)。 -2. 要将放置策略绑定到表或分区表，使用 `CREATE TABLE` 或 `ALTER TABLE` 语句为该表或分区表指定放置策略： +2. 要将放置策略附加到表或分区表，使用 `CREATE TABLE` 或 `ALTER TABLE` 语句为该表或分区表指定放置策略： ```sql CREATE TABLE t1 (a INT) PLACEMENT POLICY=myplacementpolicy; @@ -111,7 +111,7 @@ SHOW PLACEMENT LABELS; ALTER TABLE t2 PLACEMENT POLICY=myplacementpolicy; ``` - `PLACEMENT POLICY` 不属于任何数据库 schema，可以在全局范围内绑定。因此，使用 `CREATE TABLE` 指定放置策略不需要额外的权限。 + `PLACEMENT POLICY` 不属于任何数据库 schema，可以在全局范围内附加。因此，使用 `CREATE TABLE` 指定放置策略不需要额外的权限。 ### 查看放置策略 @@ -125,7 +125,7 @@ SHOW PLACEMENT LABELS; 1 row in set (0.00 sec) ``` -- 要查看某个表绑定的放置策略，可以使用 [`SHOW CREATE TABLE`](/sql-statements/sql-statement-show-create-table.md) 语句： +- 要查看某个表附加的放置策略，可以使用 [`SHOW CREATE TABLE`](/sql-statements/sql-statement-show-create-table.md) 语句： ```sql SHOW CREATE TABLE t1\G @@ -157,19 +157,19 @@ SHOW PLACEMENT LABELS; 1 row in set ``` -- 要查看集群中所有已绑定放置策略的表，可以查询 `information_schema.tables` 系统表的 `tidb_placement_policy_name` 列： +- 要查看集群中所有已附加放置策略的表，可以查询 `information_schema.tables` 系统表的 `tidb_placement_policy_name` 列： ```sql SELECT * FROM information_schema.tables WHERE tidb_placement_policy_name IS NOT NULL; ``` -- 要查看集群中所有已绑定放置策略的分区，可以查询 `information_schema.partitions` 系统表的 `tidb_placement_policy_name` 列： +- 要查看集群中所有已附加放置策略的分区，可以查询 `information_schema.partitions` 系统表的 `tidb_placement_policy_name` 列： ```sql SELECT * FROM information_schema.partitions WHERE tidb_placement_policy_name IS NOT NULL; ``` -- 所有对象上绑定的放置策略都是*异步*生效的。要检查放置策略的调度进度，可以使用 [`SHOW PLACEMENT`](/sql-statements/sql-statement-show-placement.md) 语句： +- 附加到所有对象的放置策略都是*异步*生效的。要检查放置策略的调度进度，可以使用 [`SHOW PLACEMENT`](/sql-statements/sql-statement-show-placement.md) 语句： ```sql SHOW PLACEMENT; @@ -177,17 +177,17 @@ SHOW PLACEMENT LABELS; ### 修改放置策略 -要修改放置策略，可以使用 [`ALTER PLACEMENT POLICY`](/sql-statements/sql-statement-alter-placement-policy.md) 语句。该修改会应用到所有绑定了该策略的对象上。 +要修改放置策略，可以使用 [`ALTER PLACEMENT POLICY`](/sql-statements/sql-statement-alter-placement-policy.md) 语句。该修改会应用到所有已附加该策略的对象上。 ```sql ALTER PLACEMENT POLICY myplacementpolicy FOLLOWERS=4; ``` -在该语句中，`FOLLOWERS=4` 选项表示为数据配置 5 个副本（4 个 Follower 和 1 个 Leader）。更多可配置的放置选项及其含义，参见 [放置选项参考](#放置选项参考)。 +在该语句中，`FOLLOWERS=4` 选项表示为数据配置 5 个副本，包括 4 个 Follower 和 1 个 Leader。更多可配置的放置选项及其含义，参见 [放置选项参考](#placement-option-reference)。 ### 删除放置策略 -要删除未绑定到任何表或分区的策略，可以使用 [`DROP PLACEMENT POLICY`](/sql-statements/sql-statement-drop-placement-policy.md) 语句： +要删除未附加到任何表或分区的策略，可以使用 [`DROP PLACEMENT POLICY`](/sql-statements/sql-statement-drop-placement-policy.md) 语句： ```sql DROP PLACEMENT POLICY myplacementpolicy; @@ -205,25 +205,25 @@ DROP PLACEMENT POLICY myplacementpolicy; 常规放置选项可以满足数据放置的基本需求。 -| 选项名 | 描述 | +| 选项名称 | 描述 | |----------------------------|------------------------------------------------------------------------------------------------| -| `PRIMARY_REGION` | 指定将 Raft Leader 放置在 `region` label 与该选项值匹配的节点上。 | -| `REGIONS` | 指定将 Raft Follower 放置在 `region` label 与该选项值匹配的节点上。 | +| `PRIMARY_REGION` | 指定将 Raft Leader 放置在 `region` label 匹配该值的节点上。 | +| `REGIONS` | 指定将 Raft Follower 放置在 `region` label 匹配该值的节点上。 | | `SCHEDULE` | 指定 Follower 放置的调度策略。可选值为 `EVEN`（默认）或 `MAJORITY_IN_PRIMARY`。 | | `FOLLOWERS` | 指定 Follower 的数量。例如，`FOLLOWERS=2` 表示数据有 3 个副本（2 个 Follower 和 1 个 Leader）。 | ### 高级放置选项 -高级配置选项为数据放置提供了更高的灵活性，以满足复杂场景的需求。但配置高级选项比常规选项更复杂，需要你对集群拓扑和 TiDB 数据分片有深入了解。 +高级配置选项为数据放置提供了更大的灵活性，以满足复杂场景的需求。但配置高级选项比常规选项更复杂，需要你对集群拓扑和 TiDB 数据分片有深入了解。 -| 选项名 | 描述 | +| 选项名称 | 描述 | | --------------| ------------ | | `CONSTRAINTS` | 适用于所有角色的约束列表。例如，`CONSTRAINTS="[+disk=ssd]"`。 | | `LEADER_CONSTRAINTS` | 仅适用于 Leader 的约束列表。 | | `FOLLOWER_CONSTRAINTS` | 仅适用于 Follower 的约束列表。 | | `LEARNER_CONSTRAINTS` | 仅适用于 learner 的约束列表。 | | `LEARNERS` | learner 的数量。 | -| `SURVIVAL_PREFERENCE` | 按 label 容灾级别指定副本放置优先级。例如，`SURVIVAL_PREFERENCE="[region, zone, host]"`。 | +| `SURVIVAL_PREFERENCE` | 按 label 的容灾级别指定副本放置优先级。例如，`SURVIVAL_PREFERENCE="[region, zone, host]"`。 | ### CONSTRAINTS 格式 @@ -232,25 +232,25 @@ DROP PLACEMENT POLICY myplacementpolicy; | CONSTRAINTS 格式 | 描述 | |----------------------------|-----------------------------------------------------------------------------------------------------------| | 列表格式 | 如果要指定的约束适用于所有副本，可以使用键值列表格式。每个键以 `+` 或 `-` 开头。例如：
  • `[+region=us-east-1]` 表示将数据放置在 `region` label 为 `us-east-1` 的节点上。
  • `[+region=us-east-1,-type=fault]` 表示将数据放置在 `region` label 为 `us-east-1` 且 `type` label 不为 `fault` 的节点上。

| -| 字典格式 | 如果需要为不同约束指定不同数量的副本，可以使用字典格式。例如：
  • `FOLLOWER_CONSTRAINTS="{+region=us-east-1: 1,+region=us-east-2: 1,+region=us-west-1: 1}";` 表示在 `us-east-1`、`us-east-2` 和 `us-west-1` 各放置一个 Follower。
  • `FOLLOWER_CONSTRAINTS='{"+region=us-east-1,+type=scale-node": 1,"+region=us-west-1": 1}';` 表示在 `us-east-1` 且 `type` label 为 `scale-node` 的节点上放置一个 Follower，在 `us-west-1` 放置一个 Follower。
字典格式支持每个键以 `+` 或 `-` 开头，并允许配置特殊的 `#evict-leader` 属性。例如，`FOLLOWER_CONSTRAINTS='{"+region=us-east-1":1, "+region=us-east-2": 2, "+region=us-west-1,#evict-leader": 1}'` 表示在灾难恢复期间，尽量将 `us-west-1` 选出的 Leader 驱逐。| +| 字典格式 | 如果需要为不同约束指定不同数量的副本，可以使用字典格式。例如：
  • `FOLLOWER_CONSTRAINTS="{+region=us-east-1: 1,+region=us-east-2: 1,+region=us-west-1: 1}";` 表示在 `us-east-1`、`us-east-2` 和 `us-west-1` 各放置一个 Follower。
  • `FOLLOWER_CONSTRAINTS='{"+region=us-east-1,+type=scale-node": 1,"+region=us-west-1": 1}';` 表示在 `us-east-1` 且 `type` label 为 `scale-node` 的节点上放置一个 Follower，在 `us-west-1` 放置一个 Follower。
字典格式支持每个键以 `+` 或 `-` 开头，并允许你配置特殊的 `#evict-leader` 属性。例如，`FOLLOWER_CONSTRAINTS='{"+region=us-east-1":1, "+region=us-east-2": 2, "+region=us-west-1,#evict-leader": 1}'` 表示在灾难恢复期间，尽量将 `us-west-1` 选出的 Leader 驱逐。| > **Note:** > > - `LEADER_CONSTRAINTS` 放置选项仅支持列表格式。 -> - 列表和字典格式均基于 YAML 解析器，但在某些情况下 YAML 语法可能被错误解析。例如，`"{+region=east:1,+region=west:2}"`（冒号后无空格）可能被错误解析为 `'{"+region=east:1": null, "+region=west:2": null}'`，这不是预期结果。而 `"{+region=east: 1,+region=west: 2}"`（冒号后有空格）则可被正确解析为 `'{"+region=east": 1, "+region=west": 2}'`。因此，建议在冒号后添加空格。 +> - 列表和字典格式均基于 YAML 解析器，但在某些情况下 YAML 语法可能被错误解析。例如，`"{+region=east:1,+region=west:2}"`（冒号后无空格）可能被错误解析为 `'{"+region=east:1": null, "+region=west:2": null}'`，这不是预期结果。而 `"{+region=east: 1,+region=west: 2}"`（冒号后有空格）可以被正确解析为 `'{"+region=east": 1, "+region=west": 2}'`。因此，建议在冒号后添加空格。 ## 基本示例 ### 为集群全局指定副本数 -集群初始化后，默认副本数为 `3`。如果集群需要更多副本，可以通过配置放置策略增加副本数，并使用 [`ALTER RANGE`](/sql-statements/sql-statement-alter-range.md) 在集群级别应用该策略。例如： +集群初始化后，默认副本数为 `3`。如果集群需要更多副本，可以通过配置放置策略增加副本数，然后使用 [`ALTER RANGE`](/sql-statements/sql-statement-alter-range.md) 在集群级别应用该策略。例如： ```sql CREATE PLACEMENT POLICY five_replicas FOLLOWERS=4; ALTER RANGE global PLACEMENT POLICY five_replicas; ``` -注意，由于 TiDB 默认 Leader 数为 `1`，`five replicas` 表示 4 个 Follower 和 1 个 Leader。 +注意，由于 TiDB 默认 Leader 数为 `1`，`five replicas` 表示 `4` 个 Follower 和 `1` 个 Leader。 ### 为数据库指定默认放置策略 @@ -263,22 +263,22 @@ CREATE PLACEMENT POLICY p2 FOLLOWERS=4; CREATE PLACEMENT POLICY p3 FOLLOWERS=2; -CREATE TABLE t1 (a INT); -- 创建表 t1，未指定放置策略。 +CREATE TABLE t1 (a INT); -- 创建表 t1，未指定任何放置策略。 -ALTER DATABASE test PLACEMENT POLICY=p2; -- 修改数据库默认放置策略为 p2，不影响已存在的表 t1。 +ALTER DATABASE test PLACEMENT POLICY=p2; -- 修改数据库的默认放置策略为 p2，不影响已存在的表 t1。 CREATE TABLE t2 (a INT); -- 创建表 t2，默认放置策略 p2 应用于 t2。 CREATE TABLE t3 (a INT) PLACEMENT POLICY=p1; -- 创建表 t3。由于该语句已指定其他放置规则，默认放置策略 p2 不会应用于 t3。 -ALTER DATABASE test PLACEMENT POLICY=p3; -- 再次修改数据库默认策略，不影响已存在的表。 +ALTER DATABASE test PLACEMENT POLICY=p3; -- 再次修改数据库的默认策略，不影响已存在的表。 CREATE TABLE t4 (a INT); -- 创建表 t4，默认放置策略 p3 应用于 t4。 -ALTER PLACEMENT POLICY p3 FOLLOWERS=3; -- `FOLLOWERS=3` 应用于绑定了策略 p3 的表（即 t4）。 +ALTER PLACEMENT POLICY p3 FOLLOWERS=3; -- `FOLLOWERS=3` 应用于附加了策略 p3 的表（即表 t4）。 ``` -注意，表到分区的策略继承与上述示例中的策略继承不同。当你更改表的默认策略时，新策略也会应用于该表的分区。但表只有在创建时未指定任何策略时才会继承数据库的策略。一旦表继承了数据库的策略，后续修改数据库的默认策略不会影响该表。 +注意，表到分区的策略继承与上述示例中的策略继承不同。当你更改表的默认策略时，新策略也会应用于该表中的分区。但表只有在创建时未指定任何策略时才会继承数据库的策略。一旦表继承了数据库的策略，修改数据库的默认策略不会影响该表。 ### 为表指定放置策略 @@ -287,9 +287,9 @@ ALTER PLACEMENT POLICY p3 FOLLOWERS=3; -- `FOLLOWERS=3` 应用于绑定了策略 ```sql CREATE PLACEMENT POLICY five_replicas FOLLOWERS=4; -CREATE TABLE t (a INT) PLACEMENT POLICY=five_replicas; -- 创建表 t 并绑定 five_replicas 放置策略。 +CREATE TABLE t (a INT) PLACEMENT POLICY=five_replicas; -- 创建表 t 并附加 'five_replicas' 放置策略。 -ALTER TABLE t PLACEMENT POLICY=default; -- 移除表 t 的 five_replicas 放置策略，重置为默认策略。 +ALTER TABLE t PLACEMENT POLICY=default; -- 从表 t 移除 'five_replicas' 放置策略，重置为默认放置策略。 ``` ### 为分区表指定放置策略 @@ -320,7 +320,7 @@ PARTITION BY RANGE( YEAR(purchased) ) ( - 全局索引 `idx` 会应用与表 `t1` 相同的 `companystandardpolicy` 放置策略。 - 如果表 `t1` 未指定放置策略，则 `p1`、`p2`、`p3` 分区和全局索引 `idx` 会继承数据库默认策略或全局默认策略。 -在这些分区绑定放置策略后，你可以像下面这样为特定分区更改放置策略： +为这些分区附加放置策略后，你可以像下面这样为特定分区更改放置策略： ```sql ALTER TABLE t1 PARTITION p1 PLACEMENT POLICY=storageforhistorydata; @@ -328,7 +328,7 @@ ALTER TABLE t1 PARTITION p1 PLACEMENT POLICY=storageforhistorydata; ## 高可用性示例 -假设有如下拓扑的集群，TiKV 节点分布在 3 个 region，每个 region 有 3 个可用区： +假设有如下拓扑的集群，TiKV 节点分布在 3 个 region，每个 region 包含 3 个可用区： ```sql SELECT store_id,address,label from INFORMATION_SCHEMA.TIKV_STORE_STATUS; @@ -350,25 +350,25 @@ SELECT store_id,address,label from INFORMATION_SCHEMA.TIKV_STORE_STATUS; ### 指定生存优先级 -如果你对数据的具体分布没有特殊要求，而更关注容灾需求，可以使用 `SURVIVAL_PREFERENCES` 选项指定数据生存优先级。 +如果你对数据的具体分布没有特殊要求，而更关注满足容灾需求，可以使用 `SURVIVAL_PREFERENCES` 选项指定数据生存优先级。 -如上例，TiDB 集群分布在 3 个 region，每个 region 有 3 个 zone。为该集群创建放置策略时，假设你配置 `SURVIVAL_PREFERENCES` 如下： +如上例，TiDB 集群分布在 3 个 region，每个 region 包含 3 个 zone。为该集群创建放置策略时，假设你配置 `SURVIVAL_PREFERENCES` 如下： ``` sql CREATE PLACEMENT POLICY multiaz SURVIVAL_PREFERENCES="[region, zone, host]"; CREATE PLACEMENT POLICY singleaz CONSTRAINTS="[+region=us-east-1]" SURVIVAL_PREFERENCES="[zone]"; ``` -创建放置策略后，可以根据需要将其绑定到相应的表： +创建放置策略后，可以根据需要将其附加到相应的表上： -- 绑定了 `multiaz` 放置策略的表，数据会以 3 副本分布在不同 region，优先满足跨 region 的数据隔离生存目标，其次是跨 zone，最后是跨 host。 -- 绑定了 `singleaz` 放置策略的表，数据会优先以 3 副本分布在 `us-east-1` region，并满足跨 zone 的数据隔离生存目标。 +- 附加了 `multiaz` 放置策略的表，数据会以 3 个副本分布在不同 region，优先满足跨 region 的数据隔离生存目标，其次是跨 zone，最后是跨 host。 +- 附加了 `singleaz` 放置策略的表，数据会优先以 3 个副本分布在 `us-east-1` region，然后满足跨 zone 的数据隔离生存目标。 > **Note:** > -> `SURVIVAL_PREFERENCES` 等价于 PD 的 `location-labels`。更多信息，参见 [通过拓扑 label 调度副本](/schedule-replicas-by-topology-labels.md)。 +> `SURVIVAL_PREFERENCES` 等价于 PD 的 `location-labels`。更多信息，参见 [通过拓扑标签调度副本](/schedule-replicas-by-topology-labels.md)。 @@ -376,13 +376,13 @@ CREATE PLACEMENT POLICY singleaz CONSTRAINTS="[+region=us-east-1]" SURVIVAL_PREF > **Note:** > -> `SURVIVAL_PREFERENCES` 等价于 PD 的 `location-labels`。更多信息，参见 [通过拓扑 label 调度副本](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels)。 +> `SURVIVAL_PREFERENCES` 等价于 PD 的 `location-labels`。更多信息，参见 [通过拓扑标签调度副本](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels)。 ### 指定 5 副本按 2:2:1 分布在多个数据中心 -如果你需要特定的数据分布，比如 5 副本按 2:2:1 分布，可以通过配置 [字典格式](#constraints-格式) 的 `CONSTRAINTS`，为不同约束指定不同数量的副本： +如果你需要特定的数据分布，比如 5 副本按 2:2:1 的比例分布，可以通过配置 [字典格式](#constraints-格式) 的 `CONSTRAINTS`，为不同约束指定不同数量的副本： ```sql CREATE PLACEMENT POLICY `deploy221` CONSTRAINTS='{"+region=us-east-1":2, "+region=us-east-2": 2, "+region=us-west-1": 1}'; @@ -412,9 +412,9 @@ SHOW PLACEMENT; CREATE PLACEMENT POLICY deploy221_primary_east1 LEADER_CONSTRAINTS="[+region=us-east-1]" FOLLOWER_CONSTRAINTS='{"+region=us-east-1": 1, "+region=us-east-2": 2, "+region=us-west-1": 1}'; ``` -创建并绑定该放置策略后，数据的 Raft Leader 副本会放置在 `LEADER_CONSTRAINTS` 选项指定的 `us-east-1` region，其他副本会放置在 `FOLLOWER_CONSTRAINTS` 指定的 region。注意，如果集群发生故障（如 `us-east-1` region 节点宕机），新 Leader 仍会从其他 region 选举产生，即使这些 region 是在 `FOLLOWER_CONSTRAINTS` 中指定的。也就是说，保证服务可用性优先级最高。 +创建并附加该放置策略后，数据的 Raft Leader 副本会放置在 `LEADER_CONSTRAINTS` 选项指定的 `us-east-1` region，其他副本会放置在 `FOLLOWER_CONSTRAINTS` 选项指定的 region。注意，如果集群发生故障，比如 `us-east-1` region 节点宕机，新的 Leader 仍会从其他 region 选举产生，即使这些 region 是在 `FOLLOWER_CONSTRAINTS` 中指定的。换句话说，保证服务可用性优先级最高。 -如果你不希望在 `us-east-1` region 故障时将新 Leader 放在 `us-west-1`，可以配置特殊的 `evict-leader` 属性，将该 region 选出的 Leader 驱逐： +如果在 `us-east-1` region 故障时，不希望在 `us-west-1` 选举新的 Leader，可以配置特殊的 `evict-leader` 属性，将该 region 选出的 Leader 驱逐： ```sql CREATE PLACEMENT POLICY deploy221_primary_east1 LEADER_CONSTRAINTS="[+region=us-east-1]" FOLLOWER_CONSTRAINTS='{"+region=us-east-1": 1, "+region=us-east-2": 2, "+region=us-west-1,#evict-leader": 1}'; @@ -431,12 +431,12 @@ CREATE TABLE t1 (a INT) PLACEMENT POLICY=eastandwest; - `PRIMARY_REGION` 指定 Leader 的分布 region。该选项只能指定一个 region。 - `SCHEDULE` 选项指定 TiDB 如何平衡 Follower 的分布。 - - 默认的 `EVEN` 调度规则保证 Follower 在所有 region 均衡分布。 - - 如果你希望确保足够数量的 Follower 副本放在 `PRIMARY_REGION`（即 `us-east-1`），可以使用 `MAJORITY_IN_PRIMARY` 调度规则。该规则以牺牲部分可用性为代价，提供更低延迟的事务。如果主 region 故障，`MAJORITY_IN_PRIMARY` 不会自动切换。 + - 默认的 `EVEN` 调度规则保证 Follower 在所有 region 间均衡分布。 + - 如果希望保证足够数量的 Follower 副本放置在 `PRIMARY_REGION`（即 `us-east-1`），可以使用 `MAJORITY_IN_PRIMARY` 调度规则。该调度规则以牺牲部分可用性为代价，提供更低延迟的事务。如果主 region 故障，`MAJORITY_IN_PRIMARY` 不会自动切换。 ## 数据隔离示例 -如下面的示例，在创建放置策略时，可以为每个策略配置一个约束，要求数据放置在带有指定 `app` label 的 TiKV 节点上。 +如下例所示，在创建放置策略时，可以为每个策略配置一个约束，要求数据放置在带有指定 `app` label 的 TiKV 节点上。 ```sql CREATE PLACEMENT POLICY app_order CONSTRAINTS="[+app=order]"; @@ -456,8 +456,8 @@ PLACEMENT POLICY=app_list ## 与其他功能的兼容性 - 临时表不支持放置策略。 -- 放置策略只保证静态数据存储在正确的 TiKV 节点上，不保证数据在传输过程中（无论是用户查询还是内部操作）只发生在特定 region。 -- 如果要为数据配置 TiFlash 副本，需要[创建 TiFlash 副本](/tiflash/create-tiflash-replicas.md)，而不是使用放置策略。 +- 放置策略只保证静态数据存储在正确的 TiKV 节点上，但不保证数据在传输过程中（无论是用户查询还是内部操作）只发生在特定 region。 +- 若要为数据配置 TiFlash 副本，需要[创建 TiFlash 副本](/tiflash/create-tiflash-replicas.md)，而不是使用放置策略。 - 允许为 `PRIMARY_REGION` 和 `REGIONS` 设置语法糖规则。未来计划增加 `PRIMARY_RACK`、`PRIMARY_ZONE` 和 `PRIMARY_HOST` 等变体。参见 [issue #18030](https://github.com/pingcap/tidb/issues/18030)。 ## 与工具的兼容性 @@ -466,7 +466,7 @@ PLACEMENT POLICY=app_list | 工具名称 | 最低支持版本 | 说明 | | --- | --- | --- | -| 备份与恢复（BR） | 6.0 | v6.0 之前，BR 不支持备份和恢复放置策略。更多信息，参见 [为什么恢复放置规则到集群时会报错](/faq/backup-and-restore-faq.md#why-does-an-error-occur-when-i-restore-placement-rules-to-a-cluster)。 | +| 备份恢复（BR） | 6.0 | v6.0 之前，BR 不支持备份和恢复放置策略。更多信息，参见 [为什么恢复放置规则到集群时报错](/faq/backup-and-restore-faq.md#why-does-an-error-occur-when-i-restore-placement-rules-to-a-cluster)。 | | TiDB Lightning | 暂不兼容 | TiDB Lightning 导入包含放置策略的备份数据时会报错 | | TiCDC | 6.0 | 忽略放置策略，不会将策略同步到下游 | diff --git a/schema-cache.md b/schema-cache.md index d2bcbcd0fd0ea..8d515effef066 100644 --- a/schema-cache.md +++ b/schema-cache.md @@ -5,21 +5,21 @@ summary: TiDB 采用基于 LRU（最近最少使用）机制的 schema 信息缓 # Schema Cache -在一些多租户场景下，可能会有数十万甚至上百万个数据库和数据表。如果将所有这些数据库和数据表的 schema 信息全部加载到内存中，不仅会消耗大量内存，还会降低访问性能。为了解决这个问题，TiDB 引入了类似 LRU（最近最少使用）的 schema 缓存机制。只有最近访问的数据库和数据表的 schema 信息会被缓存在内存中。 +在一些多租户场景下，可能会有数十万甚至上百万个数据库和数据表。如果将所有这些数据库和数据表的 schema 信息全部加载到内存中，不仅会消耗大量内存，还会导致访问性能下降。为了解决这个问题，TiDB 引入了类似 LRU（最近最少使用）机制的 schema 缓存。只有最近访问过的数据库和数据表的 schema 信息会被缓存在内存中。 > **Note:** > -> 目前，该特性在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 目前，该特性不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 ## 配置 schema 缓存 -你可以通过配置系统变量 [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) 来启用 schema 缓存功能。 +你可以通过配置系统变量 [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) 来启用 schema 缓存特性。 ## 最佳实践 -- 在拥有大量数据库和数据表（例如超过 10 万个数据库和数据表）的场景，或者数据库和数据表数量足够大以影响系统性能时，建议开启 schema 缓存功能。 -- 你可以通过 TiDB Dashboard 的 **Schema load** 部分下的 **Infoschema v2 Cache Operation** 子面板，监控 schema 缓存的命中率。如果命中率较低，可以适当增大 [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) 的值。 -- 你可以通过 TiDB Dashboard 的 **Schema load** 部分下的 **Infoschema v2 Cache Size** 子面板，监控当前正在使用的 schema 缓存大小。 +- 在拥有大量数据库和数据表（例如超过 10 万个数据库和数据表）的场景，或者数据库和数据表数量足够大以影响系统性能时，建议开启 schema 缓存特性。 +- 你可以通过 TiDB Dashboard 的 **Schema load** 部分下的子面板 **Infoschema v2 Cache Operation** 监控 schema 缓存的命中率。如果命中率较低，可以适当增大 [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) 的值。 +- 你可以通过 TiDB Dashboard 的 **Schema load** 部分下的子面板 **Infoschema v2 Cache Size** 监控当前正在使用的 schema 缓存大小。 @@ -42,7 +42,7 @@ summary: TiDB 采用基于 LRU（最近最少使用）机制的 schema 信息缓 - 单个集群中的数据表数量不能超过 300 万。 - 如果单个集群中的数据表数量超过 30 万，不要将 [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) 的值设置为 `0`，否则可能导致 TiDB 内存溢出（OOM）。 - 使用外键可能会增加集群中 DDL 操作的执行时间。 -- 当数据表被不规律地访问时，例如在 time1 访问一批表，在 time2 访问另一批表，并且 `tidb_schema_cache_size` 的值较小，schema 信息可能会频繁被驱逐和重新缓存，导致性能波动。该特性更适用于频繁访问的数据库和数据表相对固定的场景。 +- 当数据表被不规律地访问时，例如在 time1 访问一组表，在 time2 访问另一组表，并且 `tidb_schema_cache_size` 的值较小时，schema 信息可能会频繁被驱逐和重新缓存，导致性能波动。该特性更适用于频繁访问的数据库和数据表相对固定的场景。 - 统计信息可能无法及时收集。 - 某些元数据信息的访问可能会变慢。 - 切换 schema 缓存的开关需要等待一段时间。 @@ -52,7 +52,7 @@ summary: TiDB 采用基于 LRU（最近最少使用）机制的 schema 信息缓 - `FLASHBACK` - `ALTER TABLE ... SET TIFLASH MODE ...` -- 当你使用带有 [`AUTO_INCREMENT`](/auto-increment.md) 或 [`AUTO_RANDOM`](/auto-random.md) 属性的数据表时，较小的 schema 缓存大小可能导致这些表的元数据频繁进出缓存，从而导致分配的 ID 区间在未完全使用前失效，出现 ID 跳号。在写入压力较大的场景下，甚至可能导致 ID 区间被耗尽。为尽量减少异常的 ID 分配行为并提升系统稳定性，建议采取以下措施： +- 当你使用带有 [`AUTO_INCREMENT`](/auto-increment.md) 或 [`AUTO_RANDOM`](/auto-random.md) 属性的数据表时，较小的 schema 缓存大小可能导致这些表的元数据频繁进出缓存。这可能导致分配的 ID 区间在未被完全使用前就失效，从而出现 ID 跳号。在写入压力较大的场景下，甚至可能导致 ID 区间被耗尽。为尽量减少异常的 ID 分配行为并提升系统稳定性，建议采取以下措施： - 在监控面板查看 schema 缓存的命中率和大小，评估缓存设置是否合理。适当增大 schema 缓存大小，减少频繁驱逐。 - 将 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache) 设置为 `1`，以防止 ID 跳号。 diff --git a/sql-statements/sql-statement-admin-alter-ddl.md b/sql-statements/sql-statement-admin-alter-ddl.md index e85e0df3089f1..7a47a6209b6b0 100644 --- a/sql-statements/sql-statement-admin-alter-ddl.md +++ b/sql-statements/sql-statement-admin-alter-ddl.md @@ -1,13 +1,13 @@ --- title: ADMIN ALTER DDL JOBS -summary: 关于 TiDB 数据库中 `ADMIN ALTER DDL JOBS` 用法的概述。 +summary: 关于在 TiDB 数据库中使用 `ADMIN ALTER DDL JOBS` 的概述。 --- # ADMIN ALTER DDL JOBS > **Note:** > -> 目前，该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群上不可用。 +> 目前，该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群上不可用。 `ADMIN ALTER DDL JOBS` 语句允许你修改单个正在运行的 DDL 任务的参数。例如： @@ -29,7 +29,7 @@ ADMIN ALTER DDL JOBS 101 THREAD = 8; - `BATCH_SIZE`：批处理大小。初始值由 [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) 设置。 - `MAX_WRITE_SPEED`：向每个 TiKV 导入索引记录的最大带宽限制。初始值由 [`tidb_ddl_reorg_max_write_speed`](/system-variables.md#tidb_ddl_reorg_max_write_speed-new-in-v6512-v755-and-v850) 设置。 - 目前，上述参数仅对在禁用 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 后提交并运行的 `ADD INDEX` 任务生效。 + 目前，上述参数仅对在关闭 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 后提交并运行的 `ADD INDEX` 任务生效。 - `MODIFY COLUMN`： - `THREAD`：DDL 任务的并发度。初始值由 `tidb_ddl_reorg_worker_cnt` 设置。 @@ -84,7 +84,7 @@ AlterJobOption ::= 该语句是 TiDB 对 MySQL 语法的扩展。 -## 另请参阅 +## 参考 * [`ADMIN SHOW DDL [JOBS|QUERIES]`](/sql-statements/sql-statement-admin-show-ddl.md) * [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md) diff --git a/sql-statements/sql-statement-admin.md b/sql-statements/sql-statement-admin.md index 37227324daca1..be5ae71ceba66 100644 --- a/sql-statements/sql-statement-admin.md +++ b/sql-statements/sql-statement-admin.md @@ -23,8 +23,8 @@ summary: TiDB 数据库中 ADMIN 的用法概述。 | [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md) | 取消当前正在运行的 DDL 任务。 | | [`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md) | 暂停当前正在运行的 DDL 任务。 | | [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md) | 恢复已暂停的 DDL 任务。 | -| [`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) | 计算表的所有行和索引的 CRC64。 | -| [ADMIN CHECK [TABLE\|INDEX]](/sql-statements/sql-statement-admin-check-table-index.md) | 检查表或索引的一致性。 | +| [`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) | 计算表所有行及索引的 CRC64。 | +| [ADMIN CHECK [TABLE\|INDEX]](/sql-statements/sql-statement-admin-check-table-index.md) | 检查表或索引的一致性。 | | [ADMIN SHOW DDL [JOBS\|QUERIES]](/sql-statements/sql-statement-admin-show-ddl.md) | 显示当前正在运行或最近完成的 DDL 任务的详细信息。 | @@ -34,8 +34,8 @@ summary: TiDB 数据库中 ADMIN 的用法概述。 | 语句 | 描述 | |------------------------------------------------------------------------------------------|----------------------------| | [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md) | 取消当前正在运行的 DDL 任务。 | -| [`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) | 计算表的所有行和索引的 CRC64。 | -| [ADMIN CHECK [TABLE\|INDEX]](/sql-statements/sql-statement-admin-check-table-index.md) | 检查表或索引的一致性。 | +| [`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) | 计算表所有行及索引的 CRC64。 | +| [ADMIN CHECK [TABLE\|INDEX]](/sql-statements/sql-statement-admin-check-table-index.md) | 检查表或索引的一致性。 | | [ADMIN SHOW DDL [JOBS\|QUERIES]](/sql-statements/sql-statement-admin-show-ddl.md) | 显示当前正在运行或最近完成的 DDL 任务的详细信息。 | @@ -58,7 +58,7 @@ ADMIN RELOAD opt_rule_blacklist; > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 ```sql ADMIN PLUGINS ENABLE plugin_name [, plugin_name] ...; @@ -78,25 +78,25 @@ ADMIN PLUGINS DISABLE plugin_name [, plugin_name] ...; ADMIN FLUSH BINDINGS; ``` -上述语句用于持久化 SQL 执行计划绑定信息。 +上述语句用于持久化 SQL Plan 绑定信息。 ```sql ADMIN CAPTURE BINDINGS; ``` -上述语句可以从出现多次的 `SELECT` 语句中生成 SQL 执行计划绑定。 +上述语句可以从出现多次的 `SELECT` 语句中生成 SQL Plan 绑定。 ```sql ADMIN EVOLVE BINDINGS; ``` -开启自动绑定功能后，每隔 `bind-info-leave`（默认值为 `3s`）会触发一次 SQL 执行计划绑定信息的进化。上述语句用于主动触发该进化过程。 +开启自动绑定功能后，每隔 `bind-info-leave`（默认值为 `3s`）会触发一次 SQL Plan 绑定信息的进化。上述语句用于主动触发该进化过程。 ```sql ADMIN RELOAD BINDINGS; ``` -上述语句用于重新加载 SQL 执行计划绑定信息。 +上述语句用于重新加载 SQL Plan 绑定信息。 ## `ADMIN REPAIR` 语句 @@ -104,11 +104,11 @@ ADMIN RELOAD BINDINGS; > **Note:** > -> 该 TiDB 语句不适用于 TiDB Cloud。 +> 此 TiDB 语句不适用于 TiDB Cloud。 -在极端情况下需要以不可信的方式覆盖存储表的元数据时，可以使用 `ADMIN REPAIR TABLE`： +在极端情况下，如果需要以不可信的方式覆盖存储表的元数据，可以使用 `ADMIN REPAIR TABLE`： ```sql ADMIN REPAIR TABLE tbl_name CREATE TABLE STATEMENT; @@ -116,7 +116,7 @@ ADMIN REPAIR TABLE tbl_name CREATE TABLE STATEMENT; -这里的“不可信”是指你需要手动确保原表的元数据可以被 `CREATE TABLE STATEMENT` 操作覆盖。要使用该 `REPAIR` 语句，需要开启 [`repair-mode`](/tidb-configuration-file.md#repair-mode) 配置项，并确保待修复的表已列在 [`repair-table-list`](/tidb-configuration-file.md#repair-table-list) 中。 +这里的“不可信”指的是你需要手动确保原表的元数据可以被 `CREATE TABLE STATEMENT` 操作覆盖。要使用该 `REPAIR` 语句，需要开启 [`repair-mode`](/tidb-configuration-file.md#repair-mode) 配置项，并确保待修复的表已列在 [`repair-table-list`](/tidb-configuration-file.md#repair-table-list) 中。 @@ -132,7 +132,7 @@ ADMIN SHOW t NEXT_ROW_ID; > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 ```sql ADMIN SHOW SLOW RECENT N; @@ -144,7 +144,7 @@ ADMIN SHOW SLOW TOP [INTERNAL | ALL] N; -详细信息可参考 [`ADMIN SHOW SLOW` 命令](/identify-slow-queries.md#admin-show-slow-command)。 +详细内容可参考 [`ADMIN SHOW SLOW` 命令](/identify-slow-queries.md#admin-show-slow-command)。 @@ -289,7 +289,7 @@ ADMIN SHOW DDL JOBS 5 WHERE state != 'synced' AND db_name = 'test'; * `START_TIME`：DDL 操作的开始时间。 * `END_TIME`：DDL 操作的结束时间。 * `STATE`：DDL 操作的状态。常见状态包括： - * `none`：表示操作任务已进入 DDL 任务队列但尚未执行，正在等待前序任务完成。也可能在执行 drop 操作后变为 `none`，但很快会更新为 `synced`，表示所有 TiDB 实例已同步到该状态。 + * `none`：表示操作任务已进入 DDL 任务队列但尚未执行，正在等待前序任务完成。也可能是执行 drop 操作后变为 `none`，但很快会更新为 `synced`，表示所有 TiDB 实例已同步到该状态。 * `running`：表示操作正在执行中。 * `synced`：表示操作已成功执行，且所有 TiDB 实例已同步到该状态。 * `rollback done`：表示操作失败且已完成回滚。 diff --git a/sql-statements/sql-statement-alter-instance.md b/sql-statements/sql-statement-alter-instance.md index a2a9b8bbc0af9..3927e8d7e4653 100644 --- a/sql-statements/sql-statement-alter-instance.md +++ b/sql-statements/sql-statement-alter-instance.md @@ -9,25 +9,25 @@ summary: 了解 TiDB 中 `ALTER INSTANCE` 的用法概述。 > **Note:** > -> [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 可以自动刷新 TLS 证书，因此该功能不适用于 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 +> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 可以自动刷新 TLS 证书，因此该功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 ## RELOAD TLS -你可以执行 `ALTER INSTANCE RELOAD TLS` 语句，从原有的配置路径重新加载证书（[`ssl-cert`](/tidb-configuration-file.md#ssl-cert)）、密钥（[`ssl-key`](/tidb-configuration-file.md#ssl-key)）和 CA（[`ssl-ca`](/tidb-configuration-file.md#ssl-ca)）。 +你可以执行 `ALTER INSTANCE RELOAD TLS` 语句，从原始配置路径重新加载证书（[`ssl-cert`](/tidb-configuration-file.md#ssl-cert)）、密钥（[`ssl-key`](/tidb-configuration-file.md#ssl-key)）和 CA（[`ssl-ca`](/tidb-configuration-file.md#ssl-ca)）。 -你可以执行 `ALTER INSTANCE RELOAD TLS` 语句，从原有的配置路径重新加载证书（[`ssl-cert`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#ssl-cert)）、密钥（[`ssl-key`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#ssl-key)）和 CA（[`ssl-ca`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#ssl-ca)）。 +你可以执行 `ALTER INSTANCE RELOAD TLS` 语句，从原始配置路径重新加载证书（[`ssl-cert`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#ssl-cert)）、密钥（[`ssl-key`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#ssl-key)）和 CA（[`ssl-ca`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#ssl-ca)）。 -新加载的证书、密钥和 CA 会在该语句成功执行后建立的新连接中生效。在此语句执行前已建立的连接不受影响。 +新加载的证书、密钥和 CA 会在该语句成功执行后建立的新连接上生效。在此语句执行前已建立的连接不受影响。 -当在重新加载过程中发生错误时，默认会返回该错误信息，并继续使用之前的密钥和证书。但是，如果你添加了可选的 `NO ROLLBACK ON ERROR`，当重新加载过程中发生错误时，将不会返回错误，后续的请求将以禁用 TLS 安全连接的方式处理。 +当在重新加载过程中发生错误时，默认会返回该错误信息，并继续使用之前的密钥和证书。但是，如果你添加了可选的 `NO ROLLBACK ON ERROR`，当重新加载过程中发生错误时，将不会返回错误，后续请求将以禁用 TLS 安全连接的方式处理。 ## 语法图 @@ -49,7 +49,7 @@ ALTER INSTANCE RELOAD TLS; ## MySQL 兼容性 -`ALTER INSTANCE RELOAD TLS` 语句仅支持从原有的配置路径重新加载。不支持动态修改加载路径，也不支持在 TiDB 启动时动态启用 TLS 加密连接功能。该功能在重启 TiDB 时默认处于禁用状态。 +`ALTER INSTANCE RELOAD TLS` 语句仅支持从原始配置路径重新加载。不支持动态修改加载路径，也不支持在 TiDB 启动时动态启用 TLS 加密连接功能。该功能在重启 TiDB 时默认处于禁用状态。 ## 另请参阅 diff --git a/sql-statements/sql-statement-alter-placement-policy.md b/sql-statements/sql-statement-alter-placement-policy.md index 5e6cee3b48bb9..72f13b8ea2dd7 100644 --- a/sql-statements/sql-statement-alter-placement-policy.md +++ b/sql-statements/sql-statement-alter-placement-policy.md @@ -1,17 +1,17 @@ --- title: ALTER PLACEMENT POLICY -summary: TiDB 中 ALTER PLACEMENT POLICY 的用法。 +summary: ALTER PLACEMENT POLICY 在 TiDB 中的用法。 --- # ALTER PLACEMENT POLICY -`ALTER PLACEMENT POLICY` 用于修改之前已创建的现有放置策略。所有使用该放置策略的表和分区都会自动更新。 +`ALTER PLACEMENT POLICY` 用于修改之前已创建的现有放置策略。所有使用该放置策略的表和分区会自动更新。 > **Note:** > -> 该功能在 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 -`ALTER PLACEMENT POLICY` 会用新的定义 _替换_ 之前的策略，而不是将新旧策略 _合并_。在以下示例中，执行 `ALTER PLACEMENT POLICY` 后，`FOLLOWERS=4` 会被丢弃： +`ALTER PLACEMENT POLICY` 会用新的定义 _替换_ 之前的策略，而不是 _合并_ 旧策略和新策略。在下面的例子中，执行 `ALTER PLACEMENT POLICY` 后，`FOLLOWERS=4` 会丢失： ```sql CREATE PLACEMENT POLICY p1 FOLLOWERS=4; diff --git a/sql-statements/sql-statement-alter-range.md b/sql-statements/sql-statement-alter-range.md index f56484bb0073e..f2df662796384 100644 --- a/sql-statements/sql-statement-alter-range.md +++ b/sql-statements/sql-statement-alter-range.md @@ -5,11 +5,11 @@ summary: TiDB 中 ALTER RANGE 的用法概述。 # ALTER RANGE -目前，`ALTER RANGE` 语句只能用于修改 TiDB 中特定放置策略（placement policy）的范围。 +目前，`ALTER RANGE` 语句只能用于修改 TiDB 中特定放置策略的范围。 -> **注意：** +> **Note:** > -> 此功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 此功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 diff --git a/sql-statements/sql-statement-alter-resource-group.md b/sql-statements/sql-statement-alter-resource-group.md index 6a3f8f03fc979..7b49934bf9fea 100644 --- a/sql-statements/sql-statement-alter-resource-group.md +++ b/sql-statements/sql-statement-alter-resource-group.md @@ -9,7 +9,7 @@ summary: 了解在 TiDB 中 ALTER RESOURCE GROUP 的用法。 > **Note:** > -> 此功能在 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -78,15 +78,15 @@ DirectBackgroundOption ::= | "UTILIZATION_LIMIT" EqOpt LengthNum ``` -TiDB 支持以下 `DirectResourceGroupOption`，其中 [请求单元（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru) 是 TiDB 中对 CPU、IO 及其他系统资源的统一抽象单位。 +TiDB 支持以下 `DirectResourceGroupOption`，其中 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru) 是 TiDB 中对 CPU、IO 及其他系统资源的统一抽象单位。 -| 选项 | 描述 | 示例 | -|----------------|--------------------------------------------------------------|--------------------------------------------------------------------------------------------------------| -| `RU_PER_SEC` | 每秒回填的 RU 速率 | `RU_PER_SEC = 500` 表示该资源组每秒回填 500 个 RU | -| `PRIORITY` | 在 TiKV 上待处理任务的绝对优先级 | `PRIORITY = HIGH` 表示优先级为高。如果未指定，默认值为 `MEDIUM`。 | -| `BURSTABLE` | 如果设置了 `BURSTABLE` 属性，TiDB 允许对应资源组在超出配额时使用可用的系统资源。 | -| `QUERY_LIMIT` | 当查询执行满足该条件时，查询会被识别为异常查询并执行相应操作。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当查询执行时间超过 60 秒时，该查询会被识别为异常查询并被终止。所有 SQL 文本相同的 SQL 语句将在接下来的 10 分钟内被立即终止。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 表示未启用异常查询控制。详见 [异常查询](/tidb-resource-control-runaway-queries.md)。 | -| `BACKGROUND` | 配置后台任务。更多详情参见 [管理后台任务](/tidb-resource-control-background-tasks.md)。 | `BACKGROUND=(TASK_TYPES="br,stats", UTILIZATION_LIMIT=30)` 表示备份恢复和统计信息收集相关任务被调度为后台任务，且后台任务最多可消耗 TiKV 资源的 30%。 | +| 选项 | 描述 | 示例 | +|---------------|----------------------------------------------|---------------------| +| `RU_PER_SEC` | 每秒回填的 RU 速率 | `RU_PER_SEC = 500` 表示该资源组每秒回填 500 个 RU | +| `PRIORITY` | 在 TiKV 上处理任务的绝对优先级 | `PRIORITY = HIGH` 表示优先级为高。如果未指定，默认值为 `MEDIUM`。| +| `BURSTABLE` | 如果设置了 `BURSTABLE` 属性，TiDB 允许对应资源组在超出配额时使用可用的系统资源。| +| `QUERY_LIMIT` | 当查询执行满足该条件时，查询会被识别为异常查询并执行相应操作。| `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当查询执行时间超过 60 秒时被识别为异常查询，并被终止。所有 SQL 文本相同的 SQL 语句将在接下来的 10 分钟内被立即终止。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 表示未启用异常查询控制。详见 [异常查询](/tidb-resource-control-runaway-queries.md)。| +| `BACKGROUND` | 配置后台任务。更多详情参见 [管理后台任务](/tidb-resource-control-background-tasks.md)。| `BACKGROUND=(TASK_TYPES="br,stats", UTILIZATION_LIMIT=30)` 表示备份恢复和统计信息收集相关任务被调度为后台任务，且后台任务最多可消耗 TiKV 资源的 30%。| > **Note:** > @@ -184,4 +184,4 @@ MySQL 也支持 [ALTER RESOURCE GROUP](https://dev.mysql.com/doc/refman/8.0/en/a * [DROP RESOURCE GROUP](/sql-statements/sql-statement-drop-resource-group.md) * [CREATE RESOURCE GROUP](/sql-statements/sql-statement-create-resource-group.md) -* [请求单元（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru) +* [Request Unit (RU)](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru) diff --git a/sql-statements/sql-statement-backup.md b/sql-statements/sql-statement-backup.md index d81959f4ca4bc..03ae6437b29db 100644 --- a/sql-statements/sql-statement-backup.md +++ b/sql-statements/sql-statement-backup.md @@ -10,15 +10,15 @@ summary: TiDB 数据库 BACKUP 语句用法概述。 > **Warning:** > > - 该功能为实验性特性。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下更改或移除。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 -> - 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> - 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 -`BACKUP` 语句使用与 [BR 工具](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview) 相同的引擎，不同之处在于备份过程由 TiDB 自身驱动，而不是独立的 BR 工具。BR 的所有优势和注意事项同样适用于该语句。 +`BACKUP` 语句使用与 [BR 工具](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview) 相同的引擎，不同之处在于备份过程由 TiDB 自身驱动，而不是单独的 BR 工具。BR 的所有优势和注意事项同样适用于该语句。 -执行 `BACKUP` 需要 `BACKUP_ADMIN` 或 `SUPER` 权限。此外，执行备份的 TiDB 节点以及集群中的所有 TiKV 节点都必须对目标路径具有读写权限。当启用 [增强安全模式](/system-variables.md#tidb_enable_enhanced_security) 时，不允许使用本地存储（以 `local://` 开头的存储路径）。 +执行 `BACKUP` 需要 `BACKUP_ADMIN` 或 `SUPER` 权限。此外，执行备份的 TiDB 节点以及集群中的所有 TiKV 节点都必须对目标存储具有读写权限。当启用 [安全增强模式](/system-variables.md#tidb_enable_enhanced_security) 时，不允许使用本地存储（以 `local://` 开头的存储路径）。 `BACKUP` 语句会被阻塞，直到整个备份任务完成、失败或被取消。建议为执行 `BACKUP` 准备一个长时间保持的连接。可以使用 [`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md) 语句取消该任务。 -同一时间只能执行一个 `BACKUP` 或 [`RESTORE`](/sql-statements/sql-statement-restore.md) 任务。如果同一 TiDB 服务器上已经有 `BACKUP` 或 `RESTORE` 语句在执行，新的 `BACKUP` 执行会等待所有前序任务完成。 +同一时间只能执行一个 `BACKUP` 和 [`RESTORE`](/sql-statements/sql-statement-restore.md) 任务。如果同一 TiDB 服务器上已经有 `BACKUP` 或 `RESTORE` 语句在执行，新的 `BACKUP` 执行会等待所有前序任务完成后再开始。 `BACKUP` 只能用于 "tikv" 存储引擎。若在 "unistore" 引擎下使用 `BACKUP` 会失败。 @@ -76,7 +76,7 @@ BACKUP DATABASE `test` TO 'local:///mnt/backup/2020/04/'; | :-------- | :--------- | | `Destination` | 目标 URL | | `Size` | 备份归档的总大小，单位为字节 | -| `BackupTS` | 创建备份时快照的 TSO（用于 [增量备份](#incremental-backup)） | +| `BackupTS` | 创建备份时快照的 TSO（适用于 [增量备份](#incremental-backup)） | | `Queue Time` | `BACKUP` 任务进入队列的时间戳（当前时区） | | `Execution Time` | `BACKUP` 任务开始执行的时间戳（当前时区） | @@ -119,15 +119,15 @@ BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-05/' 使用 `RATE_LIMIT` 可以限制每个 TiKV 节点的平均上传速度，以减少网络带宽占用。 -在备份完成前，`BACKUP` 默认会对集群中的数据进行校验（checksum），以验证数据正确性。单表校验任务的默认并发数为 4，可以通过 `CHECKSUM_CONCURRENCY` 参数进行调整。如果你确信无需数据校验，可以将 `CHECKSUM` 参数设置为 `FALSE` 以关闭校验。 +在备份完成前，`BACKUP` 默认会对集群上的数据进行校验（checksum），以验证数据正确性。单表校验任务的默认并发数为 4，可以通过 `CHECKSUM_CONCURRENCY` 参数进行调整。如果你确信无需数据校验，可以将 `CHECKSUM` 参数设置为 `FALSE` 以关闭校验。 如需指定 BR 备份表和索引时可执行的并发任务数，可使用 `CONCURRENCY` 参数。该参数控制 BR 内部的线程池大小，从而优化备份操作的性能和效率。 -一个任务代表一个表范围或一个索引范围，具体取决于备份的 schema。对于一个带有一个索引的表，备份该表会使用两个任务。`CONCURRENCY` 的默认值为 `4`。如果需要备份大量表或索引，可以适当增大该值。 +根据备份的 schema，一个任务代表一个表范围或一个索引范围。例如，一个带有一个索引的表会使用两个任务进行备份。`CONCURRENCY` 的默认值为 `4`。如果需要备份大量表或索引，可以适当增大该值。 统计信息默认不会被备份。如需备份统计信息，需要将 `IGNORE_STATS` 参数设置为 `FALSE`。 -备份生成的 SST 文件默认使用 `zstd` 压缩算法。如有需要，可以通过 `COMPRESSION_TYPE` 参数指定其他压缩算法。支持的算法包括 `lz4`、`zstd` 和 `snappy`。你还可以通过 `COMPRESSION_LEVEL` 参数调整压缩级别，级别数值越高，压缩比越高，但 CPU 消耗也越大。 +备份生成的 SST 文件默认使用 `zstd` 压缩算法。如果需要，可以通过 `COMPRESSION_TYPE` 参数指定其他压缩算法。支持的算法包括 `lz4`、`zstd` 和 `snappy`。你还可以通过 `COMPRESSION_LEVEL` 参数调整压缩级别，级别数值越高，压缩比越高，但 CPU 消耗也越大。 ```sql BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-06/' @@ -138,7 +138,7 @@ BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-06/' ### 快照 -可以通过指定时间戳、TSO 或相对时间来备份历史数据。 +可以指定时间戳、TSO 或相对时间来备份历史数据。 ```sql -- relative time diff --git a/sql-statements/sql-statement-create-placement-policy.md b/sql-statements/sql-statement-create-placement-policy.md index cd560128d1566..72e334dc7ea3a 100644 --- a/sql-statements/sql-statement-create-placement-policy.md +++ b/sql-statements/sql-statement-create-placement-policy.md @@ -5,11 +5,11 @@ summary: CREATE PLACEMENT POLICY 在 TiDB 中的用法。 # CREATE PLACEMENT POLICY -`CREATE PLACEMENT POLICY` 用于创建一个命名的放置策略（placement policy），之后可以将该策略分配给表、分区或数据库模式。 +`CREATE PLACEMENT POLICY` 用于创建一个命名的放置策略（placement policy），之后可以将其分配给表、分区或数据库模式。 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -51,9 +51,9 @@ AdvancedPlacementOption ::= > **Note:** > -> 若要了解你的集群中有哪些可用的 region，请参见 [`SHOW PLACEMENT LABELS`](/sql-statements/sql-statement-show-placement-labels.md)。 +> 要了解你的集群中有哪些可用的 region，请参见 [`SHOW PLACEMENT LABELS`](/sql-statements/sql-statement-show-placement-labels.md)。 > -> 如果你没有看到任何可用的 region，可能是你的 TiKV 安装未正确设置 label。 +> 如果你没有看到任何可用的 region，可能是你的 TiKV 安装没有正确设置 label。 ```sql CREATE PLACEMENT POLICY p1 PRIMARY_REGION="us-east-1" REGIONS="us-east-1,us-west-1" FOLLOWERS=4; @@ -78,7 +78,7 @@ Query OK, 0 rows affected (0.10 sec) 该语句是 TiDB 对 MySQL 语法的扩展。 -## 另请参阅 +## 参见 * [Placement Rules in SQL](/placement-rules-in-sql.md) * [SHOW PLACEMENT](/sql-statements/sql-statement-show-placement.md) diff --git a/sql-statements/sql-statement-create-resource-group.md b/sql-statements/sql-statement-create-resource-group.md index 06419dbefff01..a702f05806698 100644 --- a/sql-statements/sql-statement-create-resource-group.md +++ b/sql-statements/sql-statement-create-resource-group.md @@ -9,7 +9,7 @@ summary: 了解在 TiDB 中如何使用 CREATE RESOURCE GROUP。 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -77,18 +77,18 @@ ResourceGroupRunawayActionOption ::= TiDB 支持以下 `DirectResourceGroupOption`，其中 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru) 是 TiDB 中对 CPU、IO 及其他系统资源的统一抽象单位。 -| 选项 | 描述 | 示例 | -|----------------|----------------------------------------------|-------------------------------------------------------------------------------------------| -| `RU_PER_SEC` | 每秒回填的 RU 速率 | `RU_PER_SEC = 500` 表示该资源组每秒回填 500 个 RU | -| `PRIORITY` | 在 TiKV 上待处理任务的绝对优先级 | `PRIORITY = HIGH` 表示优先级为高。如果未指定，默认值为 `MEDIUM`。 | -| `BURSTABLE` | 如果设置了 `BURSTABLE` 属性，TiDB 允许对应资源组在超出配额时使用可用的系统资源。 | -| `QUERY_LIMIT` | 当查询执行满足该条件时，查询会被识别为异常查询并执行相应操作。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当查询执行时间超过 60 秒时，该查询会被识别为异常查询并被终止。所有 SQL 文本相同的 SQL 语句将在接下来的 10 分钟内被立即终止。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 表示未启用异常查询控制。详见 [异常查询](/tidb-resource-control-runaway-queries.md)。 | +| 选项 | 描述 | 示例 | +|--------------|----------------------------------------------|---------------------| +| `RU_PER_SEC` | 每秒回填的 RU 速率 | `RU_PER_SEC = 500` 表示该资源组每秒回填 500 个 RU | +| `PRIORITY` | 在 TiKV 上待处理任务的绝对优先级 | `PRIORITY = HIGH` 表示优先级为高。如果未指定，默认值为 `MEDIUM`。 | +| `BURSTABLE` | 如果设置了 `BURSTABLE` 属性，TiDB 允许对应的资源组在超出配额时使用可用的系统资源。 | +| `QUERY_LIMIT`| 当查询执行满足该条件时，查询会被识别为异常查询并执行相应操作。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当查询执行时间超过 60 秒时被识别为异常查询，并被终止。所有 SQL 文本相同的 SQL 语句将在接下来的 10 分钟内被立即终止。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 表示未启用异常查询控制。详见 [异常查询](/tidb-resource-control-runaway-queries.md)。 | > **Note:** > > - 只有当全局变量 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) 设置为 `ON` 时，才能执行 `CREATE RESOURCE GROUP` 语句。 -> TiDB 在集群初始化时会自动创建一个 `default` 资源组。对于该资源组，`RU_PER_SEC` 的默认值为 `UNLIMITED`（等同于 `INT` 类型的最大值，即 `2147483647`），并且处于 `BURSTABLE` 模式。所有未绑定到任何资源组的请求会自动绑定到该 `default` 资源组。当你为其他资源组创建新配置时，建议根据需要修改 `default` 资源组的配置。 -> - 目前，仅 `default` 资源组支持修改 `BACKGROUND` 配置。 +> TiDB 在集群初始化时会自动创建一个 `default` 资源组。对于该资源组，`RU_PER_SEC` 的默认值为 `UNLIMITED`（等同于 `INT` 类型的最大值，即 `2147483647`），并处于 `BURSTABLE` 模式。所有未绑定到任何资源组的请求会自动绑定到该 `default` 资源组。当你为其他资源组创建新配置时，建议根据需要修改 `default` 资源组的配置。 +> - 当前仅支持为 `default` 资源组修改 `BACKGROUND` 配置。 ## 示例 diff --git a/sql-statements/sql-statement-drop-placement-policy.md b/sql-statements/sql-statement-drop-placement-policy.md index d09c20bb4f51f..bc801172db025 100644 --- a/sql-statements/sql-statement-drop-placement-policy.md +++ b/sql-statements/sql-statement-drop-placement-policy.md @@ -1,6 +1,6 @@ --- title: DROP PLACEMENT POLICY -summary: 在 TiDB 中使用 ALTER PLACEMENT POLICY。 +summary: The usage of ALTER PLACEMENT POLICY in TiDB. --- # DROP PLACEMENT POLICY @@ -9,7 +9,7 @@ summary: 在 TiDB 中使用 ALTER PLACEMENT POLICY。 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -28,14 +28,14 @@ PolicyName ::= ```sql CREATE PLACEMENT POLICY p1 FOLLOWERS=4; CREATE TABLE t1 (a INT PRIMARY KEY) PLACEMENT POLICY=p1; -DROP PLACEMENT POLICY p1; -- 此语句会失败，因为放置策略 p1 仍被引用。 +DROP PLACEMENT POLICY p1; -- This statement fails because the placement policy p1 is referenced. --- 查询哪些表和分区引用了该放置策略。 +-- Finds which tables and partitions reference the placement policy. SELECT table_schema, table_name FROM information_schema.tables WHERE tidb_placement_policy_name='p1'; SELECT table_schema, table_name FROM information_schema.partitions WHERE tidb_placement_policy_name='p1'; -ALTER TABLE t1 PLACEMENT POLICY=default; -- 从 t1 表中移除放置策略。 -DROP PLACEMENT POLICY p1; -- 删除成功。 +ALTER TABLE t1 PLACEMENT POLICY=default; -- Removes the placement policy from t1. +DROP PLACEMENT POLICY p1; -- Succeeds. ``` ```sql @@ -63,9 +63,9 @@ Query OK, 0 rows affected (0.21 sec) 该语句是 TiDB 对 MySQL 语法的扩展。 -## 另请参阅 +## 参见 * [Placement Rules in SQL](/placement-rules-in-sql.md) * [SHOW PLACEMENT](/sql-statements/sql-statement-show-placement.md) * [CREATE PLACEMENT POLICY](/sql-statements/sql-statement-create-placement-policy.md) -* [ALTER PLACEMENT POLICY](/sql-statements/sql-statement-alter-placement-policy.md) +* [ALTER PLACEMENT POLICY](/sql-statements/sql-statement-alter-placement-policy.md) \ No newline at end of file diff --git a/sql-statements/sql-statement-drop-resource-group.md b/sql-statements/sql-statement-drop-resource-group.md index 282d39717ee08..1a922d44a1dcb 100644 --- a/sql-statements/sql-statement-drop-resource-group.md +++ b/sql-statements/sql-statement-drop-resource-group.md @@ -9,7 +9,7 @@ summary: 了解在 TiDB 中 DROP RESOURCE GROUP 的用法。 > **Note:** > -> 此功能在 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 diff --git a/sql-statements/sql-statement-flashback-cluster.md b/sql-statements/sql-statement-flashback-cluster.md index 4cb7789234899..29c71d263fa90 100644 --- a/sql-statements/sql-statement-flashback-cluster.md +++ b/sql-statements/sql-statement-flashback-cluster.md @@ -5,24 +5,24 @@ summary: 了解在 TiDB 数据库中使用 FLASHBACK CLUSTER 的方法。 # FLASHBACK CLUSTER -TiDB v6.4.0 引入了 `FLASHBACK CLUSTER TO TIMESTAMP` 语法。你可以使用该语法将集群恢复到某个特定的时间点。在指定时间戳时，你可以设置一个 datetime 值或使用时间函数。datetime 的格式如 '2016-10-08 16:45:26.999'，最小时间单位为毫秒。但在大多数情况下，指定以秒为单位的时间戳就足够了，例如 '2016-10-08 16:45:26'。 +TiDB v6.4.0 引入了 `FLASHBACK CLUSTER TO TIMESTAMP` 语法。你可以使用该语法将集群恢复到某个特定的时间点。在指定时间戳时，你可以设置一个 datetime 值，或者使用时间函数。datetime 的格式类似于 '2016-10-08 16:45:26.999'，最小时间单位为毫秒。但在大多数情况下，使用秒作为时间单位指定时间戳就足够了，例如 '2016-10-08 16:45:26'。 从 v6.5.6、v7.1.3、v7.5.1 和 v7.6.0 开始，TiDB 引入了 `FLASHBACK CLUSTER TO TSO` 语法。该语法允许你使用 [TSO](/tso.md) 来指定更精确的数据恢复时间点，从而提升数据恢复的灵活性。 > **Warning:** > -> `FLASHBACK CLUSTER TO [TIMESTAMP|TSO]` 语法不适用于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。为避免出现不可预期的结果，请不要在 {{{ .starter }}} 和 {{{ .essential }}} 集群上执行该语句。 +> `FLASHBACK CLUSTER TO [TIMESTAMP|TSO]` 语法不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。为避免出现不可预期的结果，请不要在 TiDB Cloud Starter 和 TiDB Cloud Essential 集群上执行该语句。 > **Warning:** > -> - 在指定恢复时间点时，请确保检查目标 timestamp 或 TSO 的有效性，避免指定超过 PD 当前分配的最大 TSO（可在 Grafana PD 面板的 `Current TSO` 查看）的未来时间。否则，可能会破坏并发处理的线性一致性和事务隔离级别，导致严重的数据正确性问题。 -> - 在 `FLASHBACK CLUSTER` 执行期间，数据清理过程不保证事务一致性。在 `FLASHBACK CLUSTER` 完成后，如果你打算使用 TiDB 的任何历史版本读取功能（如 [Stale Read](/stale-read.md) 或 [`tidb_snapshot`](/read-historical-data.md)），请确保指定的历史 timestamp 不在 `FLASHBACK CLUSTER` 执行期间。读取包含未被 FLASHBACK 完全恢复数据的历史版本，可能会破坏并发处理的线性一致性和事务隔离级别，导致严重的数据正确性问题。 +> - 在指定恢复时间点时，请务必检查目标 timestamp 或 TSO 的有效性，避免指定超过 PD 当前分配的最大 TSO（可在 Grafana PD 面板的 `Current TSO` 查看）的未来时间。否则，可能会破坏并发处理的线性一致性和事务隔离级别，导致严重的数据正确性问题。 +> - 在执行 `FLASHBACK CLUSTER` 期间，数据清理过程不保证事务一致性。在 `FLASHBACK CLUSTER` 完成后，如果你打算使用 TiDB 的任何历史版本读取功能（如 [Stale Read](/stale-read.md) 或 [`tidb_snapshot`](/read-historical-data.md)），请确保指定的历史时间戳不在 `FLASHBACK CLUSTER` 执行期间。读取包含未被 FLASHBACK 完全恢复数据的历史版本，可能会破坏并发处理的线性一致性和事务隔离级别，导致严重的数据正确性问题。 > **Warning:** > -> 在 TiDB v7.1.0 中使用该功能时，部分 Region 可能在 FLASHBACK 操作完成后仍处于 FLASHBACK 过程中。建议避免在 v7.1.0 中使用该功能。详情可参考 issue [#44292](https://github.com/pingcap/tidb/issues/44292)。 +> 当你在 TiDB v7.1.0 中使用该功能时，即使 FLASHBACK 操作完成，部分 Region 可能仍处于 FLASHBACK 过程中。建议避免在 v7.1.0 中使用该功能。详情可参考 issue [#44292](https://github.com/pingcap/tidb/issues/44292)。 > > 如果你遇到该问题，可以使用 [TiDB 快照备份与恢复](/br/br-snapshot-guide.md) 功能进行数据恢复。 @@ -57,29 +57,29 @@ FlashbackToTimestampStmt * 只有拥有 `SUPER` 权限的用户才能执行 `FLASHBACK CLUSTER` SQL 语句。 -* `FLASHBACK CLUSTER` 不支持回滚修改 PD 相关信息的 DDL 语句，如 `ALTER TABLE ATTRIBUTE`、`ALTER TABLE REPLICA` 和 `CREATE PLACEMENT POLICY`。 +* `FLASHBACK CLUSTER` 不支持回滚修改 PD 相关信息的 DDL 语句，例如 `ALTER TABLE ATTRIBUTE`、`ALTER TABLE REPLICA` 和 `CREATE PLACEMENT POLICY`。 * 在 `FLASHBACK` 语句指定的时间点，不能存在未完全执行的 DDL 语句。如果存在此类 DDL，TiDB 会拒绝执行。 * 在执行 `FLASHBACK CLUSTER` 前，TiDB 会断开所有相关连接，并禁止对这些表的读写操作，直到 `FLASHBACK CLUSTER` 语句执行完成。 * `FLASHBACK CLUSTER` 语句在执行后无法取消，TiDB 会持续重试直到成功。 -* 在执行 `FLASHBACK CLUSTER` 期间，如需备份数据，只能使用 [Backup & Restore](/br/br-snapshot-guide.md) 并指定早于 `FLASHBACK CLUSTER` 开始时间的 `BackupTS`。此外，在 `FLASHBACK CLUSTER` 执行期间，开启 [日志备份](/br/br-pitr-guide.md) 会失败。因此，建议在 `FLASHBACK CLUSTER` 完成后再开启日志备份。 -* 如果 `FLASHBACK CLUSTER` 语句导致元数据（表结构、数据库结构）回滚，相关修改 **不会** 被 TiCDC 同步。因此，你需要手动暂停任务，等待 `FLASHBACK CLUSTER` 完成后，手动同步上下游的 schema 定义以确保一致。之后需要重新创建 TiCDC changefeed。 +* 在执行 `FLASHBACK CLUSTER` 期间，如果需要备份数据，只能使用 [Backup & Restore](/br/br-snapshot-guide.md) 并指定早于 `FLASHBACK CLUSTER` 开始时间的 `BackupTS`。此外，在 `FLASHBACK CLUSTER` 执行期间，开启 [日志备份](/br/br-pitr-guide.md) 会失败。因此，建议在 `FLASHBACK CLUSTER` 完成后再开启日志备份。 +* 如果 `FLASHBACK CLUSTER` 语句导致元数据（表结构、数据库结构）回滚，相关修改 **不会** 被 TiCDC 同步。因此，你需要手动暂停任务，等待 `FLASHBACK CLUSTER` 完成后，手动同步上下游的表结构定义，确保一致。之后需要重新创建 TiCDC changefeed。 * 只有拥有 `SUPER` 权限的用户才能执行 `FLASHBACK CLUSTER` SQL 语句。 -* `FLASHBACK CLUSTER` 不支持回滚修改 PD 相关信息的 DDL 语句，如 `ALTER TABLE ATTRIBUTE`、`ALTER TABLE REPLICA` 和 `CREATE PLACEMENT POLICY`。 +* `FLASHBACK CLUSTER` 不支持回滚修改 PD 相关信息的 DDL 语句，例如 `ALTER TABLE ATTRIBUTE`、`ALTER TABLE REPLICA` 和 `CREATE PLACEMENT POLICY`。 * 在 `FLASHBACK` 语句指定的时间点，不能存在未完全执行的 DDL 语句。如果存在此类 DDL，TiDB 会拒绝执行。 * 在执行 `FLASHBACK CLUSTER` 前，TiDB 会断开所有相关连接，并禁止对这些表的读写操作，直到 `FLASHBACK CLUSTER` 语句执行完成。 * `FLASHBACK CLUSTER` 语句在执行后无法取消，TiDB 会持续重试直到成功。 -* 如果 `FLASHBACK CLUSTER` 语句导致元数据（表结构、数据库结构）回滚，相关修改 **不会** 被 TiCDC 同步。因此，你需要手动暂停任务，等待 `FLASHBACK CLUSTER` 完成后，手动同步上下游的 schema 定义以确保一致。之后需要重新创建 TiCDC changefeed。 +* 如果 `FLASHBACK CLUSTER` 语句导致元数据（表结构、数据库结构）回滚，相关修改 **不会** 被 TiCDC 同步。因此，你需要手动暂停任务，等待 `FLASHBACK CLUSTER` 完成后，手动同步上下游的表结构定义，确保一致。之后需要重新创建 TiCDC changefeed。 ## 示例 -以下示例展示了如何将集群 flashback 到某个特定 timestamp，以恢复新插入的数据： +以下示例展示了如何将集群 flashback 到某个特定时间戳，以恢复新插入的数据： ```sql mysql> CREATE TABLE t(a INT); @@ -160,7 +160,7 @@ mysql> SELECT * FROM t; 1 row in set (0.01 sec) ``` -如果在 `FLASHBACK` 语句指定的时间点存在未完全执行的 DDL 语句，则 `FLASHBACK` 语句会执行失败： +如果在 `FLASHBACK` 语句指定的时间点存在未完全执行的 DDL 语句，则 `FLASHBACK` 语句会失败： ```sql mysql> ALTER TABLE t ADD INDEX k(a); diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index b1a1fd8e997e9..383be1c3f789d 100644 --- a/sql-statements/sql-statement-import-into.md +++ b/sql-statements/sql-statement-import-into.md @@ -31,26 +31,26 @@ summary: TiDB 中 IMPORT INTO 的用法概述。 - 一次导入任务仅支持向一个目标表导入数据。 - TiDB 集群升级期间不支持 `IMPORT INTO`。 - 确保待导入数据中不包含任何主键或非空唯一索引冲突的记录，否则会导致导入任务失败。 -- 已知问题：如果 TiDB 节点配置文件中的 PD 地址与当前集群的 PD 拓扑不一致，`IMPORT INTO` 任务可能会失败。该不一致可能出现在 PD 曾经缩容但 TiDB 配置文件未及时更新，或配置文件更新后 TiDB 节点未重启等场景。 +- 已知问题：如果 TiDB 节点配置文件中的 PD 地址与当前集群的 PD 拓扑不一致，`IMPORT INTO` 任务可能会失败。例如，PD 曾经缩容但 TiDB 配置文件未同步更新，或配置文件更新后 TiDB 节点未重启。 ### `IMPORT INTO ... FROM FILE` 限制 -- 对于自建 TiDB，每个 `IMPORT INTO` 任务支持导入不超过 10 TiB 的数据。如果启用 [Global Sort](/tidb-global-sort.md) 功能，每个 `IMPORT INTO` 任务支持导入不超过 40 TiB 的数据。 -- 对于 [TiDB Cloud 专业版](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)，如果待导入数据超过 500 GiB，建议使用至少 16 核的 TiDB 节点并启用 [Global Sort](/tidb-global-sort.md) 功能，此时每个 `IMPORT INTO` 任务支持导入不超过 40 TiB 的数据。如果待导入数据不超过 500 GiB，或 TiDB 节点核数小于 16，则不建议启用 [Global Sort](/tidb-global-sort.md) 功能。 -- 执行 `IMPORT INTO ... FROM FILE` 时会阻塞当前连接，直到导入完成。若需异步执行该语句，可添加 `DETACHED` 选项。 +- 对于自建 TiDB，每个 `IMPORT INTO` 任务支持导入不超过 10 TiB 的数据。如果启用 [Global Sort](/tidb-global-sort.md) 功能，每个任务支持导入不超过 40 TiB 的数据。 +- 对于 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)，如果待导入数据超过 500 GiB，建议使用至少 16 核的 TiDB 节点并启用 [Global Sort](/tidb-global-sort.md) 功能，此时每个任务支持导入不超过 40 TiB 的数据。如果数据量在 500 GiB 以内或 TiDB 节点核数小于 16，则不建议启用 [Global Sort](/tidb-global-sort.md)。 +- 执行 `IMPORT INTO ... FROM FILE` 会阻塞当前连接直到导入完成。若需异步执行，可添加 `DETACHED` 选项。 - 每个集群最多可同时运行 16 个 `IMPORT INTO` 任务（参见 [TiDB 分布式执行框架（DXF）使用限制](/tidb-distributed-execution-framework.md#limitation)）。当集群资源不足或任务数已达上限时，新提交的导入任务会排队等待执行。 - 使用 [Global Sort](/tidb-global-sort.md) 功能导入数据时，`THREAD` 选项的值必须至少为 `8`。 - 使用 [Global Sort](/tidb-global-sort.md) 功能导入数据时，单行编码后的数据大小不得超过 32 MiB。 -- 在未启用 [TiDB 分布式执行框架（DXF）](/tidb-distributed-execution-framework.md) 时创建的所有 `IMPORT INTO` 任务，均直接在提交任务的节点上运行，即使后续启用了 DXF，这些任务也不会被调度到其他 TiDB 节点执行。启用 DXF 后，只有新创建的、从 S3 或 GCS 导入数据的 `IMPORT INTO` 任务才会自动调度或故障转移到其他 TiDB 节点执行。 +- 在未启用 [TiDB 分布式执行框架（DXF）](/tidb-distributed-execution-framework.md) 时创建的所有 `IMPORT INTO` 任务，均直接在提交任务的节点上运行，即使后续启用 DXF，这些任务也不会被调度到其他 TiDB 节点。启用 DXF 后，只有新创建的、从 S3 或 GCS 导入数据的 `IMPORT INTO` 任务会自动调度或故障转移到其他 TiDB 节点执行。 ### `IMPORT INTO ... FROM SELECT` 限制 - `IMPORT INTO ... FROM SELECT` 只能在当前用户连接的 TiDB 节点上执行，并且会阻塞当前连接直到导入完成。 - `IMPORT INTO ... FROM SELECT` 仅支持两种 [导入选项](#withoptions)：`THREAD` 和 `DISABLE_PRECHECK`。 - `IMPORT INTO ... FROM SELECT` 不支持 `SHOW IMPORT JOB(s)`、`CANCEL IMPORT JOB ` 等任务管理语句。 -- TiDB 的 [临时目录](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630) 需要有足够空间存储 `SELECT` 语句的完整查询结果（当前不支持配置 `DISK_QUOTA` 选项）。 +- TiDB 的 [临时目录](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630) 需要有足够空间存储 `SELECT` 语句的完整查询结果（目前不支持配置 `DISK_QUOTA` 选项）。 - 不支持使用 [`tidb_snapshot`](/read-historical-data.md) 导入历史数据。 -- 由于 `SELECT` 子句语法复杂，`IMPORT INTO` 中的 `WITH` 参数可能与其冲突并导致解析错误，如 `GROUP BY ... [WITH ROLLUP]`。建议对于复杂的 `SELECT` 语句，先创建视图，再通过 `IMPORT INTO ... FROM SELECT * FROM view_name` 导入。或者，可以用括号明确 `SELECT` 子句的范围，如 `IMPORT INTO ... FROM (SELECT ...) WITH ...`。 +- 由于 `SELECT` 子句语法复杂，`IMPORT INTO` 中的 `WITH` 参数可能与其冲突并导致解析错误，如 `GROUP BY ... [WITH ROLLUP]`。建议对于复杂的 `SELECT` 语句，先创建视图，再通过 `IMPORT INTO ... FROM SELECT * FROM view_name` 导入。或者用括号明确 `SELECT` 子句的范围，如 `IMPORT INTO ... FROM (SELECT ...) WITH ...`。 ## 导入前提条件 @@ -58,11 +58,11 @@ summary: TiDB 中 IMPORT INTO 的用法概述。 - 目标表已在 TiDB 中创建且为空表。 - 目标集群有足够空间存储待导入数据。 -- 对于自建 TiDB，当前会话连接的 TiDB 节点的 [临时目录](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630) 至少有 90 GiB 可用空间。如果已启用 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 且导入数据来源为 S3 或 GCS，还需确保集群中每个 TiDB 节点的临时目录有足够磁盘空间。 +- 对于自建 TiDB，当前会话连接的 TiDB 节点的 [临时目录](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630) 至少有 90 GiB 可用空间。如果已启用 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 且导入数据来源为 S3 或 GCS，还需确保集群中每个 TiDB 节点的临时目录磁盘空间充足。 ## 所需权限 -执行 `IMPORT INTO` 需要对目标表拥有 `SELECT`、`UPDATE`、`INSERT`、`DELETE` 和 `ALTER` 权限。若需导入 TiDB 本地存储中的文件，还需拥有 `FILE` 权限。 +执行 `IMPORT INTO` 需要对目标表拥有 `SELECT`、`UPDATE`、`INSERT`、`DELETE` 和 `ALTER` 权限。若需导入 TiDB 本地存储的文件，还需拥有 `FILE` 权限。 ## 语法 @@ -101,13 +101,13 @@ OptionItem ::= 用于指定数据文件中每个字段与目标表列的对应关系。你也可以用它将字段映射到变量，以跳过某些字段的导入，或在 `SetClause` 中使用。 - 如果未指定该参数，则数据文件每行的字段数必须与目标表的列数一致，字段将按顺序导入到对应列。 -- 如果指定了该参数，则指定的列或变量数必须与数据文件每行的字段数一致。 +- 如果指定了该参数，则指定的列或变量数量必须与数据文件每行的字段数一致。 ### SetClause -用于指定目标列的值如何计算。在 `SET` 表达式的右侧，可以引用 `ColumnNameOrUserVarList` 中指定的变量。 +用于指定目标列的值如何计算。在 `SET` 表达式右侧，可以引用 `ColumnNameOrUserVarList` 中指定的变量。 -在 `SET` 表达式的左侧，只能引用未包含在 `ColumnNameOrUserVarList` 中的列名。如果目标列名已在 `ColumnNameOrUserVarList` 中出现，则该 `SET` 表达式无效。 +在 `SET` 表达式左侧，只能引用未包含在 `ColumnNameOrUserVarList` 中的列名。如果目标列名已在 `ColumnNameOrUserVarList` 中出现，则该 `SET` 表达式无效。 ### fileLocation @@ -115,17 +115,17 @@ OptionItem ::= - Amazon S3 或 GCS URI 路径：URI 配置详情参见 [外部存储服务的 URI 格式](/external-storage-uri.md)。 -- TiDB 本地文件路径：必须为绝对路径，且文件扩展名为 `.csv`、`.sql` 或 `.parquet`。确保该路径对应的文件存储在当前用户连接的 TiDB 节点上，且该用户拥有 `FILE` 权限。 +- TiDB 本地文件路径：必须为绝对路径，且文件扩展名为 `.csv`、`.sql` 或 `.parquet`。确保该路径对应的文件存储在当前用户连接的 TiDB 节点上，且用户拥有 `FILE` 权限。 > **Note:** > > 如果目标集群启用了 [SEM](/system-variables.md#tidb_enable_enhanced_security)，则 `fileLocation` 不能指定为本地文件路径。 -在 `fileLocation` 参数中，你可以指定单个文件，也可以使用 `*` 和 `[]` 通配符匹配多个文件进行导入。注意，通配符只能用于文件名部分，不能匹配目录或递归匹配子目录下的文件。以存储在 Amazon S3 的文件为例，参数配置如下： +在 `fileLocation` 参数中，你可以指定单个文件，也可以使用 `*` 和 `[]` 通配符匹配多个文件进行导入。注意，通配符只能用于文件名部分，不能匹配目录或递归匹配子目录下的文件。以 Amazon S3 存储的文件为例，参数配置如下： - 导入单个文件：`s3:///path/to/data/foo.csv` - 导入指定路径下所有文件：`s3:///path/to/data/*` -- 导入指定路径下所有 `.csv` 后缀的文件：`s3:///path/to/data/*.csv` +- 导入指定路径下所有 `.csv` 后缀文件：`s3:///path/to/data/*.csv` - 导入指定路径下所有以 `foo` 为前缀的文件：`s3:///path/to/data/foo*` - 导入指定路径下所有以 `foo` 为前缀且以 `.csv` 结尾的文件：`s3:///path/to/data/foo*.csv` - 导入指定路径下的 `1.csv` 和 `2.csv`：`s3:///path/to/data/[12].csv` @@ -136,7 +136,7 @@ OptionItem ::= ### WithOptions -你可以使用 `WithOptions` 指定导入选项，控制数据导入过程。例如，若需在后台异步执行数据文件导入，可在 `IMPORT INTO` 语句中添加 `WITH DETACHED` 选项启用 `DETACHED` 模式。 +你可以通过 `WithOptions` 指定导入选项，控制数据导入过程。例如，若需在后台异步执行数据文件导入，可在 `IMPORT INTO` 语句中添加 `WITH DETACHED` 选项启用 `DETACHED` 模式。 支持的选项说明如下： @@ -149,30 +149,30 @@ OptionItem ::= | `FIELDS_DEFINED_NULL_BY=''` | CSV | 指定字段中表示 `NULL` 的值。默认值为 `\N`。| | `LINES_TERMINATED_BY=''` | CSV | 指定行终止符。默认情况下，`IMPORT INTO` 会自动识别 `\n`、`\r` 或 `\r\n` 作为行终止符。如果行终止符为这三者之一，无需显式指定该选项。| | `SKIP_ROWS=` | CSV | 指定跳过的行数。默认值为 `0`。可用于跳过 CSV 文件的表头。如果使用通配符指定导入源文件，该选项会应用于 `fileLocation` 匹配到的所有源文件。| -| `SPLIT_FILE` | CSV | 将单个 CSV 文件拆分为多个约 256 MiB 的小块并并行处理，以提升导入效率。该参数仅对**非压缩**的 CSV 文件生效，且使用限制与 TiDB Lightning 的 [`strict-format`](https://docs.pingcap.com/tidb/stable/tidb-lightning-data-source#strict-format) 相同。注意，使用该选项时需显式指定 `LINES_TERMINATED_BY`。| -| `DISK_QUOTA=''` | 所有文件格式 | 指定数据排序过程中可用的磁盘空间阈值。默认值为 TiDB [临时目录](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630) 磁盘空间的 80%。若无法获取总磁盘大小，默认值为 50 GiB。显式指定 `DISK_QUOTA` 时，确保该值不超过 TiDB 临时目录磁盘空间的 80%。| -| `DISABLE_TIKV_IMPORT_MODE` | 所有文件格式 | 指定导入过程中是否禁用 TiKV 切换为导入模式。默认不禁用 TiKV 切换为导入模式。如果集群中有读写操作进行中，可启用该选项以避免导入过程的影响。| -| `THREAD=` | 所有文件格式及 `SELECT` 查询结果 | 指定导入并发度。对于 `IMPORT INTO ... FROM FILE`，`THREAD` 默认值为 TiDB 节点 CPU 核数的 50%，最小值为 `1`，最大值为 CPU 核数。对于 `IMPORT INTO ... FROM SELECT`，`THREAD` 默认值为 `2`，最小值为 `1`，最大值为 TiDB 节点 CPU 核数的两倍。若向新集群导入数据，建议适当提高并发度以提升导入性能。若目标集群已在生产环境中使用，建议根据业务需求调整并发度。| -| `MAX_WRITE_SPEED=''` | 所有文件格式 | 控制写入到 TiKV 节点的速度。默认无限速。例如，可指定为 `1MiB`，限制写入速度为 1 MiB/s。| +| `SPLIT_FILE` | CSV | 将单个 CSV 文件切分为多个约 256 MiB 的小块并行处理，以提升导入效率。该参数仅对**非压缩**的 CSV 文件生效，且使用限制与 TiDB Lightning 的 [`strict-format`](https://docs.pingcap.com/tidb/stable/tidb-lightning-data-source#strict-format) 相同。注意需显式指定 `LINES_TERMINATED_BY`。| +| `DISK_QUOTA=''` | 所有文件格式 | 指定数据排序可用的磁盘空间阈值。默认值为 TiDB [临时目录](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630) 磁盘空间的 80%。若无法获取总磁盘大小，默认值为 50 GiB。显式指定 `DISK_QUOTA` 时，确保该值不超过 TiDB 临时目录磁盘空间的 80%。| +| `DISABLE_TIKV_IMPORT_MODE` | 所有文件格式 | 指定是否在导入过程中禁用 TiKV 切换为导入模式。默认不禁用 TiKV 切换为导入模式。如果集群有读写业务，可启用该选项以避免导入过程的影响。| +| `THREAD=` | 所有文件格式及 `SELECT` 查询结果 | 指定导入并发度。对于 `IMPORT INTO ... FROM FILE`，`THREAD` 默认值为 TiDB 节点 CPU 核数的 50%，最小值为 `1`，最大值为 CPU 核数。对于 `IMPORT INTO ... FROM SELECT`，默认值为 `2`，最小值为 `1`，最大值为 TiDB 节点 CPU 核数的两倍。若向新集群导入数据，建议适当提高并发度以提升导入性能。若目标集群已用于生产环境，建议根据业务需求调整并发度。| +| `MAX_WRITE_SPEED=''` | 所有文件格式 | 控制写入 TiKV 节点的速度。默认无限制。例如，可指定为 `1MiB`，限制写入速度为 1 MiB/s。| | `CHECKSUM_TABLE=''` | 所有文件格式 | 配置导入完成后是否对目标表进行校验以验证导入完整性。支持的值包括 `"required"`（默认）、`"optional"` 和 `"off"`。`"required"` 表示导入后进行校验，校验失败则返回错误并退出导入；`"optional"` 表示导入后进行校验，若出错则返回警告并忽略错误；`"off"` 表示导入后不进行校验。| -| `DETACHED` | 所有文件格式 | 控制是否异步执行 `IMPORT INTO`。启用该选项后，执行 `IMPORT INTO` 会立即返回导入任务信息（如 `Job_ID`），任务在后台异步执行。| -| `CLOUD_STORAGE_URI` | 所有文件格式 | 指定 [Global Sort](/tidb-global-sort.md) 编码 KV 数据的目标存储地址。未指定 `CLOUD_STORAGE_URI` 时，`IMPORT INTO` 会根据系统变量 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 的值判断是否启用 Global Sort。如果该系统变量指定了目标存储地址，则使用该地址进行 Global Sort。若 `CLOUD_STORAGE_URI` 显式指定非空值，则使用该值作为目标存储地址。若 `CLOUD_STORAGE_URI` 显式指定为空值，则强制本地排序。目前目标存储地址仅支持 S3。URI 配置详情参见 [Amazon S3 URI 格式](/external-storage-uri.md#amazon-s3-uri-format)。使用该功能时，所有 TiDB 节点必须具备目标 S3 bucket 的读写权限，包括至少以下权限：`s3:ListBucket`、`s3:GetObject`、`s3:DeleteObject`、`s3:PutObject`、`s3:AbortMultipartUpload`。| -| `DISABLE_PRECHECK` | 所有文件格式及 `SELECT` 查询结果 | 设置该选项可禁用非关键项的预检查，如检查是否存在 CDC 或 PITR 任务。| +| `DETACHED` | 所有文件格式 | 控制是否异步执行 `IMPORT INTO`。启用后，执行 `IMPORT INTO` 会立即返回导入任务信息（如 `Job_ID`），任务在后台异步执行。| +| `CLOUD_STORAGE_URI` | 所有文件格式 | 指定 [Global Sort](/tidb-global-sort.md) 编码 KV 数据的目标存储地址。未指定时，`IMPORT INTO` 会根据系统变量 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 的值判断是否启用 Global Sort。如果该系统变量指定了目标存储地址，则使用该地址进行 Global Sort。若 `CLOUD_STORAGE_URI` 显式指定非空值，则使用该值作为目标存储地址。若指定为空值，则强制本地排序。目前目标存储地址仅支持 S3。URI 配置详情参见 [Amazon S3 URI 格式](/external-storage-uri.md#amazon-s3-uri-format)。使用该功能时，所有 TiDB 节点需具备目标 S3 bucket 的读写权限，包括至少：`s3:ListBucket`、`s3:GetObject`、`s3:DeleteObject`、`s3:PutObject`、`s3:AbortMultipartUpload`。| +| `DISABLE_PRECHECK` | 所有文件格式及 `SELECT` 查询结果 | 设置该选项可禁用非关键项的预检查，如是否存在 CDC 或 PITR 任务的检查。| ## `IMPORT INTO ... FROM FILE` 用法 -对于自建 TiDB，`IMPORT INTO ... FROM FILE` 支持从 Amazon S3、GCS 及 TiDB 本地存储导入数据文件。对于 [TiDB Cloud 专业版](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)，`IMPORT INTO ... FROM FILE` 支持从 Amazon S3 和 GCS 导入数据文件。对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，`IMPORT INTO ... FROM FILE` 支持从 Amazon S3 和阿里云 OSS 导入数据文件。 +对于自建 TiDB，`IMPORT INTO ... FROM FILE` 支持从 Amazon S3、GCS 及 TiDB 本地存储的文件导入数据。对于 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)，支持从 Amazon S3 和 GCS 导入。对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，支持从 Amazon S3 和阿里云 OSS 导入。 - 对于存储在 Amazon S3 或 GCS 的数据文件，`IMPORT INTO ... FROM FILE` 支持在 [TiDB 分布式执行框架（DXF）](/tidb-distributed-execution-framework.md) 下运行。 - 启用 DXF（[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 为 `ON`）时，`IMPORT INTO` 会将数据导入任务拆分为多个子任务，并分发到不同 TiDB 节点并行执行，以提升导入效率。 - 未启用 DXF 时，`IMPORT INTO ... FROM FILE` 仅支持在当前用户连接的 TiDB 节点上运行。 -- 对于存储在 TiDB 本地的数据文件，`IMPORT INTO ... FROM FILE` 仅支持在当前用户连接的 TiDB 节点上运行。因此，数据文件需放置在当前用户连接的 TiDB 节点上。如果你通过代理或负载均衡访问 TiDB，则无法导入存储在 TiDB 本地的数据文件。 +- 对于存储在 TiDB 本地的数据文件，`IMPORT INTO ... FROM FILE` 仅支持在当前用户连接的 TiDB 节点上运行。因此，数据文件需放置在当前用户连接的 TiDB 节点上。如果你通过代理或负载均衡访问 TiDB，则无法导入 TiDB 本地存储的文件。 ### 压缩文件 -`IMPORT INTO ... FROM FILE` 支持导入压缩的 `CSV` 和 `SQL` 文件。可根据文件扩展名自动判断文件是否压缩及压缩格式： +`IMPORT INTO ... FROM FILE` 支持导入压缩的 `CSV` 和 `SQL` 文件。可根据文件扩展名自动识别文件是否压缩及压缩格式： | 扩展名 | 压缩格式 | |:---|:---| @@ -182,26 +182,26 @@ OptionItem ::= > **Note:** > -> - Snappy 压缩文件必须为 [官方 Snappy 格式](https://github.com/google/snappy)。不支持其他变种的 Snappy 压缩格式。 +> - Snappy 压缩文件必须为 [官方 Snappy 格式](https://github.com/google/snappy)。不支持其他变体的 Snappy 压缩。 > - 由于 TiDB Lightning 无法对单个大型压缩文件并发解压，压缩文件的大小会影响导入速度。建议单个源文件解压后不超过 256 MiB。 ### Global Sort > **Note:** > -> Global Sort 不支持在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群上使用。 +> Global Sort 不支持在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群上使用。 -`IMPORT INTO ... FROM FILE` 会将源数据文件的导入任务拆分为多个子任务，每个子任务独立编码、排序后导入数据。如果这些子任务编码后的 KV 范围有较大重叠（关于 TiDB 如何将数据编码为 KV，参见 [TiDB 计算](/tidb-computing.md)），则 TiKV 在导入过程中需要持续进行 compaction，导致导入性能和稳定性下降。 +`IMPORT INTO ... FROM FILE` 会将源数据文件的导入任务拆分为多个子任务，每个子任务独立编码、排序后导入数据。如果这些子任务编码后的 KV 范围有大量重叠（关于 TiDB 如何将数据编码为 KV，参见 [TiDB 计算](/tidb-computing.md)），则 TiKV 在导入过程中需持续进行 compaction，导致导入性能和稳定性下降。 -以下场景可能导致 KV 范围重叠较大： +以下场景可能导致 KV 范围重叠较多： - 若分配给各子任务的数据文件行的主键范围有重叠，则各子任务编码生成的数据 KV 也会重叠。 - - `IMPORT INTO` 按数据文件的遍历顺序拆分子任务，通常按文件名字典序排序。 + - `IMPORT INTO` 按数据文件遍历顺序拆分子任务，通常按文件名字典序排序。 - 若目标表有大量索引，或索引列值在数据文件中分布较散，则各子任务编码生成的索引 KV 也会重叠。 启用 [TiDB 分布式执行框架（DXF）](/tidb-distributed-execution-framework.md) 后，你可以通过在 `IMPORT INTO` 语句中指定 `CLOUD_STORAGE_URI` 选项，或通过系统变量 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 指定编码 KV 数据的目标存储地址来启用 [Global Sort](/tidb-global-sort.md)。目前 Global Sort 仅支持使用 Amazon S3 作为存储地址。启用 Global Sort 后，`IMPORT INTO` 会将编码后的 KV 数据写入云存储，在云存储中进行全局排序，然后并行将全局有序的索引和表数据导入 TiKV，从而避免 KV 重叠带来的问题，提升导入的稳定性和性能。 -Global Sort 会消耗大量内存资源。建议在数据导入前，配置 [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640) 和 [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640) 变量，避免频繁触发 golang GC 影响导入效率。 +Global Sort 会消耗大量内存资源。建议在数据导入前配置 [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640) 和 [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640) 变量，避免频繁触发 golang GC 影响导入效率。 ```sql SET GLOBAL tidb_server_memory_limit_gc_trigger=1; @@ -210,14 +210,14 @@ SET GLOBAL tidb_server_memory_limit='75%'; > **Note:** > -> - 如果源数据文件的 KV 范围重叠较低，启用 Global Sort 可能会降低导入性能。因为启用 Global Sort 后，TiDB 需要等待所有子任务本地排序完成，才能进行全局排序及后续导入操作。 +> - 如果源数据文件的 KV 范围重叠较低，启用 Global Sort 可能会降低导入性能。因为启用 Global Sort 后，TiDB 需等待所有子任务本地排序完成后，才能进行全局排序及后续导入操作。 > - 使用 Global Sort 的导入任务完成后，云存储中用于 Global Sort 的文件会在后台线程中异步清理。 ### 输出 当 `IMPORT INTO ... FROM FILE` 导入完成或启用 `DETACHED` 模式时，TiDB 会在输出中返回当前任务信息，示例如下。各字段说明参见 [`SHOW IMPORT JOB(s)`](/sql-statements/sql-statement-show-import-job.md)。 -`IMPORT INTO ... FROM FILE` 导入完成时，输出示例如下： +`IMPORT INTO ... FROM FILE` 导入完成时，输出示例： ```sql IMPORT INTO t FROM '/path/to/small.csv'; @@ -241,7 +241,7 @@ IMPORT INTO t FROM '/path/to/small.csv' WITH DETACHED; ### 查看和管理导入任务 -对于启用 `DETACHED` 模式的导入任务，你可以使用 [`SHOW IMPORT`](/sql-statements/sql-statement-show-import-job.md) 查看其当前进度。 +对于启用 `DETACHED` 模式的导入任务，你可以使用 [`SHOW IMPORT`](/sql-statements/sql-statement-show-import-job.md) 查看当前任务进度。 导入任务启动后，可以通过 [`CANCEL IMPORT JOB `](/sql-statements/sql-statement-cancel-import-job.md) 取消任务。 @@ -269,7 +269,7 @@ id,name,age 2,Jack,44 ``` -假设目标表结构为 `CREATE TABLE t(id int primary key, name varchar(100))`。若需跳过 `age` 字段的导入，可执行如下 SQL 语句： +假设目标表结构为 `CREATE TABLE t(id int primary key, name varchar(100))`。若需跳过 `age` 字段的导入，可执行如下 SQL： ```sql IMPORT INTO t(id, name, @1) FROM '/path/to/file.csv' WITH skip_rows=1; @@ -277,13 +277,13 @@ IMPORT INTO t(id, name, @1) FROM '/path/to/file.csv' WITH skip_rows=1; #### 使用通配符导入多个数据文件 -假设 `/path/to/` 目录下有 `file-01.csv`、`file-02.csv` 和 `file-03.csv` 三个文件。若需将这三个文件导入目标表 `t`，可执行如下 SQL 语句： +假设 `/path/to/` 目录下有 `file-01.csv`、`file-02.csv` 和 `file-03.csv` 三个文件。要将这三个文件导入目标表 `t`，可执行如下 SQL： ```sql IMPORT INTO t FROM '/path/to/file-*.csv'; ``` -若只需将 `file-01.csv` 和 `file-03.csv` 导入目标表，可执行如下 SQL 语句： +如只需导入 `file-01.csv` 和 `file-03.csv`，可执行如下 SQL： ```sql IMPORT INTO t FROM '/path/to/file-0[13].csv'; @@ -315,7 +315,7 @@ id,name,val 2,book,440 ``` -假设目标表结构为 `CREATE TABLE t(id int primary key, name varchar(100), val int)`。若需在导入时将 `val` 列的值乘以 100，可执行如下 SQL 语句： +假设目标表结构为 `CREATE TABLE t(id int primary key, name varchar(100), val int)`。若需在导入时将 `val` 列的值乘以 100，可执行如下 SQL： ```sql IMPORT INTO t(id, name, @1) SET val=@1*100 FROM '/path/to/file.csv' WITH skip_rows=1; @@ -329,7 +329,7 @@ IMPORT INTO t FROM '/path/to/file.sql' FORMAT 'sql'; #### 限制写入 TiKV 的速度 -若需将写入 TiKV 节点的速度限制为 10 MiB/s，可执行如下 SQL 语句： +若需将写入 TiKV 节点的速度限制为 10 MiB/s，可执行如下 SQL： ```sql IMPORT INTO t FROM 's3://bucket/path/to/file.parquet?access-key=XXX&secret-access-key=XXX' FORMAT 'parquet' WITH MAX_WRITE_SPEED='10MiB'; @@ -341,7 +341,7 @@ IMPORT INTO t FROM 's3://bucket/path/to/file.parquet?access-key=XXX&secret-acces ### 导入 `SELECT` 查询结果 -若需将 `UNION` 结果导入目标表 `t`，并指定导入并发度为 `8`，禁用非关键项预检查，可执行如下 SQL 语句： +要将 `UNION` 结果导入目标表 `t`，并指定导入并发度为 `8`，禁用非关键项预检查，可执行如下 SQL： ```sql IMPORT INTO t FROM SELECT * FROM src UNION SELECT * FROM src2 WITH THREAD = 8, DISABLE_PRECHECK; @@ -349,7 +349,7 @@ IMPORT INTO t FROM SELECT * FROM src UNION SELECT * FROM src2 WITH THREAD = 8, D ### 导入指定时间点的历史数据 -若需将指定时间点的历史数据导入目标表 `t`，可执行如下 SQL 语句： +要将指定时间点的历史数据导入目标表 `t`，可执行如下 SQL： ```sql IMPORT INTO t FROM SELECT * FROM src AS OF TIMESTAMP '2024-02-27 11:38:00'; @@ -359,7 +359,7 @@ IMPORT INTO t FROM SELECT * FROM src AS OF TIMESTAMP '2024-02-27 11:38:00'; 该语句为 TiDB 对 MySQL 语法的扩展。 -## 另请参阅 +## 参见 * [`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) * [`CANCEL IMPORT JOB`](/sql-statements/sql-statement-cancel-import-job.md) diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index 5890803629921..5b7ae81698304 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -5,7 +5,7 @@ summary: TiDB 数据库中 LOAD DATA 的用法概述。 # LOAD DATA -`LOAD DATA` 语句用于批量将数据加载到 TiDB 表中。 +`LOAD DATA` 语句用于批量导入数据到 TiDB 表中。 从 TiDB v7.0.0 开始，`LOAD DATA` SQL 语句支持以下功能： @@ -14,13 +14,13 @@ summary: TiDB 数据库中 LOAD DATA 的用法概述。 > **Warning:** > -> 新参数 `FIELDS DEFINED NULL BY` 以及从 S3 和 GCS 导入数据的功能目前为实验性特性。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下变更或移除。如果你发现了 bug，可以在 GitHub 上[提交 issue](https://github.com/pingcap/tidb/issues)。 +> 新参数 `FIELDS DEFINED NULL BY` 以及从 S3 和 GCS 导入数据的功能目前为实验性特性。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下变更或移除。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 对于 `LOAD DATA INFILE` 语句，TiDB Cloud Dedicated 支持 `LOAD DATA LOCAL INFILE`，以及从 Amazon S3 或 Google Cloud Storage 加载数据，而 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 仅支持 `LOAD DATA LOCAL INFILE`。 +> 对于 `LOAD DATA INFILE` 语句，TiDB Cloud Dedicated 支持 `LOAD DATA LOCAL INFILE`，以及从 Amazon S3 或 Google Cloud Storage 的 `LOAD DATA INFILE`，而 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 仅支持 `LOAD DATA LOCAL INFILE`。 @@ -46,9 +46,9 @@ Fields ::= ### `LOCAL` -你可以使用 `LOCAL` 指定要导入的客户端本地数据文件，此时文件参数必须为客户端文件系统路径。 +你可以使用 `LOCAL` 指定要导入的客户端本地数据文件，此时文件参数必须是客户端文件系统的路径。 -如果你在使用 TiDB Cloud，想通过 `LOAD DATA` 语句加载本地数据文件，连接 TiDB Cloud 时需要在连接字符串中添加 `--local-infile` 选项。 +如果你在使用 TiDB Cloud，要通过 `LOAD DATA` 语句加载本地数据文件，连接 TiDB Cloud 时需要在连接字符串中添加 `--local-infile` 选项。 - 以下是 TiDB Cloud Starter 的连接字符串示例： @@ -75,13 +75,13 @@ Fields ::= -如果未指定 `LOCAL`，文件参数必须为合法的 S3 或 GCS 路径，具体格式详见 [外部存储](/br/backup-and-restore-storages.md)。 +如果未指定 `LOCAL`，文件参数必须是合法的 S3 或 GCS 路径，具体格式详见 [外部存储](/br/backup-and-restore-storages.md)。 -如果未指定 `LOCAL`，文件参数必须为合法的 S3 或 GCS 路径，具体格式详见 [外部存储](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)。 +如果未指定 `LOCAL`，文件参数必须是合法的 S3 或 GCS 路径，具体格式详见 [外部存储](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)。 @@ -116,34 +116,34 @@ Fields ::= "alice","33","street 1"\r\n ``` -如果你想提取 `bob`、`20` 和 `street 1`，需要将字段分隔符指定为 `','`，包裹字符指定为 `'\"'`： +如果你希望提取 `bob`、`20` 和 `street 1`，可以将字段分隔符指定为 `','`，包裹字符指定为 `'\"'`： ```sql FIELDS TERMINATED BY ',' ENCLOSED BY '\"' LINES TERMINATED BY '\r\n' ``` -如果你未指定上述参数，导入数据时默认按如下方式处理： +如果你未指定上述参数，导入的数据默认按如下方式处理： ```sql FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\' LINES TERMINATED BY '\n' STARTING BY '' ``` -你可以通过配置 `IGNORE LINES` 参数忽略文件的前 `number` 行。例如，配置 `IGNORE 1 LINES` 时，文件的第一行会被忽略。 +你可以通过配置 `IGNORE LINES` 参数，忽略文件的前 `number` 行。例如，配置 `IGNORE 1 LINES` 时，会忽略文件的第一行。 ## 示例 -以下示例使用 `LOAD DATA` 导入数据。字段分隔符为逗号，数据包裹的双引号会被忽略，文件的第一行会被忽略。 +以下示例使用 `LOAD DATA` 导入数据。指定逗号为字段分隔符，忽略包裹数据的双引号，忽略文件的第一行。 -如果你看到 `ERROR 1148 (42000): the used command is not allowed with this TiDB version`，请参考 [ERROR 1148 (42000): the used command is not allowed with this TiDB version](/error-codes.md#mysql-native-error-messages) 进行排查。 +如果你遇到 `ERROR 1148 (42000): the used command is not allowed with this TiDB version`，请参考 [ERROR 1148 (42000): the used command is not allowed with this TiDB version](/error-codes.md#mysql-native-error-messages) 进行排查。 -如果你看到 `ERROR 1148 (42000): the used command is not allowed with this TiDB version`，请参考 [ERROR 1148 (42000): the used command is not allowed with this TiDB version](https://docs.pingcap.com/tidb/stable/error-codes#mysql-native-error-messages) 进行排查。 +如果你遇到 `ERROR 1148 (42000): the used command is not allowed with this TiDB version`，请参考 [ERROR 1148 (42000): the used command is not allowed with this TiDB version](https://docs.pingcap.com/tidb/stable/error-codes#mysql-native-error-messages) 进行排查。 @@ -162,11 +162,11 @@ Records: 815264 Deleted: 0 Skipped: 0 Warnings: 0 LOAD DATA LOCAL INFILE '/mnt/evo970/data-sets/bikeshare-data/2017Q4-capitalbikeshare-tripdata.csv' INTO TABLE trips FIELDS TERMINATED BY x'2c' ENCLOSED BY b'100010' LINES TERMINATED BY '\r\n' IGNORE 1 LINES (duration, start_date, end_date, start_station_number, start_station, end_station_number, end_station, bike_number, member_type); ``` -在上述示例中，`x'2c'` 是字符 `,` 的十六进制表示，`b'100010'` 是字符 `"` 的二进制表示。 +在上述示例中，`x'2c'` 是 `,` 字符的十六进制表示，`b'100010'` 是 `"` 字符的二进制表示。 -以下示例展示了如何使用 `LOAD DATA INFILE` 语句从 Amazon S3 向 TiDB Cloud Dedicated 集群导入数据： +以下示例展示如何使用 `LOAD DATA INFILE` 语句从 Amazon S3 向 TiDB Cloud Dedicated 集群导入数据： ```sql LOAD DATA INFILE 's3:///your-file.csv?role_arn=&external_id=' @@ -181,7 +181,7 @@ IGNORE 1 LINES; ## MySQL 兼容性 -`LOAD DATA` 语句的语法与 MySQL 兼容，字符集相关选项会被解析但会被忽略。如果你发现任何语法兼容性差异，可以[提交 bug](https://docs.pingcap.com/tidb/stable/support)。 +`LOAD DATA` 语句的语法与 MySQL 兼容，字符集相关选项会被解析但会被忽略。如果你发现任何语法兼容性差异，可以 [报告 bug](https://docs.pingcap.com/tidb/stable/support)。 @@ -190,13 +190,13 @@ IGNORE 1 LINES; > - TiDB v4.0.0 之前的版本，`LOAD DATA` 每 20000 行提交一次，且不可配置。 > - TiDB v4.0.0 到 v6.6.0 版本，默认情况下 TiDB 会将所有行在一个事务中提交。但如果你需要 `LOAD DATA` 语句每固定行数提交一次，可以设置 [`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size) 为期望的行数。 > - 从 TiDB v7.0.0 开始，`tidb_dml_batch_size` 对 `LOAD DATA` 不再生效，TiDB 会将所有行在一个事务中提交。 -> - 从 TiDB v4.0.0 或更早版本升级后，可能会出现 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`。推荐的解决方法是增加 `tidb.toml` 文件中的 [`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit) 配置值。 +> - 从 TiDB v4.0.0 或更早版本升级后，可能会出现 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`。推荐的解决方法是增加 `tidb.toml` 文件中的 [`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit) 配置项的值。 > - TiDB v7.6.0 之前的版本，无论每个事务提交多少行，`LOAD DATA` 在显式事务中都不会被 [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) 语句回滚。 -> - TiDB v7.6.0 之前的版本，`LOAD DATA` 语句始终以乐观事务模式执行，无论 TiDB 的事务模式配置如何。 +> - TiDB v7.6.0 之前的版本，`LOAD DATA` 语句始终以乐观事务模式执行，不受 TiDB 事务模式配置影响。 > - 从 v7.6.0 开始，TiDB 处理 `LOAD DATA` 事务的方式与其他 DML 语句一致： > - `LOAD DATA` 语句不会提交当前事务，也不会开启新事务。 > - `LOAD DATA` 语句会受到 TiDB 事务模式（乐观或悲观事务）的影响。 -> - 事务中的 `LOAD DATA` 语句可以被该事务中的 [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) 语句回滚。 +> - 事务中的 `LOAD DATA` 语句可以被该事务内的 [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) 语句回滚。 @@ -207,17 +207,17 @@ IGNORE 1 LINES; > - TiDB v4.0.0 之前的版本，`LOAD DATA` 每 20000 行提交一次，且不可配置。 > - TiDB v4.0.0 到 v6.6.0 版本，默认情况下 TiDB 会将所有行在一个事务中提交。但如果你需要 `LOAD DATA` 语句每固定行数提交一次，可以设置 [`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size) 为期望的行数。 > - 从 v7.0.0 开始，`tidb_dml_batch_size` 对 `LOAD DATA` 不再生效，TiDB 会将所有行在一个事务中提交。 -> - 从 TiDB v4.0.0 或更早版本升级后，可能会出现 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`。如需解决该错误，可以联系 [TiDB Cloud Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) 增加 [`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit) 配置值。 +> - 从 TiDB v4.0.0 或更早版本升级后，可能会出现 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`。如需解决该错误，可以联系 [TiDB Cloud Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) 增大 [`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit) 配置项的值。 > - TiDB v7.6.0 之前的版本，无论每个事务提交多少行，`LOAD DATA` 在显式事务中都不会被 [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) 语句回滚。 -> - TiDB v7.6.0 之前的版本，`LOAD DATA` 语句始终以乐观事务模式执行，无论 TiDB 的事务模式配置如何。 +> - TiDB v7.6.0 之前的版本，`LOAD DATA` 语句始终以乐观事务模式执行，不受 TiDB 事务模式配置影响。 > - 从 v7.6.0 开始，TiDB 处理 `LOAD DATA` 事务的方式与其他 DML 语句一致： > - `LOAD DATA` 语句不会提交当前事务，也不会开启新事务。 > - `LOAD DATA` 语句会受到 TiDB 事务模式（乐观或悲观事务）的影响。 -> - 事务中的 `LOAD DATA` 语句可以被该事务中的 [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) 语句回滚。 +> - 事务中的 `LOAD DATA` 语句可以被该事务内的 [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) 语句回滚。 -## 相关内容 +## 另请参阅 diff --git a/sql-statements/sql-statement-load-stats.md b/sql-statements/sql-statement-load-stats.md index caf13e82c95e3..06a625705d538 100644 --- a/sql-statements/sql-statement-load-stats.md +++ b/sql-statements/sql-statement-load-stats.md @@ -9,7 +9,7 @@ summary: TiDB 数据库中 LOAD STATS 的用法概述。 > **Note:** > -> 此功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 此功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -24,7 +24,7 @@ LoadStatsStmt ::= 你也可以使用 `LOAD STATS ${stats_path}` 加载指定的统计信息文件。 -`${stats_path}` 可以是绝对路径，也可以是相对路径。如果你使用相对路径，则会从 `tidb-server` 启动时所在的路径查找对应的文件。以下是一个示例： +`${stats_path}` 可以是绝对路径，也可以是相对路径。如果你使用相对路径，则会从 `tidb-server` 启动时所在的路径查找对应的文件。示例如下： ```sql LOAD STATS '/tmp/stats.json'; @@ -38,6 +38,6 @@ Query OK, 0 rows affected (0.00 sec) 该语句是 TiDB 对 MySQL 语法的扩展。 -## 另请参阅 +## 参见 * [Statistics](/statistics.md) diff --git a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md index de300f1a2fb57..3922938d0c331 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -7,7 +7,7 @@ summary: TiDB 数据库中 LOCK TABLES 和 UNLOCK TABLES 的用法概述。 > **Warning:** > -> `LOCK TABLES` 和 `UNLOCK TABLES` 是当前版本的实验性特性。不建议在生产环境中使用。 +> `LOCK TABLES` 和 `UNLOCK TABLES` 是当前版本的实验性功能。不建议在生产环境中使用。 TiDB 允许客户端会话获取表锁，以便与其他会话协作访问表，或防止其他会话修改表。一个会话只能为自身获取或释放锁。一个会话不能为其他会话获取锁，也不能释放其他会话持有的锁。 @@ -22,8 +22,8 @@ TiDB 允许客户端会话获取表锁，以便与其他会话协作访问表， > 表锁功能默认是关闭的。 > > - 对于 TiDB 自建集群，要启用表锁功能，需要在所有 TiDB 实例的配置文件中将 [`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400) 设置为 `true`。 -> - 对于 TiDB Cloud Dedicated 集群，要启用表锁功能，需要联系 [TiDB Cloud Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) 将 [`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400) 设置为 `true`。 -> - 对于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，不支持将 [`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400) 设置为 `true`。 +> - 对于 TiDB Cloud 专属集群，要启用表锁功能，需要联系 [TiDB Cloud Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) 将 [`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400) 设置为 `true`。 +> - 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)，不支持将 [`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400) 设置为 `true`。 ## 语法 @@ -46,7 +46,7 @@ LockType `READ` 锁： -- 持有该锁的会话可以读取表，但不能写入表。 +- 持有该锁的会话可以读取表，但不能写入。 - 多个会话可以同时对同一张表获取 `READ` 锁。 - 其他会话可以在未显式获取 `READ` 锁的情况下读取该表。 @@ -55,14 +55,14 @@ LockType `WRITE` 锁： - 持有该锁的会话可以读写表。 -- 只有持有该锁的会话可以访问该表。在锁释放之前，其他会话无法访问该表。 +- 只有持有该锁的会话可以访问该表，其他会话在锁释放前无法访问。 `WRITE LOCAL` 锁： - 持有该锁的会话可以读写表。 -- 只有持有该锁的会话可以访问该表。其他会话可以读取该表，但不能写入。 +- 只有持有该锁的会话可以访问该表，其他会话可以读取该表，但不能写入。 -如果 `LOCK TABLES` 语句需要的锁已被其他会话持有，则 `LOCK TABLES` 语句必须等待，并在执行该语句时返回错误，例如： +如果 `LOCK TABLES` 语句需要的锁已被其他会话持有，则 `LOCK TABLES` 语句会等待，并在执行时返回错误，例如： ```sql > LOCK TABLES t1 READ; @@ -80,12 +80,12 @@ ERROR 1066 (42000): Not unique table/alias: 't' ## 释放表锁 -当会话持有的表锁被释放时，会同时释放所有锁。会话可以显式或隐式释放其锁。 +当会话持有的表锁被释放时，会同时释放所有锁。会话可以显式或隐式释放锁。 - 会话可以通过 `UNLOCK TABLES` 显式释放锁。 -- 如果会话在已持有锁的情况下再次执行 `LOCK TABLES` 语句获取新锁，则在获取新锁之前，已持有的锁会被隐式释放。 +- 如果会话在已持有锁的情况下再次执行 `LOCK TABLES` 语句获取新锁，则在获取新锁之前，原有锁会被隐式释放。 -如果客户端会话的连接终止（无论是正常还是异常），TiDB 会隐式释放该会话持有的所有表锁。如果客户端重新连接，锁将不再生效。因此，不建议在客户端启用自动重连功能。如果启用自动重连，客户端在发生重连时不会收到通知，所有表锁或当前事务都会丢失。相反，如果禁用自动重连，当连接断开时，下一条语句会报错。客户端可以检测到该错误，并采取相应措施，如重新获取锁或重做事务。 +如果客户端会话的连接终止（无论是正常还是异常），TiDB 会隐式释放该会话持有的所有表锁。如果客户端重新连接，锁将不再生效。因此，不建议在客户端启用自动重连功能。如果启用自动重连，客户端在重连时不会收到通知，所有表锁或当前事务都会丢失。相反，如果禁用自动重连，当连接断开时，下一条语句会报错。客户端可以检测到该错误，并采取相应措施，如重新获取锁或重做事务。 ## 表锁的限制与条件 @@ -102,10 +102,10 @@ ERROR 1066 (42000): Not unique table/alias: 't' ### 表锁获取 -- 在 TiDB 中，如果会话 A 已经持有表锁，当会话 B 尝试写入该表时会返回错误。而在 MySQL 中，会话 B 的写请求会被阻塞，直到会话 A 释放表锁，其他会话对该表的加锁请求也会被阻塞，直到当前会话释放 `WRITE` 锁。 -- 在 TiDB 中，如果 `LOCK TABLES` 语句需要的锁已被其他会话持有，则该语句必须等待，并在执行时返回错误。而在 MySQL 中，该语句会被阻塞，直到获取到锁为止。 -- 在 TiDB 中，`LOCK TABLES` 语句在整个集群范围内生效。而在 MySQL 中，该语句只在当前 MySQL 实例中生效，并且不兼容 NDB 集群。 +- 在 TiDB 中，如果会话 A 已经持有表锁，当会话 B 尝试写入该表时会返回错误。而在 MySQL 中，会话 B 的写请求会被阻塞，直到会话 A 释放表锁，其他会话的加锁请求也会被阻塞，直到当前会话释放 `WRITE` 锁。 +- 在 TiDB 中，如果 `LOCK TABLES` 语句需要的锁已被其他会话持有，则该语句会等待，并在执行时返回错误。而在 MySQL 中，该语句会被阻塞，直到获取到锁为止。 +- 在 TiDB 中，`LOCK TABLES` 语句在整个集群范围内生效。而在 MySQL 中，该语句只在当前 MySQL 实例生效，并且不兼容 NDB 集群。 ### 表锁释放 -当在 TiDB 会话中显式开启事务（例如使用 `BEGIN` 语句）时，TiDB 不会隐式释放会话持有的表锁；而 MySQL 会隐式释放表锁。 \ No newline at end of file +当在 TiDB 会话中显式开启事务（例如使用 `BEGIN` 语句）时，TiDB 不会隐式释放该会话持有的表锁；而 MySQL 会隐式释放表锁。 \ No newline at end of file diff --git a/sql-statements/sql-statement-query-watch.md b/sql-statements/sql-statement-query-watch.md index a06f946869a44..26bacbfb6816b 100644 --- a/sql-statements/sql-statement-query-watch.md +++ b/sql-statements/sql-statement-query-watch.md @@ -5,11 +5,11 @@ summary: TiDB 数据库中 QUERY WATCH 的用法概述。 # QUERY WATCH -`QUERY WATCH` 语句用于手动管理资源组中失控查询的监控列表。 +`QUERY WATCH` 语句用于手动管理资源组中异常查询的监控列表。 > **Note:** > -> 此功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 此功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -62,4 +62,4 @@ DropQueryWatchStmt ::= ## 另请参阅 -* [失控查询](/tidb-resource-control-runaway-queries.md) +* [Runaway Queries](/tidb-resource-control-runaway-queries.md) diff --git a/sql-statements/sql-statement-restore.md b/sql-statements/sql-statement-restore.md index d26d746fa2dcc..82e30b7d670d9 100644 --- a/sql-statements/sql-statement-restore.md +++ b/sql-statements/sql-statement-restore.md @@ -5,14 +5,14 @@ summary: TiDB 数据库中 RESTORE 的用法概述。 # RESTORE -该语句用于从之前由 [`BACKUP` 语句](/sql-statements/sql-statement-backup.md) 生成的备份归档中执行分布式恢复操作。 +该语句用于从之前通过 [`BACKUP` 语句](/sql-statements/sql-statement-backup.md) 生成的备份归档中执行分布式恢复。 > **Warning:** > > - 该功能为实验性特性。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下更改或移除。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 -> - 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> - 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 -`RESTORE` 语句使用与 [BR 工具](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview) 相同的引擎，不同之处在于恢复过程由 TiDB 自身驱动，而不是由独立的 BR 工具驱动。BR 的所有优点和注意事项在此同样适用。特别地，**`RESTORE` 目前不符合 ACID**。在运行 `RESTORE` 之前，请确保满足以下要求： +`RESTORE` 语句使用与 [BR 工具](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview) 相同的引擎，不同之处在于恢复过程由 TiDB 自身驱动，而不是单独的 BR 工具。BR 的所有优点和注意事项在此同样适用。特别地，**`RESTORE` 目前不符合 ACID**。在运行 `RESTORE` 之前，请确保满足以下要求： * 集群处于“离线”状态，当前 TiDB 会话是唯一访问所有被恢复表的活跃 SQL 连接。 * 当执行全量恢复时，被恢复的表不应已存在，否则现有数据可能会被覆盖，导致数据与索引之间不一致。 @@ -22,7 +22,7 @@ summary: TiDB 数据库中 RESTORE 的用法概述。 `RESTORE` 语句为阻塞型，只有在整个恢复任务完成、失败或被取消后才会结束。建议为 `RESTORE` 准备一个长时间保持的连接。可以使用 [`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md) 语句取消该任务。 -同一时间只能执行一个 `BACKUP` 或 `RESTORE` 任务。如果同一 TiDB 服务器上已有 `BACKUP` 或 `RESTORE` 任务在运行，新的 `RESTORE` 执行将会等待所有前序任务完成。 +同一时间只能执行一个 `BACKUP` 或 `RESTORE` 任务。如果同一 TiDB 服务器上已有 `BACKUP` 或 `RESTORE` 任务在运行，新的 `RESTORE` 执行会等待所有前置任务完成后再开始。 `RESTORE` 只能用于 "tikv" 存储引擎。若在 "unistore" 引擎下使用 `RESTORE` 会失败。 @@ -68,14 +68,14 @@ RESTORE DATABASE * FROM 'local:///mnt/backup/2020/04/'; 1 row in set (28.961 sec) ``` -在上述示例中，所有数据都从本地文件系统的备份归档中恢复。数据以 SST 文件的形式，从分布在所有 TiDB 和 TiKV 节点的 `/mnt/backup/2020/04/` 目录中读取。 +在上面的示例中，所有数据都从本地文件系统的备份归档中恢复。数据以 SST 文件的形式，从分布在所有 TiDB 和 TiKV 节点的 `/mnt/backup/2020/04/` 目录中读取。 -上述结果的第一行各列说明如下： +上述结果的第一行各列含义如下： -| 列名 | 说明 | +| 列名 | 描述 | | :-------- | :--------- | -| `Destination` | 读取的目标 URL | -| `Size` | 备份归档的总大小，单位为字节 | +| `Destination` | 读取数据的目标 URL | +| `Size` | 备份归档的总大小，单位为字节 | | `BackupTS` | （未使用） | | `Queue Time` | `RESTORE` 任务排队时的时间戳（当前时区） | | `Execution Time` | `RESTORE` 任务开始执行时的时间戳（当前时区） | @@ -105,7 +105,7 @@ RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/'; URL 语法详见 [外部存储服务的 URI 格式](/external-storage-uri.md)。 -在云环境下，如果不希望分发凭证，可以将 `SEND_CREDENTIALS_TO_TIKV` 选项设置为 `FALSE`： +在云环境下运行且不希望分发凭证时，可以将 `SEND_CREDENTIALS_TO_TIKV` 选项设置为 `FALSE`： ```sql @@ -117,9 +117,9 @@ RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/' 使用 `RATE_LIMIT` 可以限制每个 TiKV 节点的平均下载速度，以减少网络带宽占用。 -在恢复完成前，`RESTORE` 默认会对备份文件中的数据进行校验，以验证数据正确性。单表校验任务的默认并发度为 4，你可以通过 `CHECKSUM_CONCURRENCY` 参数进行调整。如果你确信无需数据校验，可以通过将 `CHECKSUM` 参数设置为 `FALSE` 来关闭校验。 +在恢复完成前，`RESTORE` 默认会对备份文件中的数据进行校验，以验证数据正确性。单表校验任务的默认并发度为 4，你可以通过 `CHECKSUM_CONCURRENCY` 参数进行调整。如果你确信无需数据校验，可以将 `CHECKSUM` 参数设置为 `FALSE` 以关闭校验。 -如果统计信息已被备份，恢复时默认会一并恢复。如果你不需要恢复统计信息，可以将 `LOAD_STATS` 参数设置为 `FALSE`。 +如果统计信息已被备份，恢复时默认也会恢复统计信息。如果你不需要恢复统计信息，可以将 `LOAD_STATS` 参数设置为 `FALSE`。 @@ -156,7 +156,7 @@ BACKUP DATABASE `test` TO 's3://example-bucket/inc-backup-1' SNAPSHOT = 41497185 BACKUP DATABASE `test` TO 's3://example-bucket/inc-backup-2' SNAPSHOT = 416353458585600 LAST_BACKUP = 414971854848000; ``` -则恢复时应按相同顺序执行： +则恢复时也应按相同顺序执行： ```sql diff --git a/sql-statements/sql-statement-set-resource-group.md b/sql-statements/sql-statement-set-resource-group.md index e172be8768e24..eab0b74ba984e 100644 --- a/sql-statements/sql-statement-set-resource-group.md +++ b/sql-statements/sql-statement-set-resource-group.md @@ -9,7 +9,7 @@ summary: TiDB 数据库中 SET RESOURCE GROUP 的用法概述。 > **Note:** > -> 此功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -26,7 +26,7 @@ ResourceGroupName ::= ## 权限 -执行该语句需要满足以下配置和权限要求： +执行该语句需要以下配置和权限： 1. 系统变量 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) 设置为 `ON`。 2. 当系统变量 [`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) 设置为 `ON` 时，你需要拥有 `SUPER` 或 `RESOURCE_GROUP_ADMIN` 或 `RESOURCE_GROUP_USER` 权限；当其设置为 `OFF` 时，不需要这些权限。 @@ -92,7 +92,7 @@ SELECT CURRENT_RESOURCE_GROUP(); MySQL 也支持 [SET RESOURCE GROUP](https://dev.mysql.com/doc/refman/8.0/en/set-resource-group.html)。但其接受的参数与 TiDB 不同，二者不兼容。 -## 参考 +## 另请参阅 * [CREATE RESOURCE GROUP](/sql-statements/sql-statement-create-resource-group.md) * [DROP RESOURCE GROUP](/sql-statements/sql-statement-drop-resource-group.md) diff --git a/sql-statements/sql-statement-show-backups.md b/sql-statements/sql-statement-show-backups.md index 9e949f72627c5..03932779a423c 100644 --- a/sql-statements/sql-statement-show-backups.md +++ b/sql-statements/sql-statement-show-backups.md @@ -1,23 +1,23 @@ --- title: SHOW [BACKUPS|RESTORES] | TiDB SQL Statement Reference -summary: An overview of the usage of SHOW [BACKUPS|RESTORES] for the TiDB database. +summary: TiDB 数据库中 SHOW [BACKUPS|RESTORES] 的用法概述。 --- # SHOW [BACKUPS|RESTORES] -These statements show a list of all queued, running and recently finished [`BACKUP`](/sql-statements/sql-statement-backup.md) and [`RESTORE`](/sql-statements/sql-statement-restore.md) tasks that were executed on a TiDB instance. +这些语句会显示在 TiDB 实例上执行的所有已排队、正在运行和最近完成的 [`BACKUP`](/sql-statements/sql-statement-backup.md) 及 [`RESTORE`](/sql-statements/sql-statement-restore.md) 任务的列表。 -Both statements require `SUPER` privilege to run. +这两个语句都需要 `SUPER` 权限才能执行。 -Use `SHOW BACKUPS` to query `BACKUP` tasks and use `SHOW RESTORES` to query `RESTORE` tasks. +使用 `SHOW BACKUPS` 查询 `BACKUP` 任务，使用 `SHOW RESTORES` 查询 `RESTORE` 任务。 > **Note:** > -> This feature is not available on [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) clusters. +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 -Backups and restores that were started with the `br` commandline tool are not shown. +通过 `br` 命令行工具启动的备份和恢复任务不会显示在这里。 -## Synopsis +## 语法 ```ebnf+diagram ShowBRIEStmt ::= @@ -28,19 +28,15 @@ ShowLikeOrWhere ::= | "WHERE" Expression ``` -## Examples +## 示例 -In one connection, execute the following statement: - -{{< copyable "sql" >}} +在一个连接中，执行以下语句： ```sql BACKUP DATABASE `test` TO 's3://example-bucket/backup-01'; ``` -Before the backup completes, run `SHOW BACKUPS` in a new connection: - -{{< copyable "sql" >}} +在备份完成之前，在新的连接中运行 `SHOW BACKUPS`： ```sql SHOW BACKUPS; @@ -55,30 +51,28 @@ SHOW BACKUPS; 1 row in set (0.00 sec) ``` -The first row of the result above is described as follows: +上面结果的第一行各列含义如下： -| Column | Description | +| 列名 | 描述 | | :-------- | :--------- | -| `Destination` | The destination URL (with all parameters stripped to avoid leaking secret keys) | -| `State` | State of the task | -| `Progress` | Estimated progress in the current state as a percentage | -| `Queue_time` | When the task was queued | -| `Execution_time` | When the task was started; the value is `0000-00-00 00:00:00` for queueing tasks | -| `Finish_time` | The timestamp when the task finished; the value is `0000-00-00 00:00:00` for queueing and running tasks | -| `Connection` | Connection ID running this task | -| `Message` | Message with details | - -The possible states are: - -| State | Description | +| `Destination` | 目标 URL（已去除所有参数以避免泄露密钥） | +| `State` | 任务的状态 | +| `Progress` | 当前状态下的预计进度百分比 | +| `Queue_time` | 任务被排队的时间 | +| `Execution_time` | 任务开始执行的时间；对于排队中的任务，该值为 `0000-00-00 00:00:00` | +| `Finish_time` | 任务完成时的时间戳；对于排队和运行中的任务，该值为 `0000-00-00 00:00:00` | +| `Connection` | 执行该任务的连接 ID | +| `Message` | 详细信息 | + +可能的状态有： + +| State | 描述 | | :-----|:------------| -| Backup | Making a backup | -| Wait | Waiting for execution | -| Checksum | Running a checksum operation | - -The connection ID can be used to cancel a backup/restore task via the [`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md) statement. +| Backup | 正在进行备份 | +| Wait | 等待执行 | +| Checksum | 正在执行校验和操作 | -{{< copyable "sql" >}} +你可以使用连接 ID 通过 [`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md) 语句取消备份/恢复任务。 ```sql KILL TIDB QUERY 4; @@ -88,29 +82,25 @@ KILL TIDB QUERY 4; Query OK, 0 rows affected (0.00 sec) ``` -### Filtering +### 过滤 -Use the `LIKE` clause to filter out tasks by matching the destination URL against a wildcard expression. - -{{< copyable "sql" >}} +使用 `LIKE` 子句，通过通配符表达式匹配目标 URL 来筛选任务。 ```sql SHOW BACKUPS LIKE 's3://%'; ``` -Use the `WHERE` clause to filter by columns. - -{{< copyable "sql" >}} +使用 `WHERE` 子句按列进行筛选。 ```sql SHOW BACKUPS WHERE `Progress` < 25.0; ``` -## MySQL compatibility +## MySQL 兼容性 -This statement is a TiDB extension to MySQL syntax. +该语句是 TiDB 对 MySQL 语法的扩展。 -## See also +## 参见 * [BACKUP](/sql-statements/sql-statement-backup.md) -* [RESTORE](/sql-statements/sql-statement-restore.md) +* [RESTORE](/sql-statements/sql-statement-restore.md) \ No newline at end of file diff --git a/sql-statements/sql-statement-show-create-placement-policy.md b/sql-statements/sql-statement-show-create-placement-policy.md index 065eb1ea2328d..974e685bc1169 100644 --- a/sql-statements/sql-statement-show-create-placement-policy.md +++ b/sql-statements/sql-statement-show-create-placement-policy.md @@ -9,7 +9,7 @@ summary: SHOW CREATE PLACEMENT POLICY 在 TiDB 中的用法。 > **Note:** > -> 此功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 diff --git a/sql-statements/sql-statement-show-create-resource-group.md b/sql-statements/sql-statement-show-create-resource-group.md index 06864c238b8d4..8a3928b3da3ee 100644 --- a/sql-statements/sql-statement-show-create-resource-group.md +++ b/sql-statements/sql-statement-show-create-resource-group.md @@ -9,7 +9,7 @@ summary: 了解在 TiDB 中 SHOW CREATE RESOURCE GROUP 的用法。 > **Note:** > -> 该功能在 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 diff --git a/sql-statements/sql-statement-show-placement-for.md b/sql-statements/sql-statement-show-placement-for.md index 066e0575739c6..b8f03a593c1b3 100644 --- a/sql-statements/sql-statement-show-placement-for.md +++ b/sql-statements/sql-statement-show-placement-for.md @@ -7,14 +7,14 @@ summary: SHOW PLACEMENT FOR 在 TiDB 中的用法。 `SHOW PLACEMENT FOR` 总结了所有的放置选项，并以规范形式展示指定表、数据库模式或分区的放置信息。 -> **注意：** +> **Note:** > -> 该功能在 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 该语句返回的结果集中，`Scheduling_State` 字段表示 Placement Driver（PD）在调度放置时的当前进度： -* `PENDING`：PD 尚未开始调度放置。这可能表示放置规则在语义上是正确的，但当前集群无法满足。例如，若 `FOLLOWERS=4`，但只有 3 个 TiKV 节点可作为 follower。 -* `INPROGRESS`：PD 正在调度放置。 +* `PENDING`：PD 尚未开始调度放置。这可能表示放置规则在语义上是正确的，但当前集群无法满足。例如，如果 `FOLLOWERS=4`，但只有 3 个 TiKV 节点可作为 follower。 +* `INPROGRESS`：PD 当前正在调度放置。 * `SCHEDULED`：PD 已成功完成放置调度。 ## 语法 diff --git a/sql-statements/sql-statement-show-placement-labels.md b/sql-statements/sql-statement-show-placement-labels.md index b08ea0295bfb5..9edac119972d7 100644 --- a/sql-statements/sql-statement-show-placement-labels.md +++ b/sql-statements/sql-statement-show-placement-labels.md @@ -9,7 +9,7 @@ summary: SHOW PLACEMENT LABELS 在 TiDB 中的用法。 > **Note:** > -> 该功能在 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -38,7 +38,7 @@ SHOW PLACEMENT LABELS; 该语句是 TiDB 对 MySQL 语法的扩展。 -## 参见 +## 另请参阅 * [Placement Rules in SQL](/placement-rules-in-sql.md) * [SHOW PLACEMENT](/sql-statements/sql-statement-show-placement.md) diff --git a/sql-statements/sql-statement-show-placement.md b/sql-statements/sql-statement-show-placement.md index be5e2fc579c81..650da9f326813 100644 --- a/sql-statements/sql-statement-show-placement.md +++ b/sql-statements/sql-statement-show-placement.md @@ -5,17 +5,17 @@ summary: SHOW PLACEMENT 在 TiDB 中的用法。 # SHOW PLACEMENT -`SHOW PLACEMENT` 汇总了所有来自放置策略（placement policies）的放置选项，并以规范形式展示。 +`SHOW PLACEMENT` 汇总了所有来自 placement policy 的放置选项，并以规范形式展示。 > **Note:** > -> 此功能在 [TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 此功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 -该语句返回的结果集中，`Scheduling_State` 字段表示 Placement Driver（PD）在调度放置过程中的当前进度： +该语句返回的结果集中，`Scheduling_State` 字段表示 Placement Driver（PD）在调度放置规则时的当前进度： -* `PENDING`：PD 尚未开始调度放置。这可能表示放置规则在语义上是正确的，但当前集群无法满足。例如，如果 `FOLLOWERS=4`，但只有 3 个 TiKV 节点可作为 follower。 -* `INPROGRESS`：PD 正在调度放置。 -* `SCHEDULED`：PD 已成功完成放置调度。 +* `PENDING`：PD 尚未开始调度放置规则。这可能表示放置规则在语义上是正确的，但当前集群无法满足。例如，如果 `FOLLOWERS=4`，但只有 3 个 TiKV 节点可作为 follower。 +* `INPROGRESS`：PD 当前正在调度放置规则。 +* `SCHEDULED`：PD 已成功调度放置规则。 ## 语法 diff --git a/sql-statements/sql-statement-show-plugins.md b/sql-statements/sql-statement-show-plugins.md index c21949155abec..3c805fbb6a314 100644 --- a/sql-statements/sql-statement-show-plugins.md +++ b/sql-statements/sql-statement-show-plugins.md @@ -5,11 +5,11 @@ summary: TiDB 数据库中 SHOW PLUGINS 的用法概述。 # SHOW PLUGINS -`SHOW PLUGINS` 用于显示 TiDB 中已安装的所有插件，包括每个插件的状态和版本信息。 +`SHOW PLUGINS` 显示 TiDB 中已安装的所有插件，包括每个插件的状态和版本信息。 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 diff --git a/sql-statements/sql-statement-show-table-regions.md b/sql-statements/sql-statement-show-table-regions.md index de12610695434..bc6db0b000c5f 100644 --- a/sql-statements/sql-statement-show-table-regions.md +++ b/sql-statements/sql-statement-show-table-regions.md @@ -9,7 +9,7 @@ summary: 了解如何在 TiDB 中使用 SHOW TABLE REGIONS。 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法 @@ -31,16 +31,16 @@ TableName ::= 执行 `SHOW TABLE REGIONS` 会返回以下列： * `REGION_ID`：Region 的 ID。 -* `START_KEY`：Region 的起始 key。 -* `END_KEY`：Region 的结束 key。 +* `START_KEY`：Region 的起始键。 +* `END_KEY`：Region 的结束键。 * `LEADER_ID`：Region 的 Leader ID。 -* `LEADER_STORE_ID`：Region Leader 所在的 store（TiKV）ID。 +* `LEADER_STORE_ID`：Region Leader 所在的存储节点（TiKV）的 ID。 * `PEERS`：所有 Region 副本的 ID。 -* `SCATTERING`：Region 是否正在调度。`1` 表示为 true。 -* `WRITTEN_BYTES`：在一个心跳周期内写入该 Region 的数据量估算，单位为字节。 -* `READ_BYTES`：在一个心跳周期内从该 Region 读取的数据量估算，单位为字节。 +* `SCATTERING`：Region 是否正在调度。`1` 表示是。 +* `WRITTEN_BYTES`：在一个心跳周期内写入该 Region 的数据量估算值，单位为字节。 +* `READ_BYTES`：在一个心跳周期内从该 Region 读取的数据量估算值，单位为字节。 * `APPROXIMATE_SIZE(MB)`：Region 内数据的估算量，单位为 MB。 -* `APPROXIMATE_KEYS`：Region 内 key 的估算数量。 +* `APPROXIMATE_KEYS`：Region 内 Key 的估算数量。 @@ -54,7 +54,7 @@ TableName ::= -* `SCHEDULING_STATE`：拥有 placement policy 的 Region 的调度状态。 +* `SCHEDULING_STATE`：带有 placement policy 的 Region 的调度状态。 > **Note:** > @@ -103,7 +103,7 @@ mysql> SHOW TABLE t1 REGIONS; 3 rows in set (0.00 sec) ``` -在上述输出中，`START_KEY` 为 `t_75_r_31717`，`END_KEY` 为 `t_75_r_63434`，表示主键在 `31717` 到 `63434` 之间的数据存储在该 Region 中。前缀 `t_75_` 表示该 Region 属于内部表 ID 为 `75` 的表（`t`）。`START_KEY` 或 `END_KEY` 为空时，分别表示负无穷或正无穷。 +在上述输出中，`START_KEY` 为 `t_75_r_31717` 且 `END_KEY` 为 `t_75_r_63434`，表示主键在 `31717` 到 `63434` 之间的数据存储在该 Region 中。前缀 `t_75_` 表示该 Region 属于内部表 ID 为 `75` 的表（`t`）。`START_KEY` 或 `END_KEY` 为空时，分别表示负无穷或正无穷。 TiDB 会根据需要自动进行 Region 的重新均衡。若需手动均衡，可使用 `SPLIT TABLE REGION` 语句： @@ -128,7 +128,7 @@ mysql> SHOW TABLE t1 REGIONS; 4 rows in set (0.00 sec) ``` -上述输出显示 Region 96 被拆分，创建了新的 Region 98。表中的其他 Region 未受拆分操作影响。可通过输出统计信息确认： +上述输出显示 Region 96 被拆分，新增了 Region 98。表中的其他 Region 未受拆分操作影响。可通过输出统计信息确认： * `TOTAL_SPLIT_REGION` 表示新拆分出的 Region 数量。本例中为 1。 * `SCATTER_FINISH_RATIO` 表示新拆分 Region 的调度完成率。`1.0` 表示所有 Region 均已调度完成。 @@ -155,9 +155,9 @@ mysql> SHOW TABLE t REGIONS; * 表 t 对应 6 个 Region。其中 `102`、`106`、`110`、`114`、`3` 存储行数据，`98` 存储索引数据。 * Region `102` 的 `START_KEY` 和 `END_KEY` 中，`t_43` 表示表前缀和表 ID，`_r` 表示表 t 的记录数据前缀，`_i` 表示索引数据前缀。 * Region `102` 的 `START_KEY` 和 `END_KEY` 表示记录数据范围为 `[-inf, 20000)`。同理，可以计算出 Region (`106`、`110`、`114`、`3`) 的数据存储范围。 -* Region `98` 存储索引数据。表 t 的索引数据起始 key 为 `t_43_i`，该范围属于 Region `98`。 +* Region `98` 存储索引数据。表 t 的索引数据起始键为 `t_43_i`，该范围属于 Region `98`。 -如需查看 store 1 上对应表 t 的 Region，可使用 `WHERE` 子句： +要查看 store 1 上对应表 t 的 Region，可使用 `WHERE` 子句： ```sql test> SHOW TABLE t REGIONS WHERE leader_store_id =1; @@ -168,7 +168,7 @@ test> SHOW TABLE t REGIONS WHERE leader_store_id =1; +-----------+-----------+---------+-----------+-----------------+--------------+------------+---------------+------------+----------------------+------------------+------------------------+------------------+ ``` -使用 `SPLIT TABLE REGION` 可将索引数据拆分为多个 Region。如下例，将表 t 的索引数据 `name` 在 `[a,z]` 范围内拆分为 2 个 Region。 +使用 `SPLIT TABLE REGION` 可以将索引数据拆分为多个 Region。如下例所示，将表 t 的索引数据 `name` 在 `[a,z]` 范围内拆分为 2 个 Region。 ```sql test> SPLIT TABLE t INDEX name BETWEEN ("a") AND ("z") REGIONS 2; diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index 51ada2e4a9dba..2c6073522a17a 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -5,15 +5,15 @@ summary: TiDB 数据库 Split Region 的用法概述。 # Split Region -在 TiDB 中，每创建一张新表，默认会为该表的数据分割出一个 [Region](/tidb-storage.md#region)。这个默认行为由 TiDB 配置文件中的 `split-table` 控制。当该 Region 中的数据超过默认的 Region 大小限制时，Region 会开始自动拆分为两个。 +在 TiDB 中，每创建一张新表，默认会为该表的数据分割出一个 [Region](/tidb-storage.md#region)。这个默认行为由 TiDB 配置文件中的 `split-table` 控制。当该 Region 中的数据超过默认的 Region 大小限制时，该 Region 会被拆分成两个。 -在上述情况下，由于一开始只有一个 Region，所有写入请求都会集中在该 Region 所在的 TiKV 节点上。如果对新建表有大量写入操作，就会导致热点问题。 +在上述情况下，由于一开始只有一个 Region，所有写入请求都会落在该 Region 所在的 TiKV 上。如果对新建表有大量写入操作，就会造成热点问题。 -为了解决上述场景下的热点问题，TiDB 引入了预拆分（pre-split）功能，可以根据指定参数为某张表预先拆分出多个 Region，并将它们分散到各个 TiKV 节点上。 +为了解决上述场景下的热点问题，TiDB 引入了预拆分功能，可以根据指定参数为某张表预先拆分出多个 Region，并将它们分散到各个 TiKV 节点上。 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 ## 语法说明 @@ -42,15 +42,15 @@ RowValue ::= Split Region 语法分为两种类型： -- 均匀拆分的语法： +- 均匀拆分语法： ```sql SPLIT TABLE table_name [INDEX index_name] BETWEEN (lower_value) AND (upper_value) REGIONS region_num ``` - `BETWEEN lower_value AND upper_value REGIONS region_num` 用于定义上边界、下边界和 Region 数量。然后当前 Region 会在上下边界之间，均匀拆分为 `region_num` 个 Region。 + `BETWEEN lower_value AND upper_value REGIONS region_num` 用于定义上下边界和 Region 数量。然后当前 Region 会在上下边界之间，均匀拆分为 `region_num` 个 Region。 -- 非均匀拆分的语法： +- 非均匀拆分语法： ```sql SPLIT TABLE table_name [INDEX index_name] BY (value_list) [, (value_list)] ... @@ -68,17 +68,17 @@ Split Region 语法分为两种类型： +--------------------+----------------------+ ``` -* `TOTAL_SPLIT_REGION`：新拆分出来的 Region 数量。 -* `SCATTER_FINISH_RATIO`：新拆分 Region 的调度完成率。`1.0` 表示所有 Region 已经调度完成，`0.5` 表示只有一半 Region 已经调度完成，剩余的还在调度中。 +* `TOTAL_SPLIT_REGION`：新拆分出的 Region 数量。 +* `SCATTER_FINISH_RATIO`：新拆分 Region 的分散完成率。`1.0` 表示所有 Region 已分散；`0.5` 表示只有一半 Region 已分散，剩余的还在分散中。 > **Note:** > > 以下两个会话变量可能会影响 `SPLIT` 语句的行为： > -> - `tidb_wait_split_region_finish`：Region 的调度可能需要一段时间，具体时长取决于 PD 调度和 TiKV 负载。该变量用于控制执行 `SPLIT REGION` 语句时，是否等到所有 Region 调度完成后再将结果返回给客户端。如果该变量值为 `1`（默认值），TiDB 会在调度完成后才返回结果；如果为 `0`，则无论调度是否完成都会立即返回结果。 -> - `tidb_wait_split_region_timeout`：该变量用于设置 `SPLIT REGION` 语句的执行超时时间，单位为秒，默认值为 300 秒。如果在该时间内拆分操作未完成，TiDB 会返回超时错误。 +> - `tidb_wait_split_region_finish`：Region 分散可能需要一段时间，具体取决于 PD 调度和 TiKV 负载。该变量用于控制执行 `SPLIT REGION` 语句时，是否等所有 Region 分散完成后再将结果返回给客户端。若值为 `1`（默认），TiDB 会在分散完成后返回结果；若值为 `0`，则无论分散是否完成都会立即返回结果。 +> - `tidb_wait_split_region_timeout`：该变量用于设置 `SPLIT REGION` 语句的执行超时时间（单位：秒），默认值为 300 秒。如果在该时间内拆分操作未完成，TiDB 会返回超时错误。 -### 拆分表的 Region +### 拆分表 Region 每张表的行数据的 key 由 `table_id` 和 `row_id` 编码，格式如下： @@ -86,7 +86,7 @@ Split Region 语法分为两种类型： t[table_id]_r[row_id] ``` -例如，当 `table_id` 为 22，`row_id` 为 11 时： +例如，`table_id` 为 22，`row_id` 为 11 时： ```go t22_r11 @@ -96,7 +96,7 @@ t22_r11 #### 均匀拆分 -由于 `row_id` 是整数，可以根据指定的 `lower_value`、`upper_value` 和 `region_num` 计算出需要拆分的 key 值。TiDB 首先计算步长（`step = (upper_value - lower_value)/region_num`），然后在 `lower_value` 和 `upper_value` 之间，每隔一个步长均匀拆分，生成 `region_num` 个 Region。 +由于 `row_id` 是整数，可以根据指定的 `lower_value`、`upper_value` 和 `region_num` 计算出要拆分的 key 值。TiDB 首先计算步长（`step = (upper_value - lower_value)/region_num`），然后在 `lower_value` 和 `upper_value` 之间，每隔一个步长均匀拆分，生成 `region_num` 个 Region。 例如，如果你想将表 t 的 key 范围 `minInt64`~`maxInt64` 均匀拆分为 16 个 Region，可以使用如下语句： @@ -112,7 +112,7 @@ SPLIT TABLE t BETWEEN (0) AND (1000000000) REGIONS 16; #### 非均匀拆分 -如果已知数据分布不均，想要分别在 key 范围 -inf ~ 10000、10000 ~ 90000、90000 ~ +inf 各拆分一个 Region，可以通过设置固定拆分点实现，如下所示： +如果已知数据分布不均，想要分别在 key 范围 -inf ~ 10000、10000 ~ 90000、90000 ~ +inf 拆分 Region，可以通过设置固定拆分点实现，如下所示： ```sql SPLIT TABLE t BY (10000), (90000); @@ -126,7 +126,7 @@ SPLIT TABLE t BY (10000), (90000); t[table_id]_i[index_id][index_value] ``` -例如，当 `table_id` 为 22，`index_id` 为 5，`index_value` 为 abc 时： +例如，`table_id` 为 22，`index_id` 为 5，`index_value` 为 abc 时： ```go t22_i5abc @@ -138,25 +138,25 @@ t22_i5abc 索引的均匀拆分方式与数据的均匀拆分类似。但由于 `index_value` 可能不是整数，步长的计算更为复杂。 -`upper` 和 `lower` 的值首先会被编码为字节数组。去除 `lower` 和 `upper` 字节数组的最长公共前缀后，将剩余部分的前 8 个字节分别转换为 uint64 格式，然后计算 `step = (upper - lower)/num`。之后，将计算得到的步长编码为字节数组，并拼接回最长公共前缀，作为索引拆分点。示例如下： +`upper` 和 `lower` 的值会先编码为字节数组。去除 `lower` 和 `upper` 字节数组的最长公共前缀后，将剩余部分的前 8 个字节分别转为 uint64 格式，然后计算 `step = (upper - lower)/num`。之后，将计算出的步长编码为字节数组，并拼接到 `lower` 和 `upper` 字节数组的最长公共前缀后，用于索引拆分。示例如下： -如果 `idx` 索引的列为整型，可以使用如下 SQL 拆分索引数据： +如果 `idx` 索引的列为整数类型，可以用如下 SQL 拆分索引数据： ```sql SPLIT TABLE t INDEX idx BETWEEN (-9223372036854775808) AND (9223372036854775807) REGIONS 16; ``` -该语句会将表 t 的 idx 索引 Region 从 `minInt64` 到 `maxInt64` 拆分为 16 个 Region。 +该语句会将表 t 的 idx 索引 Region 在 `minInt64` 到 `maxInt64` 之间拆分为 16 个 Region。 -如果 idx1 索引的列为 varchar 类型，想要按前缀字母拆分索引数据： +如果 idx1 索引的列为 varchar 类型，想按前缀字母拆分索引数据： ```sql SPLIT TABLE t INDEX idx1 BETWEEN ("a") AND ("z") REGIONS 25; ``` -该语句会将 idx1 索引从 a~z 拆分为 25 个 Region。Region 1 的范围为 `[minIndexValue, b)`，Region 2 的范围为 `[b, c)`，……，Region 25 的范围为 `[y, minIndexValue]`。对于 idx 索引，前缀为 a 的数据写入 Region 1，前缀为 b 的数据写入 Region 2。 +该语句会将 idx1 索引从 a~z 拆分为 25 个 Region。Region 1 的范围为 `[minIndexValue, b)`，Region 2 的范围为 `[b, c)`，……，Region 25 的范围为 `[y, minIndexValue]`。对于 idx 索引，以 a 为前缀的数据写入 Region 1，以 b 为前缀的数据写入 Region 2。 -在上述拆分方式中，前缀为 y 和 z 的数据都会写入 Region 25，因为上界不是 z，而是 `{`（ASCII 中 z 的下一个字符）。因此，更精确的拆分方式如下： +在上述拆分方式中，y 和 z 前缀的数据都会写入 Region 25，因为上界不是 z，而是 `{`（ASCII 中 z 的下一个字符）。因此，更精确的拆分方式如下： ```sql SPLIT TABLE t INDEX idx1 BETWEEN ("a") AND ("{") REGIONS 26; @@ -164,7 +164,7 @@ SPLIT TABLE t INDEX idx1 BETWEEN ("a") AND ("{") REGIONS 26; 该语句会将表 t 的 idx1 索引从 a~`{` 拆分为 26 个 Region。Region 1 的范围为 `[minIndexValue, b)`，Region 2 的范围为 `[b, c)`，……，Region 25 的范围为 `[y, z)`，Region 26 的范围为 `[z, maxIndexValue)`。 -如果 idx2 索引的列为时间类型（如 timestamp/datetime），想要按年份拆分索引 Region： +如果 idx2 索引的列为时间类型（如 timestamp/datetime），想按年份拆分索引 Region： ```sql SPLIT TABLE t INDEX idx2 BETWEEN ("2010-01-01 00:00:00") AND ("2020-01-01 00:00:00") REGIONS 10; @@ -178,13 +178,13 @@ SPLIT TABLE t INDEX idx2 BETWEEN ("2010-01-01 00:00:00") AND ("2020-01-01 00:00: SPLIT TABLE t INDEX idx2 BETWEEN ("2020-06-01 00:00:00") AND ("2020-07-01 00:00:00") REGIONS 30; ``` -该语句会将表 t 的 idx2 索引 2020 年 6 月的数据拆分为 30 个 Region，每个 Region 表示一天。 +该语句会将表 t 的 idx2 索引 2020 年 6 月的数据拆分为 30 个 Region，每个 Region 代表一天。 其他类型索引列的数据 Region 拆分方式类似。 -对于联合索引的数据 Region 拆分，唯一的区别是可以指定多个列的值。 +对于联合索引的数据 Region 拆分，唯一的区别是可以指定多列的值。 -例如，索引 `idx3 (a, b)` 包含 2 个列，a 为 timestamp 类型，b 为 int。如果只想按 a 列的时间范围拆分，可以使用单列时间索引的拆分 SQL，此时不需要在 `lower_value` 和 `upper_value` 中指定 b 列的值： +例如，索引 `idx3 (a, b)` 包含 2 列，a 为 timestamp 类型，b 为 int。如果只想按 a 列的时间范围拆分，可以使用单列时间索引的拆分 SQL，此时不需要在 `lower_value` 和 `upper_value` 中指定 b 列的值： ```sql SPLIT TABLE t INDEX idx3 BETWEEN ("2010-01-01 00:00:00") AND ("2020-01-01 00:00:00") REGIONS 10; @@ -198,7 +198,7 @@ SPLIT TABLE t INDEX idx3 BETWEEN ("2010-01-01 00:00:00", "a") AND ("2010-01-01 0 该语句会在 a 列为同一时间前缀的情况下，按 b 列的值 a~z 拆分为 10 个 Region。如果 a 列指定的值不同，则 b 列的值可能不会被使用。 -如果表的主键为 [非聚簇索引](/clustered-indexes.md)，在拆分 Region 时需要用反引号 ``` ` ``` 对 `PRIMARY` 关键字进行转义。例如： +如果表的主键为 [非聚簇索引](/clustered-indexes.md)，拆分 Region 时需要用反引号 ``` ` ``` 转义 `PRIMARY` 关键字。例如： ```sql SPLIT TABLE t INDEX `PRIMARY` BETWEEN (-9223372036854775808) AND (9223372036854775807) REGIONS 16; @@ -208,13 +208,13 @@ SPLIT TABLE t INDEX `PRIMARY` BETWEEN (-9223372036854775808) AND (92233720368547 索引数据也可以通过指定的索引值进行拆分。 -例如，有 `idx4 (a,b)`，a 列为 varchar 类型，b 列为 timestamp 类型。 +例如，有 `idx4 (a,b)`，a 为 varchar 类型，b 为 timestamp 类型： ```sql SPLIT TABLE t1 INDEX idx4 BY ("a", "2000-01-01 00:00:01"), ("b", "2019-04-17 14:26:19"), ("c", ""); ``` -该语句指定 3 个值，将数据拆分为 4 个 Region。每个 Region 的范围如下： +该语句指定 3 个值，将拆分为 4 个 Region。每个 Region 的范围如下： ``` region1 [ minIndexValue , ("a", "2000-01-01 00:00:01")) @@ -227,21 +227,21 @@ region4 [("c", "") , maxIndexValue ) 分区表的 Region 拆分方式与普通表相同，唯一的区别是每个分区都会执行相同的拆分操作。 -+ 均匀拆分的语法： ++ 均匀拆分语法： ```sql SPLIT [PARTITION] TABLE t [PARTITION] [(partition_name_list...)] [INDEX index_name] BETWEEN (lower_value) AND (upper_value) REGIONS region_num ``` -+ 非均匀拆分的语法： ++ 非均匀拆分语法： ```sql SPLIT [PARTITION] TABLE table_name [PARTITION (partition_name_list...)] [INDEX index_name] BY (value_list) [, (value_list)] ... ``` -#### 分区表拆分 Region 的示例 +#### 分区表拆分 Region 示例 -1. 创建分区表 t。假设你要创建一张 Hash 分区表，分为两个分区，示例如下： +1. 创建分区表 t。假设要创建一张 Hash 表，分为两个分区，示例如下： ```sql CREATE TABLE t (a INT, b INT, INDEX idx(a)) PARTITION BY HASH(a) PARTITIONS 2; @@ -262,17 +262,17 @@ region4 [("c", "") , maxIndexValue ) +-----------+-----------+---------+-----------+-----------------+------------------+------------+---------------+------------+----------------------+------------------+ ``` -2. 使用 `SPLIT` 语法为每个分区拆分 Region。假设你想将每个分区 `[0,10000]` 范围的数据拆分为 4 个 Region，示例如下： +2. 使用 `SPLIT` 语法为每个分区拆分 Region。假设要将每个分区 `[0,10000]` 范围的数据拆分为 4 个 Region，示例如下： ```sql split partition table t between (0) and (10000) regions 4; ``` - 在上述语句中，`0` 和 `10000` 分别代表你想要分散的热点数据的上下边界 `row_id`。 + 上述语句中，`0` 和 `10000` 分别代表你想要分散的热点数据的上下边界 `row_id`。 > **Note:** > - > 此示例仅适用于热点数据均匀分布的场景。如果热点数据在指定数据范围内分布不均，请参考 [拆分分区表 Region](#split-regions-for-partitioned-tables) 中的非均匀拆分语法。 + > 此示例仅适用于热点数据均匀分布的场景。如果热点数据在指定数据范围内分布不均，请参考 [分区表拆分 Region](#split-regions-for-partitioned-tables) 中的非均匀拆分语法。 3. 再次使用 `SHOW TABLE REGIONS` 语法查看该表的 Region，可以看到该表现在有 10 个 Region，每个分区有 5 个 Region，其中 4 个为行数据，1 个为索引数据。 @@ -303,11 +303,11 @@ region4 [("c", "") , maxIndexValue ) SPLIT PARTITION TABLE t INDEX idx BETWEEN (1000) AND (10000) REGIONS 2; ``` -#### 单个分区拆分 Region 的示例 +#### 单个分区拆分 Region 示例 你可以指定要拆分的分区。 -1. 创建分区表。假设你要创建一张 Range 分区表，分为 3 个分区，示例如下： +1. 创建分区表。假设要创建一张 Range 分区表，分为 3 个分区，示例如下： ```sql CREATE TABLE t ( a INT, b INT, INDEX idx(b)) PARTITION BY RANGE( a ) ( @@ -316,19 +316,19 @@ region4 [("c", "") , maxIndexValue ) PARTITION p3 VALUES LESS THAN (MAXVALUE) ); ``` -2. 假设你想将 p1 分区 `[0,10000]` 范围的数据拆分为 2 个 Region，示例如下： +2. 假设要将 `p1` 分区 `[0,10000]` 范围的数据拆分为 2 个 Region，示例如下： ```sql SPLIT PARTITION TABLE t PARTITION (p1) BETWEEN (0) AND (10000) REGIONS 2; ``` -3. 假设你想将 p2 分区 `[10000,20000]` 范围的数据拆分为 2 个 Region，示例如下： +3. 假设要将 `p2` 分区 `[10000,20000]` 范围的数据拆分为 2 个 Region，示例如下： ```sql SPLIT PARTITION TABLE t PARTITION (p2) BETWEEN (10000) AND (20000) REGIONS 2; ``` -4. 你可以使用 `SHOW TABLE REGIONS` 语法查看该表的 Region： +4. 可以使用 `SHOW TABLE REGIONS` 语法查看该表的 Region： ```sql SHOW TABLE t REGIONS; @@ -346,7 +346,7 @@ region4 [("c", "") , maxIndexValue ) +-----------+----------------+----------------+-----------+-----------------+------------------+------------+---------------+------------+----------------------+------------------+ ``` -5. 假设你想将 p1 和 p2 分区的 `idx` 索引 `[0,20000]` 范围拆分为 2 个 Region，示例如下： +5. 假设要将 `p1` 和 `p2` 分区的 `idx` 索引 `[0,20000]` 范围拆分为 2 个 Region，示例如下： ```sql SPLIT PARTITION TABLE t PARTITION (p1,p2) INDEX idx BETWEEN (0) AND (20000) REGIONS 2; @@ -360,7 +360,7 @@ region4 [("c", "") , maxIndexValue ) > > `PRE_SPLIT_REGIONS` 的值必须小于等于 `SHARD_ROW_ID_BITS` 或 `AUTO_RANDOM` 的值。 -[`tidb_scatter_region`](/system-variables.md#tidb_scatter_region) 全局变量会影响 `PRE_SPLIT_REGIONS` 的行为。该变量用于控制建表后是否等待 Region 预拆分并调度完成后再返回结果。如果建表后有大量写入操作，需要将该变量设置为 `global`，这样 TiDB 会根据整个集群的数据分布调度新建表的 Region。否则，TiDB 会在调度未完成前写入数据，可能会对写入性能产生较大影响。 +[`tidb_scatter_region`](/system-variables.md#tidb_scatter_region) 全局变量会影响 `PRE_SPLIT_REGIONS` 的行为。该变量用于控制建表后是否等待 Region 预拆分并分散完成再返回结果。如果建表后有大量写入操作，需要将该变量设置为 `global`，此时 TiDB 会根据整个集群的数据分布分散新建表的 Region。否则，TiDB 会在分散未完成时写入数据，这会对写入性能产生较大影响。 ### pre_split_regions 示例 @@ -383,7 +383,7 @@ region4: [ 3<<61 , +inf ) > **Note:** > -> 通过 Split Region 语句拆分出来的 Region 受 PD 中 [Region merge](/best-practices/pd-scheduling-best-practices.md#region-merge) 调度器控制。为避免 PD 在拆分后很快将新拆分的 Region 合并，需要使用 [表属性](/table-attributes.md) 或 [动态修改](/pd-control.md) 与 Region merge 相关的配置项。 +> 通过 Split Region 语句拆分出的 Region 受 PD 中 [Region merge](/best-practices/pd-scheduling-best-practices.md#region-merge) 调度器控制。为避免 PD 在拆分后很快重新合并新拆分的 Region，需要使用 [表属性](/table-attributes.md) 或 [动态修改](/pd-control.md) 与 Region merge 相关的配置项。 @@ -391,7 +391,7 @@ region4: [ 3<<61 , +inf ) 该语句是 TiDB 对 MySQL 语法的扩展。 -## 参考 +## 另请参阅 * [SHOW TABLE REGIONS](/sql-statements/sql-statement-show-table-regions.md) -* 会话变量：[`tidb_scatter_region`](/system-variables.md#tidb_scatter_region)、[`tidb_wait_split_region_finish`](/system-variables.md#tidb_wait_split_region_finish) 和 [`tidb_wait_split_region_timeout`](/system-variables.md#tidb_wait_split_region_timeout) \ No newline at end of file +* 会话变量：[tidb_scatter_region](/system-variables.md#tidb_scatter_region)、[tidb_wait_split_region_finish](/system-variables.md#tidb_wait_split_region_finish) 和 [tidb_wait_split_region_timeout](/system-variables.md#tidb_wait_split_region_timeout) \ No newline at end of file diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 562a3ceaceedb..274a645df6de9 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -3,9 +3,9 @@ title: Statement Summary Tables summary: 了解 TiDB 中的语句概要表。 --- -# 语句概要表 +# 语句概要表（Statement Summary Tables） -为更好地处理 SQL 性能问题，MySQL 在 `performance_schema` 中提供了 [statement summary tables](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html)（语句概要表），用于通过统计信息监控 SQL。在这些表中，`events_statements_summary_by_digest` 表通过其丰富的字段（如延迟、执行次数、扫描行数、全表扫描等）在定位 SQL 问题时非常有用。 +为更好地处理 SQL 性能问题，MySQL 在 `performance_schema` 中提供了 [statement summary tables](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html)（语句概要表），用于通过统计信息监控 SQL。在这些表中，`events_statements_summary_by_digest` 非常有助于定位 SQL 问题，因为它包含了丰富的字段，如延迟、执行次数、扫描行数和全表扫描等。 因此，从 v4.0.0-rc.1 版本开始，TiDB 在 `information_schema`（**不是** `performance_schema`）中提供了与 `events_statements_summary_by_digest` 功能类似的系统表。 @@ -15,32 +15,32 @@ summary: 了解 TiDB 中的语句概要表。 - [`cluster_statements_summary_history`](#statements_summary_evicted) - [`statements_summary_evicted`](#statements_summary_evicted) -> **Note:** +> **注意：** > -> 上述表在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 +> 上述表在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 -本文档详细介绍了这些表，并介绍如何使用它们来排查 SQL 性能问题。 +本文档将详细介绍这些表，并说明如何使用它们来排查 SQL 性能问题。 ## `statements_summary` -`statements_summary` 是 `information_schema` 下的一个系统表。`statements_summary` 按资源组、SQL 摘要（digest）和执行计划摘要（plan digest）对 SQL 语句进行分组，并为每类 SQL 提供统计信息。 +`statements_summary` 是 `information_schema` 中的一个系统表。`statements_summary` 按资源组、SQL 摘要（digest）和执行计划摘要（plan digest）对 SQL 语句进行分组，并为每类 SQL 提供统计信息。 -这里的 “SQL 摘要” 与慢日志中的含义一致，是通过标准化 SQL 语句计算得到的唯一标识。标准化过程会忽略常量、空白字符，并且不区分大小写。因此，语法一致的语句会有相同的摘要。例如： +这里的 “SQL 摘要” 与慢日志中使用的含义相同，是通过规范化 SQL 语句计算出的唯一标识。规范化过程会忽略常量、空白字符，并且不区分大小写。因此，语法一致的语句具有相同的摘要。例如： ```sql SELECT * FROM employee WHERE id IN (1, 2, 3) AND salary BETWEEN 1000 AND 2000; select * from EMPLOYEE where ID in (4, 5) and SALARY between 3000 and 4000; ``` -标准化后，它们都属于如下类别： +规范化后，它们都属于如下类别： ```sql select * from employee where id in (...) and salary between ? and ?; ``` -“执行计划摘要”是指通过标准化执行计划计算得到的唯一标识。标准化过程会忽略常量。相同的 SQL 语句可能会因为执行计划不同而被分到不同的类别。属于同一类别的 SQL 语句具有相同的执行计划。 +“执行计划摘要”是指通过规范化执行计划计算出的唯一标识。规范化过程会忽略常量。相同的 SQL 语句可能会因为执行计划不同而被分到不同的类别。属于同一类别的 SQL 语句具有相同的执行计划。 -`statements_summary` 存储了 SQL 监控指标的聚合结果。一般来说，每个监控指标都包含最大值和平均值。例如，执行延迟指标对应两个字段：`AVG_LATENCY`（平均延迟）和 `MAX_LATENCY`（最大延迟）。 +`statements_summary` 存储了 SQL 监控指标的聚合结果。通常，每个监控指标都包含最大值和平均值。例如，执行延迟指标对应两个字段：`AVG_LATENCY`（平均延迟）和 `MAX_LATENCY`（最大延迟）。 为保证监控指标的实时性，`statements_summary` 表中的数据会定期清理，仅保留和展示最近的聚合结果。定期清理数据的周期由系统变量 `tidb_stmt_summary_refresh_interval` 控制。如果你在清理后立即查询，显示的数据可能会很少。 @@ -79,7 +79,7 @@ select * from employee where id in (...) and salary between ? and ?; PLAN: Point_Get_1 root 1 table:employee, handle:3100 ``` -> **Note:** +> **注意：** > > - 在 TiDB 中，语句概要表中各字段的时间单位为纳秒（ns），而在 MySQL 中为皮秒（ps）。 > - 从 v7.5.1 和 v7.6.0 开始，对于启用了 [资源管控](/tidb-resource-control-ru-groups.md) 的集群，`statements_summary` 会按资源组进行聚合，例如，相同语句在不同资源组下执行会被收集为不同的记录。 @@ -92,17 +92,17 @@ select * from employee where id in (...) and salary between ? and ?; ## `statements_summary_evicted` -[`tidb_stmt_summary_max_stmt_count`](/system-variables.md#tidb_stmt_summary_max_stmt_count-new-in-v40) 系统变量限制了 `statements_summary` 和 `statements_summary_history` 两张表在内存中总共能存储的 SQL 摘要数量。当超过该限制时，TiDB 会从 `statements_summary` 和 `statements_summary_history` 表中淘汰最久未使用的 SQL 摘要。 +[`tidb_stmt_summary_max_stmt_count`](/system-variables.md#tidb_stmt_summary_max_stmt_count-new-in-v40) 系统变量限制了 `statements_summary` 和 `statements_summary_history` 两个表在内存中总共能存储的 SQL 摘要数量。当超过该限制时，TiDB 会从 `statements_summary` 和 `statements_summary_history` 表中淘汰最久未使用的 SQL 摘要。 -> **Note:** +> **注意：** > -> 当启用 [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary) 后，`statements_summary_history` 表中的数据会持久化到磁盘。此时，`tidb_stmt_summary_max_stmt_count` 只限制 `statements_summary` 表在内存中能存储的 SQL 摘要数量，超出时 TiDB 只会从 `statements_summary` 表中淘汰最久未使用的 SQL 摘要。 +> 当启用 [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary) 后，`statements_summary_history` 表中的数据会持久化到磁盘。此时，`tidb_stmt_summary_max_stmt_count` 只限制 `statements_summary` 表在内存中能存储的 SQL 摘要数量，超出限制时 TiDB 只会从 `statements_summary` 表中淘汰最久未使用的 SQL 摘要。 -`statements_summary_evicted` 表记录了发生淘汰的时间段以及该时间段内被淘汰的 SQL 摘要数量。该表可以帮助你评估 `tidb_stmt_summary_max_stmt_count` 是否配置合理。如果该表有记录，说明某一时刻 SQL 摘要数量超过了 `tidb_stmt_summary_max_stmt_count`。 +`statements_summary_evicted` 表记录了发生淘汰的时间段以及该时间段内被淘汰的 SQL 摘要数量。该表有助于你评估 `tidb_stmt_summary_max_stmt_count` 是否配置合理。如果该表有记录，说明某一时刻 SQL 摘要数量超过了 `tidb_stmt_summary_max_stmt_count`。 @@ -126,17 +126,17 @@ select * from employee where id in (...) and salary between ? and ?; 以下系统变量用于控制语句概要功能： -- `tidb_enable_stmt_summary`：是否开启语句概要功能。`1` 表示开启，`0` 表示关闭。默认开启。关闭后系统表中的统计信息会被清空；下次开启时会重新统计。测试表明开启该功能对性能影响很小。 +- `tidb_enable_stmt_summary`：是否启用语句概要功能。`1` 表示启用，`0` 表示禁用。默认启用。禁用后系统表中的统计信息会被清空；下次启用时会重新统计。测试表明启用该功能对性能影响很小。 - `tidb_stmt_summary_refresh_interval`：`statements_summary` 表的刷新周期，单位为秒（s），默认值为 `1800`。 - `tidb_stmt_summary_history_size`：`statements_summary_history` 表中每类 SQL 语句存储的历史周期数，也是 `statements_summary_evicted` 表的最大记录数。默认值为 `24`。 -- `tidb_stmt_summary_max_stmt_count`：限制 `statements_summary` 和 `statements_summary_history` 两张表在内存中总共能存储的 SQL 摘要数量。默认值为 `3000`。 +- `tidb_stmt_summary_max_stmt_count`：限制 `statements_summary` 和 `statements_summary_history` 两个表在内存中总共能存储的 SQL 摘要数量。默认值为 `3000`。 - 当超过该限制时，TiDB 会从 `statements_summary` 和 `statements_summary_history` 表中淘汰最久未使用的 SQL 摘要。这些被淘汰的摘要会被计入 [`statements_summary_evicted`](#statements_summary_evicted) 表。 + 超过该限制后，TiDB 会从 `statements_summary` 和 `statements_summary_history` 表中淘汰最久未使用的 SQL 摘要。被淘汰的摘要会计入 [`statements_summary_evicted`](#statements_summary_evicted) 表。 - > **Note:** + > **注意：** > - > - 当某个 SQL 摘要被淘汰时，其所有时间段相关的概要数据会从 `statements_summary` 和 `statements_summary_history` 表中移除。因此，即使某个时间段内 SQL 摘要数量未超限，`statements_summary_history` 表中的 SQL 摘要数量也可能小于实际数量。如果出现这种情况且影响性能，建议适当增大 `tidb_stmt_summary_max_stmt_count` 的值。 - > - 对于 TiDB 自建集群，当启用 [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary) 后，`statements_summary_history` 表中的数据会持久化到磁盘。此时，`tidb_stmt_summary_max_stmt_count` 只限制 `statements_summary` 表在内存中能存储的 SQL 摘要数量，超出时 TiDB 只会从 `statements_summary` 表中淘汰最久未使用的 SQL 摘要。 + > - 当某个 SQL 摘要被淘汰时，其所有时间段的相关概要数据都会从 `statements_summary` 和 `statements_summary_history` 表中移除。因此，即使某个时间段内 SQL 摘要数量未超限，`statements_summary_history` 表中的 SQL 摘要数量也可能小于实际数量。如果出现这种情况且影响性能，建议适当增大 `tidb_stmt_summary_max_stmt_count` 的值。 + > - 对于 TiDB 自建集群，当启用 [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary) 后，`statements_summary_history` 表中的数据会持久化到磁盘。此时，`tidb_stmt_summary_max_stmt_count` 只限制 `statements_summary` 表在内存中能存储的 SQL 摘要数量，超出限制时 TiDB 只会从 `statements_summary` 表中淘汰最久未使用的 SQL 摘要。 - `tidb_stmt_summary_max_sql_length`：指定 `DIGEST_TEXT` 和 `QUERY_SAMPLE_TEXT` 的最大显示长度。默认值为 `4096`。 - `tidb_stmt_summary_internal_query`：是否统计 TiDB 内部 SQL 语句。`1` 表示统计，`0` 表示不统计。默认值为 `0`。 @@ -152,9 +152,9 @@ set global tidb_stmt_summary_history_size = 24; 上述配置生效后，`statements_summary` 表每 30 分钟清空一次，`statements_summary_history` 表最多存储 3000 种 SQL 类型，每种类型保留最近 24 个周期的数据。`statements_summary_evicted` 表记录最近 24 个周期内被淘汰的 SQL 语句，且每 30 分钟更新一次。 -> **Note:** +> **注意：** > -> - 如果某类 SQL 每分钟出现一次，`statements_summary_history` 会保留最近 12 小时的数据。如果某类 SQL 只在每天 00:00 到 00:30 出现一次，则 `statements_summary_history` 会以 1 天为一个周期，保留最近 24 天的数据。 +> - 如果某类 SQL 每分钟出现一次，`statements_summary_history` 会保留最近 12 小时的数据。如果某类 SQL 只在每天 00:00 到 00:30 出现一次，`statements_summary_history` 会保留最近 24 个周期的数据，每个周期为 1 天，因此会保留最近 24 天的数据。 > - `tidb_stmt_summary_history_size`、`tidb_stmt_summary_max_stmt_count` 和 `tidb_stmt_summary_max_sql_length` 配置项会影响内存使用量。建议根据实际需求、SQL 大小、SQL 数量和机器配置合理调整，不建议设置过大。可通过 `tidb_stmt_summary_history_size` \* `tidb_stmt_summary_max_stmt_count` \* `tidb_stmt_summary_max_sql_length` \* `3` 计算内存占用。 ### 设置合适的语句概要表大小 @@ -182,7 +182,7 @@ select count(*) from information_schema.statements_summary; 1 row in set (0.001 sec) ``` -可以看到 `statements_summary` 表已满。接着可以通过 `statements_summary_evicted` 表查看被淘汰的数据： +可以看到 `statements_summary` 表已满。接着查询 `statements_summary_evicted` 表中的淘汰数据： ```sql select * from information_schema.statements_summary_evicted; @@ -199,7 +199,7 @@ select * from information_schema.statements_summary_evicted; 2 row in set (0.001 sec) ``` -从上述结果可以看到，最多有 59 种 SQL 类型被淘汰。此时建议将 `statement_summary` 表的大小至少增加 59 条记录，即增大到至少 3059 条。 +从上述结果可以看出，最多有 59 种 SQL 类型被淘汰。此时建议将 `statement_summary` 表的大小至少增加 59 条记录，即增大到至少 3059 条。 ## 限制 @@ -207,7 +207,7 @@ select * from information_schema.statements_summary_evicted; -为解决该问题，TiDB v6.6.0 实验性引入了 [语句概要持久化](#persist-statements-summary) 功能，默认关闭。开启后，历史数据不再保存在内存中，而是直接写入磁盘。这样即使 TiDB 实例重启，历史数据依然可用。 +为解决该问题，TiDB v6.6.0 实验性引入了 [语句概要持久化](#persist-statements-summary) 功能，默认关闭。启用后，历史数据不再保存在内存中，而是直接写入磁盘。这样即使 TiDB 实例重启，历史数据依然可用。 @@ -219,9 +219,9 @@ select * from information_schema.statements_summary_evicted; -> **Warning:** +> **警告：** > -> 语句概要持久化为实验性功能。不建议在生产环境中使用。该功能可能会在未来的版本中变更或移除，恕不另行通知。如发现 bug，可在 GitHub 提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 语句概要持久化为实验性功能。不建议在生产环境中使用。该功能可能会在未来的版本中变更或移除，且不会提前通知。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -235,7 +235,7 @@ select * from information_schema.statements_summary_evicted; -要开启语句概要持久化，可以在 TiDB 配置文件中添加如下配置项： +要启用语句概要持久化，可以在 TiDB 配置文件中添加如下配置项： ```toml [instance] @@ -247,18 +247,18 @@ tidb_stmt_summary_enable_persistent = true # tidb_stmt_summary_file_max_backups = 0 ``` -开启语句概要持久化后，内存中只保留当前实时数据，不再保留历史数据。每当实时数据被刷新为历史数据时，会按照 [参数配置](#parameter-configuration) 中的 `tidb_stmt_summary_refresh_interval` 间隔写入磁盘。查询 `statements_summary_history` 或 `cluster_statements_summary_history` 表时，会返回内存和磁盘上的数据合并结果。 +启用语句概要持久化后，内存中只保留当前实时数据，不再保留历史数据。每当实时数据刷新为历史数据时，会按照 [参数配置](#parameter-configuration) 一节中 `tidb_stmt_summary_refresh_interval` 的周期写入磁盘。查询 `statements_summary_history` 或 `cluster_statements_summary_history` 表时，会返回内存和磁盘上的数据合并结果。 -> **Note:** +> **注意：** > -> - 开启语句概要持久化后，[参数配置](#parameter-configuration) 中的 `tidb_stmt_summary_history_size` 配置项将不再生效，因为内存中不再保留历史数据。此时，持久化历史数据的保留周期和大小由以下三个配置项控制：[`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660)、[`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660) 和 [`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-new-in-v660)。 +> - 启用语句概要持久化后，[参数配置](#parameter-configuration) 一节中的 `tidb_stmt_summary_history_size` 配置项将不再生效，因为内存中不再保留历史数据。此时，持久化历史数据的保留周期和大小由以下三个配置项控制：[`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660)、[`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660) 和 [`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-new-in-v660)。 > - `tidb_stmt_summary_refresh_interval` 的值越小，数据写入磁盘的实时性越高，但也会导致更多冗余数据写入磁盘。 -## 排查示例 +## 故障排查示例 本节通过两个示例说明如何利用语句概要功能排查 SQL 性能问题。 @@ -272,7 +272,7 @@ SELECT avg_latency, exec_count, query_sample_text WHERE digest_text LIKE 'select * from employee%'; ``` -`1ms` 和 `0.3ms` 的 `avg_latency` 属于正常范围，因此可以判断服务端不是慢的原因。你可以继续排查客户端或网络问题。 +`1ms` 和 `0.3ms` 的 `avg_latency` 属于正常范围，因此可以判断不是服务端原因。你可以继续排查客户端或网络问题。 ```sql +-------------+------------+------------------------------------------+ @@ -319,10 +319,10 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text - `STMT_TYPE`：SQL 语句类型。 - `SCHEMA_NAME`：该类别 SQL 语句执行时的当前 schema。 - `DIGEST`：该类别 SQL 语句的摘要。 -- `DIGEST_TEXT`：标准化后的 SQL 语句。 +- `DIGEST_TEXT`：规范化后的 SQL 语句。 - `QUERY_SAMPLE_TEXT`：该类别 SQL 语句的原始 SQL，仅取一条。 -- `TABLE_NAMES`：SQL 涉及的所有表，多个表用逗号分隔。 -- `INDEX_NAMES`：SQL 涉及的所有索引，多个索引用逗号分隔。 +- `TABLE_NAMES`：SQL 语句涉及的所有表，多个表用逗号分隔。 +- `INDEX_NAMES`：SQL 语句使用的所有索引，多个索引用逗号分隔。 - `SAMPLE_USER`：执行该类别 SQL 语句的用户，仅取一个。 - `PLAN_DIGEST`：执行计划的摘要。 - `PLAN`：原始执行计划，若有多条语句，仅取一条的计划。 @@ -358,7 +358,7 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text - `MAX_MEM`：最大使用内存（字节）。 - `AVG_DISK`：平均使用磁盘空间（字节）。 - `MAX_DISK`：最大使用磁盘空间（字节）。 -- `AVG_TIDB_CPU_TIME`：该类别 SQL 语句在 TiDB 实例上消耗的平均 CPU 时间。仅在开启 [Top SQL](/dashboard/top-sql.md) 功能时有意义，否则值为 `0`。 +- `AVG_TIDB_CPU_TIME`：该类别 SQL 语句在 TiDB 实例上消耗的平均 CPU 时间。仅在启用 [Top SQL](/dashboard/top-sql.md) 功能时有意义，否则值始终为 `0`。 @@ -381,7 +381,7 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text - `MAX_MEM`：最大使用内存（字节）。 - `AVG_DISK`：平均使用磁盘空间（字节）。 - `MAX_DISK`：最大使用磁盘空间（字节）。 -- `AVG_TIDB_CPU_TIME`：该类别 SQL 语句在 TiDB 实例上消耗的平均 CPU 时间。仅在开启 Top SQL 功能时有意义，否则值为 `0`。 +- `AVG_TIDB_CPU_TIME`：该类别 SQL 语句在 TiDB 实例上消耗的平均 CPU 时间。仅在启用 Top SQL 功能时有意义，否则值始终为 `0`。 @@ -400,22 +400,22 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text - `MAX_BACKOFF_TIME`：SQL 遇到需重试错误时的最大等待时间。 - `AVG_TOTAL_KEYS`：Coprocessor 扫描的平均 key 数量。 - `MAX_TOTAL_KEYS`：Coprocessor 扫描的最大 key 数量。 -- `AVG_PROCESSED_KEYS`：Coprocessor 处理的平均 key 数量。与 `avg_total_keys` 相比，`avg_processed_keys` 不包含 MVCC 的旧版本。如果两者差异较大，说明存在大量旧版本。 -- `MAX_PROCESSED_KEYS`：Coprocessor 处理的最大 key 数量。 +- `AVG_PROCESSED_KEYS`：Coprocessor 实际处理的平均 key 数量。与 `avg_total_keys` 相比，`avg_processed_keys` 不包含 MVCC 的旧版本。如果两者差异较大，说明存在大量旧版本。 +- `MAX_PROCESSED_KEYS`：Coprocessor 实际处理的最大 key 数量。 - `AVG_TIKV_CPU_TIME`：该类别 SQL 语句在 TiKV 实例上消耗的平均 CPU 时间。 与事务相关的字段： - `AVG_PREWRITE_TIME`：预写阶段的平均耗时。 -- `MAX_PREWRITE_TIME`：预写阶段的最大耗时。 +- `MAX_PREWRITE_TIME`：预写阶段的最长耗时。 - `AVG_COMMIT_TIME`：提交阶段的平均耗时。 -- `MAX_COMMIT_TIME`：提交阶段的最大耗时。 +- `MAX_COMMIT_TIME`：提交阶段的最长耗时。 - `AVG_GET_COMMIT_TS_TIME`：获取 `commit_ts` 的平均耗时。 -- `MAX_GET_COMMIT_TS_TIME`：获取 `commit_ts` 的最大耗时。 +- `MAX_GET_COMMIT_TS_TIME`：获取 `commit_ts` 的最长耗时。 - `AVG_COMMIT_BACKOFF_TIME`：提交阶段遇到需重试错误时的平均等待时间。 - `MAX_COMMIT_BACKOFF_TIME`：提交阶段遇到需重试错误时的最大等待时间。 - `AVG_RESOLVE_LOCK_TIME`：事务间锁冲突的平均解决时间。 -- `MAX_RESOLVE_LOCK_TIME`：事务间锁冲突的最大解决时间。 +- `MAX_RESOLVE_LOCK_TIME`：事务间锁冲突的最长解决时间。 - `AVG_LOCAL_LATCH_WAIT_TIME`：本地事务的平均等待时间。 - `MAX_LOCAL_LATCH_WAIT_TIME`：本地事务的最大等待时间。 - `AVG_WRITE_KEYS`：平均写入 key 数量。 @@ -427,22 +427,22 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text - `AVG_TXN_RETRY`：事务平均重试次数。 - `MAX_TXN_RETRY`：事务最大重试次数。 - `SUM_BACKOFF_TIMES`：该类别 SQL 语句遇到需重试错误的总重试次数。 -- `BACKOFF_TYPES`：所有需重试错误类型及各类型的重试次数。字段格式为 `type:number`，多个类型用逗号分隔，如 `txnLock:2,pdRPC:1`。 +- `BACKOFF_TYPES`：所有需重试的错误类型及各类型的重试次数。字段格式为 `type:number`，多个类型用逗号分隔，如 `txnLock:2,pdRPC:1`。 - `AVG_AFFECTED_ROWS`：平均影响行数。 -- `PREV_SAMPLE_TEXT`：当前 SQL 为 `COMMIT` 时，`PREV_SAMPLE_TEXT` 为上一个语句。此时，SQL 会按摘要和 `prev_sample_text` 分组，即不同 `prev_sample_text` 的 `COMMIT` 语句会分到不同行。当前 SQL 不是 `COMMIT` 时，`PREV_SAMPLE_TEXT` 为空字符串。 +- `PREV_SAMPLE_TEXT`：当前 SQL 为 `COMMIT` 时，`PREV_SAMPLE_TEXT` 为上一个 SQL 语句。此时，SQL 语句按摘要和 `prev_sample_text` 分组，即不同 `prev_sample_text` 的 `COMMIT` 语句会分到不同行。当前 SQL 不是 `COMMIT` 时，`PREV_SAMPLE_TEXT` 为空字符串。 与资源管控相关的字段： -- `AVG_REQUEST_UNIT_WRITE`：SQL 平均消耗的写 RU 数量。 -- `MAX_REQUEST_UNIT_WRITE`：SQL 最大消耗的写 RU 数量。 -- `AVG_REQUEST_UNIT_READ`：SQL 平均消耗的读 RU 数量。 -- `MAX_REQUEST_UNIT_READ`：SQL 最大消耗的读 RU 数量。 -- `AVG_QUEUED_RC_TIME`：SQL 等待可用 RU 的平均时间。 -- `MAX_QUEUED_RC_TIME`：SQL 等待可用 RU 的最大时间。 -- `RESOURCE_GROUP`：SQL 绑定的资源组。 +- `AVG_REQUEST_UNIT_WRITE`：SQL 语句消耗的平均写入 RU 数量。 +- `MAX_REQUEST_UNIT_WRITE`：SQL 语句消耗的最大写入 RU 数量。 +- `AVG_REQUEST_UNIT_READ`：SQL 语句消耗的平均读取 RU 数量。 +- `MAX_REQUEST_UNIT_READ`：SQL 语句消耗的最大读取 RU 数量。 +- `AVG_QUEUED_RC_TIME`：SQL 语句执行时等待可用 RU 的平均时间。 +- `MAX_QUEUED_RC_TIME`：SQL 语句执行时等待可用 RU 的最大时间。 +- `RESOURCE_GROUP`：SQL 语句绑定的资源组。 ### `statements_summary_evicted` 字段说明 - `BEGIN_TIME`：记录起始时间。 - `END_TIME`：记录结束时间。 -- `EVICTED_COUNT`：该周期内被淘汰的 SQL 类型数量。 \ No newline at end of file +- `EVICTED_COUNT`：该记录周期内被淘汰的 SQL 类型数量。 \ No newline at end of file diff --git a/statistics.md b/statistics.md index 0c884aa5939a9..21e288aeb95d8 100644 --- a/statistics.md +++ b/statistics.md @@ -5,7 +5,7 @@ summary: 学习统计信息如何收集表级和列级信息。 # 统计信息简介 -TiDB 使用统计信息作为优化器的输入，用于估算 SQL 语句每个执行计划步骤中处理的行数。优化器会估算每个可用执行计划的成本，包括 [索引访问](/choose-index.md) 和表连接的顺序，并为每个可用计划生成一个成本值。然后，优化器选择总体成本最低的执行计划。 +TiDB 使用统计信息作为优化器的输入，用于估算 SQL 语句每个执行计划步骤中处理的行数。优化器会估算每个可用计划的成本，包括 [索引访问](/choose-index.md) 和表连接的顺序，并为每个可用计划生成成本。优化器随后选择总体成本最低的执行计划。 ## 收集统计信息 @@ -29,7 +29,7 @@ TiDB 每 60 秒持久化一次更新信息。 根据表的数据变更量，TiDB 会自动调度 [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 对这些表收集统计信息。该行为由以下系统变量控制。 -| 系统变量 | 默认值 | 描述 | +| 系统变量 | 默认值 | 描述 | |---|---|---| | [`tidb_auto_analyze_concurrency`](/system-variables.md#tidb_auto_analyze_concurrency-new-in-v840) | `1` | TiDB 集群内自动分析操作的并发度。 | | [`tidb_auto_analyze_end_time`](/system-variables.md#tidb_auto_analyze_end_time) | `23:59 +0000` | TiDB 可执行自动更新的每日结束时间。 | @@ -37,7 +37,7 @@ TiDB 每 60 秒持久化一次更新信息。 | [`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio) | `0.5` | 自动更新的阈值。 | | [`tidb_auto_analyze_start_time`](/system-variables.md#tidb_auto_analyze_start_time) | `00:00 +0000` | TiDB 可执行自动更新的每日开始时间。 | | [`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-new-in-v610) | `ON` | 控制 TiDB 是否自动执行 `ANALYZE`。 | -| [`tidb_enable_auto_analyze_priority_queue`](/system-variables.md#tidb_enable_auto_analyze_priority_queue-new-in-v800) | `ON` | 控制是否启用优先队列调度自动收集统计信息的任务。启用后，TiDB 优先为更有价值的表收集统计信息，如新建索引和分区发生变更的分区表。此外，TiDB 会优先处理健康度较低的表，将其排在队列前面。 | +| [`tidb_enable_auto_analyze_priority_queue`](/system-variables.md#tidb_enable_auto_analyze_priority_queue-new-in-v800) | `ON` | 控制是否启用优先队列调度自动收集统计信息的任务。启用该变量后，TiDB 会优先收集更有价值的表的统计信息，如新建索引和分区发生变更的分区表。此外，TiDB 会优先处理健康度较低的表，将其排在队列前面。 | | [`tidb_enable_stats_owner`](/system-variables.md#tidb_enable_stats_owner-new-in-v840) | `ON` | 控制对应的 TiDB 实例是否可以运行自动统计信息更新任务。 | | [`tidb_max_auto_analyze_time`](/system-variables.md#tidb_max_auto_analyze_time-new-in-v610) | `43200`（12 小时） | 自动 `ANALYZE` 任务的最大执行时间，单位为秒。 | @@ -65,7 +65,7 @@ TiDB 每 60 秒持久化一次更新信息。 + `WITH NUM TOPN` 指定生成的 `TOPN` 的最大数量。 + `WITH NUM CMSKETCH DEPTH` 指定 CM Sketch 的深度。 + `WITH NUM CMSKETCH WIDTH` 指定 CM Sketch 的宽度。 -+ `WITH NUM SAMPLES` 指定样本数量。 ++ `WITH NUM SAMPLES` 指定采样数。 + `WITH FLOAT_NUM SAMPLERATE` 指定采样率。 `WITH NUM SAMPLES` 和 `WITH FLOAT_NUM SAMPLERATE` 分别对应两种不同的采样算法。 @@ -88,26 +88,26 @@ TiDB 每 60 秒持久化一次更新信息。 ![等深直方图示例](/media/statistics-1.png) -关于决定直方图桶数上限的参数，参见 [手动收集](#manual-collection)。桶数越多，直方图的精度越高；但更高的精度会消耗更多内存资源。你可以根据实际场景适当调整该值。 +关于决定直方图桶数上限的参数，参见 [手动收集](#manual-collection)。桶数越大，直方图的精度越高；但更高的精度会消耗更多内存资源。你可以根据实际场景适当调整该数值。 ### Count-Min Sketch > **注意：** > -> Count-Min Sketch 仅在统计信息版本 1 中用于等值/IN 谓词选择性估算。在版本 2 中，由于管理 Count-Min Sketch 以避免哈希冲突存在挑战，已改用直方图统计信息。 +> Count-Min Sketch 仅在统计信息版本 1 中用于等值/IN 谓词选择性估算。在版本 2 中，由于管理 Count-Min Sketch 以避免哈希冲突存在挑战（见下文），因此改为使用直方图统计信息。 Count-Min Sketch 是一种哈希结构。在处理如 `a = 1` 的等值查询或 `IN` 查询（如 `a IN (1, 2, 3)`）时，TiDB 使用该数据结构进行估算。 -由于 Count-Min Sketch 是哈希结构，可能会发生哈希冲突。在 [`EXPLAIN`](/sql-statements/sql-statement-explain.md) 语句中，如果等值查询的估算值与实际值偏差很大，可能是因为大值和小值被哈希到了一起。此时，你可以通过以下方式避免哈希冲突： +由于 Count-Min Sketch 是哈希结构，可能会发生哈希冲突。在 [`EXPLAIN`](/sql-statements/sql-statement-explain.md) 语句中，如果等值查询的估算值与实际值偏差很大，可以认为是大值和小值被哈希到了一起。此时，你可以通过以下方式之一避免哈希冲突： - 修改 `WITH NUM TOPN` 参数。TiDB 会将高频（前 x 个）数据单独存储，其余数据存储在 Count-Min Sketch 中。因此，为防止大值和小值被哈希到一起，可以增大 `WITH NUM TOPN` 的值。在 TiDB 中，默认值为 20，最大值为 1024。关于该参数的更多信息，参见 [手动收集](#manual-collection)。 -- 修改 `WITH NUM CMSKETCH DEPTH` 和 `WITH NUM CMSKETCH WIDTH` 两个参数。二者均影响哈希桶数量和冲突概率。你可以根据实际场景适当增大这两个参数的值，以降低哈希冲突概率，但会增加统计信息的内存占用。在 TiDB 中，`WITH NUM CMSKETCH DEPTH` 默认值为 5，`WITH NUM CMSKETCH WIDTH` 默认值为 2048。关于这两个参数的更多信息，参见 [手动收集](#manual-collection)。 +- 修改 `WITH NUM CMSKETCH DEPTH` 和 `WITH NUM CMSKETCH WIDTH` 两个参数。二者共同影响哈希桶数量和冲突概率。你可以根据实际场景适当增大这两个参数的值，以降低哈希冲突概率，但会增加统计信息的内存消耗。在 TiDB 中，`WITH NUM CMSKETCH DEPTH` 默认值为 5，`WITH NUM CMSKETCH WIDTH` 默认值为 2048。关于这两个参数的更多信息，参见 [手动收集](#manual-collection)。 ### Top-N Top-N 值是指某一列或索引中出现次数最多的前 N 个值。Top-N 统计信息通常也称为频率统计或数据倾斜。 -TiDB 会记录 Top-N 值及其出现次数。`N` 由 `WITH NUM TOPN` 参数控制，默认值为 20，即收集出现频率最高的前 20 个值。最大值为 1024。关于该参数的详细信息，参见 [手动收集](#manual-collection)。 +TiDB 会记录 Top-N 值及其出现次数。`N` 由 `WITH NUM TOPN` 参数控制。默认值为 20，即收集出现频率最高的前 20 个值。最大值为 1024。关于该参数的详细说明，参见 [手动收集](#manual-collection)。 ## 选择性统计信息收集 @@ -115,7 +115,7 @@ TiDB 会记录 Top-N 值及其出现次数。`N` 由 `WITH NUM TOPN` 参数控 ### 收集索引统计信息 -要收集 `TableName` 中 `IndexNameList` 所有索引的统计信息，可使用以下语法： +要收集 `TableName` 中 `IndexNameList` 所有索引的统计信息，使用以下语法： ```sql ANALYZE TABLE TableName INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE]; @@ -125,28 +125,28 @@ ANALYZE TABLE TableName INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DE > **注意：** > -> 为保证收集前后统计信息一致，当 `tidb_analyze_version` 为 `2` 时，该语法会收集索引列及所有索引的统计信息。 +> 为保证收集前后的统计信息一致，当 `tidb_analyze_version` 为 `2` 时，该语法会收集索引列和所有索引的统计信息。 ### 收集部分列的统计信息 -在执行 SQL 语句时，优化器大多数情况下只会用到部分列的统计信息。例如，出现在 `WHERE`、`JOIN`、`ORDER BY` 和 `GROUP BY` 子句中的列，这些列称为谓词列（predicate columns）。 +在 TiDB 执行 SQL 语句时，优化器大多数情况下只会使用部分列的统计信息。例如，出现在 `WHERE`、`JOIN`、`ORDER BY` 和 `GROUP BY` 子句中的列。这些列称为谓词列（predicate columns）。 -如果表中列很多，收集所有列的统计信息会带来较大开销。为降低开销，你可以只为特定列（自定义选择）或 `PREDICATE COLUMNS`（谓词列）收集统计信息，以供优化器使用。若需持久化任意子集列的列表以便后续复用，参见 [持久化列配置](#persist-column-configurations)。 +如果一个表有很多列，收集所有列的统计信息会带来较大开销。为减少开销，你可以只为特定列（你选择的）或 `PREDICATE COLUMNS`（谓词列）收集统计信息，以供优化器使用。要持久化任意子集列的列表以便后续复用，参见 [持久化列配置](#persist-column-configurations)。 > **注意：** > -> - 仅在 [`tidb_analyze_version = 2`](/system-variables.md#tidb_analyze_version-new-in-v510) 时，才支持收集谓词列的统计信息。 -> - 从 TiDB v7.2.0 起，TiDB 引入了 [`tidb_analyze_skip_column_types`](/system-variables.md#tidb_analyze_skip_column_types-new-in-v720) 系统变量，用于指定在执行 `ANALYZE` 命令收集统计信息时跳过哪些类型的列。该变量仅适用于 `tidb_analyze_version = 2`。 +> - 只为谓词列收集统计信息仅适用于 [`tidb_analyze_version = 2`](/system-variables.md#tidb_analyze_version-new-in-v510)。 +> - 从 TiDB v7.2.0 起，TiDB 引入了 [`tidb_analyze_skip_column_types`](/system-variables.md#tidb_analyze_skip_column_types-new-in-v720) 系统变量，用于指定在执行 `ANALYZE` 命令收集统计信息时跳过哪些类型的列。该系统变量仅适用于 `tidb_analyze_version = 2`。 -- 若要收集指定列的统计信息，使用以下语法： +- 要为指定列收集统计信息，使用以下语法： ```sql ANALYZE TABLE TableName COLUMNS ColumnNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE]; ``` - 其中，`ColumnNameList` 指定目标列名列表。若需指定多个列名，使用英文逗号 `,` 分隔。例如：`ANALYZE table t columns a, b`。该语法除了收集指定表中指定列的统计信息外，还会同时收集该表的索引列及所有索引的统计信息。 + 其中，`ColumnNameList` 指定目标列的名称列表。如果需要指定多个列，使用逗号 `,` 分隔列名。例如，`ANALYZE table t columns a, b`。该语法除了收集指定表中指定列的统计信息外，还会同时收集该表的索引列和所有索引的统计信息。 -- 若要收集 `PREDICATE COLUMNS` 的统计信息，使用以下语法： +- 要为 `PREDICATE COLUMNS` 收集统计信息，使用以下语法： ```sql ANALYZE TABLE TableName PREDICATE COLUMNS [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE]; @@ -164,14 +164,14 @@ ANALYZE TABLE TableName INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DE - 除了收集指定表的 `PREDICATE COLUMNS` 统计信息外，该语法还会同时收集该表的索引列及所有索引的统计信息。 + 除了收集指定表中 `PREDICATE COLUMNS` 的统计信息外，该语法还会同时收集该表的索引列和所有索引的统计信息。 > **注意：** > - > - 如果 [`mysql.column_stats_usage`](/mysql-schema/mysql-schema.md#statistics-system-tables) 系统表中未记录该表的任何 `PREDICATE COLUMNS`，则上述语法会收集该表的索引列及所有索引的统计信息。 - > - 被排除在收集之外的列（无论是手动指定列还是使用 `PREDICATE COLUMNS`）不会被覆盖其统计信息。当执行新类型的 SQL 查询时，优化器会使用这些列的旧统计信息（若存在），或使用伪列统计信息（若从未收集过统计信息）。下次使用 `PREDICATE COLUMNS` 执行 ANALYZE 时，会收集这些列的统计信息。 + > - 如果 [`mysql.column_stats_usage`](/mysql-schema/mysql-schema.md#statistics-system-tables) 系统表中未记录该表的任何 `PREDICATE COLUMNS`，上述语法会收集该表的索引列和所有索引的统计信息。 + > - 被排除在收集之外的列（无论是手动列举还是使用 `PREDICATE COLUMNS`）不会被覆盖其统计信息。当执行新的 SQL 查询类型时，优化器会使用这些列的旧统计信息（如果存在），或使用伪列统计信息（如果从未收集过统计信息）。下次使用 `PREDICATE COLUMNS` 执行 ANALYZE 时会收集这些列的统计信息。 -- 若要收集所有列及索引的统计信息，使用以下语法： +- 要收集所有列和索引的统计信息，使用以下语法： ```sql ANALYZE TABLE TableName ALL COLUMNS [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE]; @@ -179,13 +179,13 @@ ANALYZE TABLE TableName INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DE ### 收集分区统计信息 -- 若要收集 `TableName` 中 `PartitionNameList` 所有分区的统计信息，使用以下语法： +- 要收集 `TableName` 中 `PartitionNameList` 所有分区的统计信息，使用以下语法： ```sql ANALYZE TABLE TableName PARTITION PartitionNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE]; ``` -- 若要收集 `TableName` 中 `PartitionNameList` 所有分区的索引统计信息，使用以下语法： +- 要收集 `TableName` 中 `PartitionNameList` 所有分区的索引统计信息，使用以下语法： ```sql ANALYZE TABLE TableName PARTITION PartitionNameList INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH]|[WITH NUM SAMPLES|WITH FLOATNUM SAMPLERATE]; @@ -199,19 +199,19 @@ ANALYZE TABLE TableName INDEX [IndexNameList] [WITH NUM BUCKETS|TOPN|CMSKETCH DE #### 动态裁剪模式下收集分区表统计信息 -在 [动态裁剪模式](/partitioned-table.md#dynamic-pruning-mode)（自 v6.3.0 起为默认）下访问分区表时，TiDB 会收集表级统计信息，即分区表的全局统计信息。目前，全局统计信息是从所有分区的统计信息聚合而来。在动态裁剪模式下，表中任一分区的统计信息更新都可能触发该表全局统计信息的更新。 +在 [动态裁剪模式](/partitioned-table.md#dynamic-pruning-mode)（自 v6.3.0 起为默认）下访问分区表时，TiDB 会收集表级统计信息，即分区表的全局统计信息。目前，全局统计信息是由所有分区的统计信息聚合而成。在动态裁剪模式下，表中任一分区的统计信息更新都可能触发该表全局统计信息的更新。 如果部分分区的统计信息为空，或部分分区缺少某些列的统计信息，则收集行为由 [`tidb_skip_missing_partition_stats`](/system-variables.md#tidb_skip_missing_partition_stats-new-in-v730) 变量控制： - 当触发全局统计信息更新且 [`tidb_skip_missing_partition_stats`](/system-variables.md#tidb_skip_missing_partition_stats-new-in-v730) 为 `OFF` 时： - - 若部分分区无统计信息（如新建分区从未分析过），全局统计信息生成会中断，并显示警告，提示分区无统计信息。 + - 如果某些分区没有统计信息（如新建分区从未被分析过），全局统计信息生成会中断，并显示警告信息，提示分区上无统计信息。 - - 若部分分区缺少某些列的统计信息（这些分区分析时指定了不同的列），在聚合这些列的统计信息时，全局统计信息生成会中断，并显示警告，提示部分分区缺少某些列的统计信息。 + - 如果某些分区缺少某些列的统计信息（这些分区分析时指定了不同的列），在聚合这些列的统计信息时全局统计信息生成会中断，并显示警告信息，提示某些分区缺少某些列的统计信息。 - 当触发全局统计信息更新且 [`tidb_skip_missing_partition_stats`](/system-variables.md#tidb_skip_missing_partition_stats-new-in-v730) 为 `ON` 时： - - 若部分分区缺少全部或部分列的统计信息，TiDB 在生成全局统计信息时会跳过这些缺失的分区统计信息，不影响全局统计信息的生成。 + - 如果某些分区缺少全部或部分列的统计信息，TiDB 在生成全局统计信息时会跳过这些缺失的分区统计信息，从而不影响全局统计信息的生成。 在动态裁剪模式下，分区和表的 `ANALYZE` 配置应保持一致。因此，如果你在 `ANALYZE TABLE TableName PARTITION PartitionNameList` 语句后指定了 `COLUMNS` 配置，或在 `WITH` 后指定了 `OPTIONS` 配置，TiDB 会忽略这些配置并返回警告。 @@ -228,47 +228,47 @@ TiDB 提供两种方式提升统计信息收集性能： ### 统计信息采样 -采样可通过 `ANALYZE` 语句的两个不同选项实现，每个选项对应不同的收集算法： +采样可通过 `ANALYZE` 语句的两个选项实现——每个选项对应不同的收集算法： -- `WITH NUM SAMPLES` 指定采样集大小，在 TiDB 中实现为蓄水池采样法。当表较大时，不建议使用该方法收集统计信息。因为蓄水池采样的中间结果集包含冗余结果，会对内存等资源造成额外压力。 -- `WITH FLOAT_NUM SAMPLERATE` 是 v5.3.0 引入的采样方法，取值范围为 `(0, 1]`，指定采样率。在 TiDB 中实现为伯努利采样，更适合大表采样，在收集效率和资源使用上表现更优。 +- `WITH NUM SAMPLES` 指定采样集的大小，在 TiDB 中实现为蓄水池采样方法。当表较大时，不建议使用该方法收集统计信息。因为蓄水池采样的中间结果集包含冗余结果，会对内存等资源造成额外压力。 +- `WITH FLOAT_NUM SAMPLERATE` 是 v5.3.0 引入的采样方法，取值范围为 `(0, 1]`，指定采样率。在 TiDB 中实现为伯努利采样，更适合大表采样，在收集效率和资源使用上表现更好。 -v5.3.0 之前，TiDB 使用蓄水池采样法收集统计信息。自 v5.3.0 起，TiDB 统计信息版本 2 默认使用伯努利采样法。若需继续使用蓄水池采样法，可使用 `WITH NUM SAMPLES` 语句。 +v5.3.0 之前，TiDB 使用蓄水池采样方法收集统计信息。从 v5.3.0 起，TiDB 统计信息版本 2 默认使用伯努利采样方法收集统计信息。如需继续使用蓄水池采样方法，可以使用 `WITH NUM SAMPLES` 语句。 当前采样率基于自适应算法计算。当你可以通过 [`SHOW STATS_META`](/sql-statements/sql-statement-show-stats-meta.md) 观察到表的行数时，可以用该行数计算对应 100,000 行的采样率。如果无法观察到该行数，可以用 [`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md) 结果中 `APPROXIMATE_KEYS` 列的所有值之和作为参考，计算采样率。 > **注意：** > -> 通常，`STATS_META` 比 `APPROXIMATE_KEYS` 更可靠。但当 `STATS_META` 结果远小于 `APPROXIMATE_KEYS` 时，建议用 `APPROXIMATE_KEYS` 计算采样率。 +> 通常，`STATS_META` 比 `APPROXIMATE_KEYS` 更可信。但当 `STATS_META` 的结果远小于 `APPROXIMATE_KEYS` 时，建议用 `APPROXIMATE_KEYS` 计算采样率。 ### 收集统计信息的内存配额 > **警告：** > -> 目前，`ANALYZE` 内存配额为实验特性，生产环境下内存统计可能不准确。 +> 目前，`ANALYZE` 内存配额为实验特性，生产环境下的内存统计可能不准确。 -自 TiDB v6.1.0 起，你可以通过系统变量 [`tidb_mem_quota_analyze`](/system-variables.md#tidb_mem_quota_analyze-new-in-v610) 控制 TiDB 收集统计信息时的内存配额。 +自 TiDB v6.1.0 起，你可以使用系统变量 [`tidb_mem_quota_analyze`](/system-variables.md#tidb_mem_quota_analyze-new-in-v610) 控制 TiDB 收集统计信息时的内存配额。 -设置 `tidb_mem_quota_analyze` 时，应结合集群数据量综合考虑。使用默认采样率时，主要考虑列数、列值大小和 TiDB 的内存配置。配置最大值和最小值时可参考以下建议： +设置 `tidb_mem_quota_analyze` 的合适值时，需要考虑集群数据量。在使用默认采样率时，主要考虑列数、列值大小和 TiDB 的内存配置。配置最大值和最小值时可参考以下建议： > **注意：** > > 以下建议仅供参考，具体值需结合实际场景配置。 -- 最小值：应大于 TiDB 收集列数最多的表时的最大内存使用量。大致参考：默认配置下，TiDB 收集 20 列的表时最大内存约 800 MiB；收集 160 列的表时最大内存约 5 GiB。 +- 最小值：应大于 TiDB 收集列数最多的表时的最大内存使用量。大致参考：TiDB 使用默认配置收集 20 列的表时，最大内存使用约 800 MiB；收集 160 列的表时，最大内存使用约 5 GiB。 - 最大值：应小于 TiDB 未收集统计信息时的可用内存。 ## 持久化 ANALYZE 配置 自 v5.4.0 起，TiDB 支持持久化部分 `ANALYZE` 配置。通过该特性，可以方便地复用现有配置进行后续统计信息收集。 -支持持久化的 `ANALYZE` 配置如下： +以下为支持持久化的 `ANALYZE` 配置： | 配置项 | 对应 ANALYZE 语法 | | --- | --- | | 直方图桶数 | `WITH NUM BUCKETS` | | Top-N 数量 | `WITH NUM TOPN` | -| 样本数量 | `WITH NUM SAMPLES` | +| 采样数 | `WITH NUM SAMPLES` | | 采样率 | `WITH FLOATNUM SAMPLERATE` | | `ANALYZE` 列类型 | AnalyzeColumnOption ::= ( 'ALL COLUMNS' \| 'PREDICATE COLUMNS' \| 'COLUMNS' ColumnNameList ) | | `ANALYZE` 列 | ColumnNameList ::= Identifier ( ',' Identifier )* | @@ -283,38 +283,38 @@ v5.3.0 之前，TiDB 使用蓄水池采样法收集统计信息。自 v5.3.0 起 -`ANALYZE` 配置持久化特性默认关闭。若需启用该特性，请确保系统变量 `tidb_persist_analyze_options` 为 `ON`，并将系统变量 `tidb_analyze_version` 设置为 `2`。 +`ANALYZE` 配置持久化特性默认关闭。要启用该特性，请确保系统变量 `tidb_persist_analyze_options` 为 `ON`，并将系统变量 `tidb_analyze_version` 设置为 `2`。 你可以通过该特性，在手动执行 `ANALYZE` 语句时记录指定的持久化配置。记录后，下次 TiDB 自动更新统计信息或你手动收集统计信息时未指定这些配置，TiDB 会按照已记录的配置收集统计信息。 -要查询某张表用于自动分析操作的持久化配置，可执行以下 SQL 语句： +要查询某张表用于自动分析操作的持久化配置，可以使用以下 SQL 语句： ```sql SELECT sample_num, sample_rate, buckets, topn, column_choice, column_ids FROM mysql.analyze_options opt JOIN information_schema.tables tbl ON opt.table_id = tbl.tidb_table_id WHERE tbl.table_schema = '{db_name}' AND tbl.table_name = '{table_name}'; ``` -TiDB 会用最新一次 `ANALYZE` 语句指定的新配置覆盖之前记录的持久化配置。例如，执行 `ANALYZE TABLE t WITH 200 TOPN;` 后，`ANALYZE` 语句会设置 top 200 的值。随后执行 `ANALYZE TABLE t WITH 0.1 SAMPLERATE;`，则自动 `ANALYZE` 语句会同时设置 top 200 和采样率 0.1，等同于 `ANALYZE TABLE t WITH 200 TOPN, 0.1 SAMPLERATE;`。 +TiDB 会用最新一次 `ANALYZE` 语句指定的新配置覆盖之前记录的持久化配置。例如，执行 `ANALYZE TABLE t WITH 200 TOPN;`，会设置 `ANALYZE` 语句中的前 200 个值。随后执行 `ANALYZE TABLE t WITH 0.1 SAMPLERATE;`，会同时设置前 200 个值和采样率 0.1，用于自动 `ANALYZE` 语句，效果等同于 `ANALYZE TABLE t WITH 200 TOPN, 0.1 SAMPLERATE;`。 ### 关闭 ANALYZE 配置持久化 -若需关闭 `ANALYZE` 配置持久化特性，将系统变量 `tidb_persist_analyze_options` 设置为 `OFF`。由于 `ANALYZE` 配置持久化特性不适用于 `tidb_analyze_version = 1`，将 `tidb_analyze_version` 设置为 `1` 也可关闭该特性。 +要关闭 `ANALYZE` 配置持久化特性，将系统变量 `tidb_persist_analyze_options` 设置为 `OFF`。由于 `ANALYZE` 配置持久化特性不适用于 `tidb_analyze_version = 1`，因此将 `tidb_analyze_version` 设置为 `1` 也可关闭该特性。 -关闭 `ANALYZE` 配置持久化特性后，TiDB 不会清除已持久化的配置记录。因此，若你再次启用该特性，TiDB 会继续使用之前记录的持久化配置收集统计信息。 +关闭 `ANALYZE` 配置持久化特性后，TiDB 不会清除已持久化的配置记录。因此，如果你再次启用该特性，TiDB 会继续使用之前记录的持久化配置收集统计信息。 > **注意：** > -> 再次启用 `ANALYZE` 配置持久化特性时，若之前记录的持久化配置已不适用于最新数据，你需要手动执行 `ANALYZE` 语句并指定新的持久化配置。 +> 当你再次启用 `ANALYZE` 配置持久化特性时，如果之前记录的持久化配置已不适用于最新数据，需要手动执行 `ANALYZE` 语句并指定新的持久化配置。 ### 持久化列配置 -如果你希望持久化 `ANALYZE` 语句中的列配置（包括 `COLUMNS ColumnNameList`、`PREDICATE COLUMNS` 和 `ALL COLUMNS`），请将系统变量 `tidb_persist_analyze_options` 设置为 `ON`，以启用 [ANALYZE 配置持久化](#persist-analyze-configurations) 特性。启用后： +如果你希望在 `ANALYZE` 语句中持久化列配置（包括 `COLUMNS ColumnNameList`、`PREDICATE COLUMNS` 和 `ALL COLUMNS`），请将系统变量 `tidb_persist_analyze_options` 设置为 `ON`，以启用 [ANALYZE 配置持久化](#persist-analyze-configurations) 特性。启用后： -- 当 TiDB 自动收集统计信息，或你手动执行 `ANALYZE` 语句但未指定列配置时，TiDB 会继续使用之前持久化的配置收集统计信息。 +- 当 TiDB 自动收集统计信息，或你手动执行 `ANALYZE` 语句未指定列配置时，TiDB 会继续使用之前持久化的配置收集统计信息。 - 当你多次手动执行带有列配置的 `ANALYZE` 语句时，TiDB 会用最新一次 `ANALYZE` 语句指定的新配置覆盖之前记录的持久化配置。 -要定位已收集统计信息的 `PREDICATE COLUMNS` 和列，可使用 [`SHOW COLUMN_STATS_USAGE`](/sql-statements/sql-statement-show-column-stats-usage.md) 语句。 +要定位 `PREDICATE COLUMNS` 及已收集统计信息的列，可使用 [`SHOW COLUMN_STATS_USAGE`](/sql-statements/sql-statement-show-column-stats-usage.md) 语句。 如下示例，在执行 `ANALYZE TABLE t PREDICATE COLUMNS;` 后，TiDB 会收集列 `b`、`c` 和 `d` 的统计信息，其中 `b` 为谓词列，`c` 和 `d` 为索引列。 @@ -322,7 +322,7 @@ TiDB 会用最新一次 `ANALYZE` 语句指定的新配置覆盖之前记录的 CREATE TABLE t (a INT, b INT, c INT, d INT, INDEX idx_c_d(c, d)); Query OK, 0 rows affected (0.00 sec) --- 优化器在该查询中会使用列 b 的统计信息。 +-- 优化器在本查询中会使用列 b 的统计信息。 SELECT * FROM t WHERE b > 1; Empty set (0.00 sec) @@ -361,7 +361,7 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; - 对于 TiDB Cloud，该变量的默认值自 v6.5.0 起由 `1` 变为 `2`。 - 如果你的集群由早期版本升级而来，升级后 `tidb_analyze_version` 的默认值不会改变。 -推荐使用版本 2，且后续会持续增强，最终完全替代版本 1。与版本 1 相比，版本 2 在大数据量下提升了统计信息的准确性，并通过移除 Count-Min Sketch 统计信息收集（用于谓词选择性估算）提升了收集性能，同时支持仅对选定列自动收集（参见 [收集部分列的统计信息](#collect-statistics-on-some-columns)）。 +推荐使用版本 2，且后续会持续增强，最终完全替代版本 1。与版本 1 相比，版本 2 在大数据量下提升了许多统计信息的准确性。版本 2 还通过移除 Count-Min Sketch 统计信息用于谓词选择性估算，支持仅对选定列自动收集统计信息（参见 [收集部分列的统计信息](#collect-statistics-on-some-columns)），从而提升了收集性能。 下表列出了每个版本为优化器估算收集的信息： @@ -376,13 +376,13 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; ### 切换统计信息版本 -建议确保所有表/索引（及分区）均使用同一版本的统计信息收集。推荐使用版本 2，但不建议无正当理由随意切换版本。切换版本期间，若所有表尚未用新版本分析，可能会出现一段时间内无统计信息，影响优化器的执行计划选择。 +建议确保所有表/索引（及分区）都使用同一版本的统计信息收集。推荐使用版本 2，但不建议无正当理由（如当前版本出现问题）随意切换版本。切换版本期间，直到所有表都用新版本分析完毕，可能会有一段时间没有统计信息，这可能会对优化器的计划选择产生负面影响。 -常见的切换理由包括：在版本 1 下，因收集 Count-Min Sketch 统计信息时哈希冲突导致等值/IN 谓词估算不准确。解决方案见 [Count-Min Sketch](#count-min-sketch) 一节。或者，将 `tidb_analyze_version` 设为 2 并对所有对象重新执行 `ANALYZE` 也是一种解决方案。在版本 2 的早期发布中，`ANALYZE` 后存在内存溢出的风险。该问题已修复，但当时的解决方法是将 `tidb_analyze_version` 设为 1 并对所有对象重新执行 `ANALYZE`。 +切换的正当理由示例：在版本 1 下，因收集 Count-Min Sketch 统计信息时哈希冲突，导致等值/IN 谓词估算不准确。解决方案见 [Count-Min Sketch](#count-min-sketch) 部分。或者，将 `tidb_analyze_version` 设为 `2` 并对所有对象重新执行 `ANALYZE` 也是一种解决方案。在版本 2 的早期发布中，`ANALYZE` 后存在内存溢出的风险。该问题已修复，但最初的解决方法是将 `tidb_analyze_version` 设为 `1` 并对所有对象重新执行 `ANALYZE`。 切换版本前的 `ANALYZE` 准备： -- 若手动执行 `ANALYZE` 语句，请手动分析所有需分析的表。 +- 如果手动执行 `ANALYZE` 语句，请手动分析所有需要分析的表。 ```sql SELECT DISTINCT(CONCAT('ANALYZE TABLE ', table_schema, '.', table_name, ';')) @@ -391,7 +391,7 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; WHERE stats_ver = 2; ``` -- 若 TiDB 自动执行 `ANALYZE` 语句（已启用自动分析），可执行以下语句生成 [`DROP STATS`](/sql-statements/sql-statement-drop-stats.md) 语句： +- 如果 TiDB 因启用了自动分析而自动执行 `ANALYZE` 语句，请执行以下语句生成 [`DROP STATS`](/sql-statements/sql-statement-drop-stats.md) 语句： ```sql SELECT DISTINCT(CONCAT('DROP STATS ', table_schema, '.', table_name, ';')) @@ -400,7 +400,7 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; WHERE stats_ver = 2; ``` -- 若上述语句结果过长无法复制粘贴，可将结果导出到临时文本文件，再从文件中执行： +- 如果上述语句的结果太长无法复制粘贴，可以将结果导出到临时文本文件，然后通过如下方式从文件执行： ```sql SELECT DISTINCT ... INTO OUTFILE '/tmp/sql.txt'; @@ -413,15 +413,15 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; ### `ANALYZE` 状态 -执行 `ANALYZE` 语句时，可通过 [`SHOW ANALYZE STATUS`](/sql-statements/sql-statement-show-analyze-status.md) 查看当前 `ANALYZE` 状态。 +执行 `ANALYZE` 语句时，可以通过 [`SHOW ANALYZE STATUS`](/sql-statements/sql-statement-show-analyze-status.md) 查看当前 `ANALYZE` 状态。 -自 TiDB v6.1.0 起，`SHOW ANALYZE STATUS` 支持显示集群级任务。即使 TiDB 重启后，仍可通过该语句查看重启前的任务记录。TiDB v6.1.0 之前，`SHOW ANALYZE STATUS` 仅能显示实例级任务，且重启后任务记录会被清除。 +自 TiDB v6.1.0 起，`SHOW ANALYZE STATUS` 语句支持显示集群级别的任务。即使 TiDB 重启后，仍可通过该语句查看重启前的任务记录。TiDB v6.1.0 之前，`SHOW ANALYZE STATUS` 仅能显示实例级别的任务，且 TiDB 重启后任务记录会被清除。 -`SHOW ANALYZE STATUS` 仅显示最近的任务记录。自 TiDB v6.1.0 起，你可以通过系统表 `mysql.analyze_jobs` 查看最近 7 天的历史任务。 +`SHOW ANALYZE STATUS` 仅显示最近的任务记录。自 TiDB v6.1.0 起，你可以通过系统表 `mysql.analyze_jobs` 查看最近 7 天内的历史任务。 -当设置了 [`tidb_mem_quota_analyze`](/system-variables.md#tidb_mem_quota_analyze-new-in-v610)，且后台自动 `ANALYZE` 任务使用内存超出该阈值时，任务会被重试。你可以在 `SHOW ANALYZE STATUS` 输出中看到失败和重试的任务。 +当设置了 [`tidb_mem_quota_analyze`](/system-variables.md#tidb_mem_quota_analyze-new-in-v610)，且 TiDB 后台自动 `ANALYZE` 任务使用的内存超过该阈值时，任务会被重试。你可以在 `SHOW ANALYZE STATUS` 语句的输出中看到失败和重试的任务。 -当 [`tidb_max_auto_analyze_time`](/system-variables.md#tidb_max_auto_analyze_time-new-in-v610) 大于 0，且后台自动 `ANALYZE` 任务执行时间超出该阈值时，任务会被终止。 +当 [`tidb_max_auto_analyze_time`](/system-variables.md#tidb_max_auto_analyze_time-new-in-v610) 大于 0 且 TiDB 后台自动 `ANALYZE` 任务执行时间超过该阈值时，任务会被终止。 ```sql mysql> SHOW ANALYZE STATUS [ShowLikeOrWhere]; @@ -460,39 +460,39 @@ mysql> SHOW ANALYZE STATUS [ShowLikeOrWhere]; > **注意：** > -> 加载统计信息不适用于 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 +> 统计信息加载功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 默认情况下，TiDB 会根据列统计信息的大小采用不同的加载方式： -- 对于占用内存较小的统计信息（如 count、distinctCount 和 nullCount），只要列数据有更新，TiDB 会自动将对应统计信息加载到内存中，供 SQL 优化阶段使用。 -- 对于占用内存较大的统计信息（如直方图、TopN 和 Count-Min Sketch），为保证 SQL 执行性能，TiDB 会按需异步加载这些统计信息。例如，直方图统计信息只有在优化器需要使用某列的直方图时，才会将其加载到内存。按需异步加载不会影响 SQL 执行性能，但可能导致 SQL 优化时统计信息不完整。 +- 对于占用内存较小的统计信息（如 count、distinctCount 和 nullCount），只要列数据被更新，TiDB 会自动将相应统计信息加载到内存中，供 SQL 优化阶段使用。 +- 对于占用内存较大的统计信息（如直方图、TopN 和 Count-Min Sketch），为保证 SQL 执行性能，TiDB 会按需异步加载统计信息。例如，TiDB 仅在优化器需要使用某列的直方图统计信息时，才将该列的直方图统计信息加载到内存中。按需异步加载统计信息不会影响 SQL 执行性能，但可能导致 SQL 优化时统计信息不完整。 -自 v5.4.0 起，TiDB 引入了同步加载统计信息特性。该特性允许 TiDB 在执行 SQL 语句时，将大体积统计信息（如直方图、TopN 和 Count-Min Sketch）同步加载到内存，从而提升 SQL 优化时统计信息的完整性。 +自 v5.4.0 起，TiDB 引入了同步加载统计信息功能。该功能允许 TiDB 在执行 SQL 语句时，将大体量统计信息（如直方图、TopN 和 Count-Min Sketch 统计信息）同步加载到内存中，从而提升 SQL 优化时统计信息的完整性。 -要启用该特性，请将 [`tidb_stats_load_sync_wait`](/system-variables.md#tidb_stats_load_sync_wait-new-in-v540) 系统变量设置为 SQL 优化可等待同步加载完整列统计信息的超时时间（毫秒）。该变量默认值为 `100`，表示已启用该特性。 +要启用该功能，请将 [`tidb_stats_load_sync_wait`](/system-variables.md#tidb_stats_load_sync_wait-new-in-v540) 系统变量设置为 SQL 优化可等待同步加载完整列统计信息的超时时间（单位：毫秒）。该变量默认值为 `100`，表示已启用该功能。 -启用同步加载统计信息特性后，你还可以进一步配置如下： +启用同步加载统计信息功能后，你还可以进一步配置如下： -- 若要控制 SQL 优化等待超时后的行为，可修改 [`tidb_stats_load_pseudo_timeout`](/system-variables.md#tidb_stats_load_pseudo_timeout-new-in-v540) 系统变量。该变量默认值为 `ON`，表示超时后 SQL 优化过程不会使用任何列的直方图、TopN 或 CMSketch 统计信息。若设为 `OFF`，超时后 SQL 执行失败。 -- 若要指定同步加载统计信息特性可并发处理的最大列数，可修改 TiDB 配置文件中的 [`stats-load-concurrency`](/tidb-configuration-file.md#stats-load-concurrency-new-in-v540) 选项。自 v8.2.0 起，默认值为 `0`，表示 TiDB 会根据服务器配置自动调整并发度。 -- 若要指定同步加载统计信息特性可缓存的最大列请求数，可修改 TiDB 配置文件中的 [`stats-load-queue-size`](/tidb-configuration-file.md#stats-load-queue-size-new-in-v540) 选项。默认值为 `1000`。 +- 要控制 SQL 优化等待超时后的行为，可修改 [`tidb_stats_load_pseudo_timeout`](/system-variables.md#tidb_stats_load_pseudo_timeout-new-in-v540) 系统变量。该变量默认值为 `ON`，表示超时后 SQL 优化过程不会使用任何列的直方图、TopN 或 CMSketch 统计信息。如果该变量设为 `OFF`，超时后 SQL 执行失败。 +- 要指定同步加载统计信息功能可并发处理的最大列数，可修改 TiDB 配置文件中的 [`stats-load-concurrency`](/tidb-configuration-file.md#stats-load-concurrency-new-in-v540) 选项。自 v8.2.0 起，该选项默认值为 `0`，表示 TiDB 会根据服务器配置自动调整并发度。 +- 要指定同步加载统计信息功能可缓存的最大列请求数，可修改 TiDB 配置文件中的 [`stats-load-queue-size`](/tidb-configuration-file.md#stats-load-queue-size-new-in-v540) 选项。默认值为 `1000`。 -TiDB 启动期间，在初始统计信息尚未完全加载前执行的 SQL 语句，可能会生成次优的执行计划，导致性能问题。为避免此类问题，TiDB v7.1.0 引入了配置参数 [`force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)。通过该选项，你可以控制 TiDB 是否在统计信息初始化完成后才提供服务。自 v7.2.0 起，该参数默认启用。 +在 TiDB 启动期间，初始统计信息未完全加载前执行的 SQL 语句可能会生成次优的执行计划，导致性能问题。为避免此类问题，TiDB v7.1.0 引入了配置参数 [`force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)。通过该选项，你可以控制 TiDB 是否在统计信息初始化完成后才提供服务。自 v7.2.0 起，该参数默认启用。 -自 v7.1.0 起，TiDB 引入了 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710) 轻量级统计信息初始化。 +自 v7.1.0 起，TiDB 引入了 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710) 用于轻量级统计信息初始化。 -- 当 `lite-init-stats` 为 `true` 时，统计信息初始化不会将任何索引或列的直方图、TopN 或 Count-Min Sketch 加载到内存。 -- 当 `lite-init-stats` 为 `false` 时，统计信息初始化会将索引和主键的直方图、TopN 和 Count-Min Sketch 加载到内存，但不会加载非主键列的直方图、TopN 或 Count-Min Sketch。当优化器需要某个索引或列的直方图、TopN 和 Count-Min Sketch 时，会同步或异步加载所需统计信息。 +- 当 `lite-init-stats` 为 `true` 时，统计信息初始化不会将任何索引或列的直方图、TopN 或 Count-Min Sketch 加载到内存中。 +- 当 `lite-init-stats` 为 `false` 时，统计信息初始化会将索引和主键的直方图、TopN 和 Count-Min Sketch 加载到内存中，但不会加载非主键列的直方图、TopN 或 Count-Min Sketch。当优化器需要某个索引或列的直方图、TopN 和 Count-Min Sketch 时，会同步或异步加载所需统计信息到内存。 -`lite-init-stats` 默认值为 `true`，即启用轻量级统计信息初始化。将 `lite-init-stats` 设为 `true` 可加快统计信息初始化速度，并通过避免不必要的统计信息加载降低 TiDB 内存占用。 +`lite-init-stats` 的默认值为 `true`，即启用轻量级统计信息初始化。将 `lite-init-stats` 设为 `true` 可加快统计信息初始化速度，并通过避免不必要的统计信息加载减少 TiDB 内存使用。 -启用同步加载统计信息特性后，你可以通过修改 [`tidb_stats_load_pseudo_timeout`](/system-variables.md#tidb_stats_load_pseudo_timeout-new-in-v540) 系统变量控制 SQL 优化等待超时后的行为。该变量默认值为 `ON`，表示超时后 SQL 优化过程不会使用任何列的直方图、TopN 或 CMSketch 统计信息。若设为 `OFF`，超时后 SQL 执行失败。 +启用同步加载统计信息功能后，你可以通过修改 [`tidb_stats_load_pseudo_timeout`](/system-variables.md#tidb_stats_load_pseudo_timeout-new-in-v540) 系统变量的值，控制 SQL 优化等待超时后的行为。该变量默认值为 `ON`，表示超时后 SQL 优化过程不会使用任何列的直方图、TopN 或 CMSketch 统计信息。如果该变量设为 `OFF`，超时后 SQL 执行失败。 @@ -504,7 +504,7 @@ TiDB 启动期间，在初始统计信息尚未完全加载前执行的 SQL 语 > **注意：** > -> 本节内容不适用于 TiDB Cloud。 +> 本节不适用于 TiDB Cloud。 @@ -524,7 +524,7 @@ TiDB 启动期间，在初始统计信息尚未完全加载前执行的 SQL 语 curl -s http://127.0.0.1:10080/stats/dump/test/t1 -o /tmp/t1.json ``` -+ 获取 `${db_name}` 数据库中 `${table_name}` 表在指定时间点的 JSON 格式统计信息： ++ 获取指定时间点 `${db_name}` 数据库中 `${table_name}` 表的 JSON 格式统计信息： ``` http://${tidb-server-ip}:${tidb-server-status-port}/stats/dump/${db_name}/${table_name}/${yyyyMMddHHmmss} @@ -546,7 +546,7 @@ TiDB 启动期间，在初始统计信息尚未完全加载前执行的 SQL 语 LOAD STATS 'file_name'; ``` -`file_name` 为待导入的统计信息文件名。 +`file_name` 为要导入的统计信息文件名。 ## 锁定统计信息 @@ -695,8 +695,8 @@ mysql> SHOW WARNINGS; ### 锁定统计信息的行为 -* 若锁定分区表的统计信息，则该分区表所有分区的统计信息均被锁定。 -* 若截断表或分区，则表或分区的统计信息锁会被释放。 +* 如果你锁定了分区表的统计信息，则该分区表所有分区的统计信息都会被锁定。 +* 如果你截断表或分区，则该表或分区的统计信息锁会被释放。 下表描述了锁定统计信息的行为： @@ -706,13 +706,13 @@ mysql> SHOW WARNINGS; | 分区表且整表被锁定 | 锁失效 | 锁失效，因 TiDB 删除旧表，锁信息也被删除 | 旧分区锁信息失效，新分区自动加锁 | 新分区自动加锁 | 被删除分区锁信息清除，整表锁继续生效 | 被删除分区锁信息清除，新分区自动加锁 | 锁信息转移到交换表，新分区自动加锁 | | 分区表且仅部分分区被锁定 | 锁失效 | 锁失效，因 TiDB 删除旧表，锁信息也被删除 | 锁失效，因 TiDB 删除旧表，锁信息也被删除 | / | 被删除分区锁信息清除 | 被删除分区锁信息清除 | 锁信息转移到交换表 | -## 管理 `ANALYZE` 任务与并发度 +## 管理 `ANALYZE` 任务与并发 -本节介绍如何终止后台 `ANALYZE` 任务及控制 `ANALYZE` 并发度。 +本节介绍如何终止后台 `ANALYZE` 任务以及控制 `ANALYZE` 并发度。 ### 终止后台 `ANALYZE` 任务 -自 TiDB v6.0 起，TiDB 支持使用 `KILL` 语句终止后台运行的 `ANALYZE` 任务。如果你发现后台 `ANALYZE` 任务消耗大量资源影响业务，可以按以下步骤终止该任务： +自 TiDB v6.0 起，TiDB 支持使用 `KILL` 语句终止后台运行的 `ANALYZE` 任务。如果你发现后台运行的 `ANALYZE` 任务消耗大量资源，影响业务，可以按以下步骤终止该任务： 1. 执行以下 SQL 语句： @@ -720,20 +720,20 @@ mysql> SHOW WARNINGS; SHOW ANALYZE STATUS ``` - 通过结果中的 `instance` 列和 `process_id` 列，可以获取后台 `ANALYZE` 任务所在 TiDB 实例地址及任务 `ID`。 + 通过结果中的 `instance` 列和 `process_id` 列，可以获取后台 `ANALYZE` 任务所在的 TiDB 实例地址和任务 `ID`。 2. 终止正在后台运行的 `ANALYZE` 任务。 - - 若 [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610) 为 `true`（默认 `true`），可直接执行 `KILL TIDB ${id};`，其中 `${id}` 为上一步获取的后台 `ANALYZE` 任务的 `ID`。 - - 若 `enable-global-kill` 为 `false`，需使用客户端连接到正在执行后台 `ANALYZE` 任务的 TiDB 实例，然后执行 `KILL TIDB ${id};`。若使用客户端连接到其他 TiDB 实例，或客户端与 TiDB 集群间有代理，则 `KILL` 语句无法终止后台 `ANALYZE` 任务。 + - 如果 [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610) 为 `true`（默认 `true`），可直接执行 `KILL TIDB ${id};` 语句，其中 `${id}` 为上一步获取的后台 `ANALYZE` 任务的 `ID`。 + - 如果 `enable-global-kill` 为 `false`，需要使用客户端连接到正在执行后台 `ANALYZE` 任务的 TiDB 实例，然后执行 `KILL TIDB ${id};` 语句。如果使用客户端连接到其他 TiDB 实例，或客户端与 TiDB 集群之间有代理，则 `KILL` 语句无法终止后台 `ANALYZE` 任务。 - 若需终止 `ANALYZE` 任务，可执行 `KILL TIDB ${id};`，其中 `${id}` 为上一步获取的后台 `ANALYZE` 任务的 `ID`。 + 要终止 `ANALYZE` 任务，可执行 `KILL TIDB ${id};` 语句，其中 `${id}` 为上一步获取的后台 `ANALYZE` 任务的 `ID`。 @@ -747,27 +747,27 @@ mysql> SHOW WARNINGS; ![analyze_concurrency](/media/analyze_concurrency.png) -`tidb_build_stats_concurrency`、`tidb_build_sampling_stats_concurrency` 和 `tidb_analyze_partition_concurrency` 之间为上下游关系，如上图所示。实际总并发度为：`tidb_build_stats_concurrency` * (`tidb_build_sampling_stats_concurrency` + `tidb_analyze_partition_concurrency`)。修改这些变量时需同时考虑各自的取值。建议按 `tidb_analyze_partition_concurrency`、`tidb_build_sampling_stats_concurrency`、`tidb_build_stats_concurrency` 的顺序逐一调整，并观察对系统的影响。三者值越大，对系统资源消耗越大。 +`tidb_build_stats_concurrency`、`tidb_build_sampling_stats_concurrency` 和 `tidb_analyze_partition_concurrency` 之间为上下游关系，如上图所示。实际总并发度为：`tidb_build_stats_concurrency` * (`tidb_build_sampling_stats_concurrency` + `tidb_analyze_partition_concurrency`)。修改这些变量时，需要同时考虑各自的取值。建议按 `tidb_analyze_partition_concurrency`、`tidb_build_sampling_stats_concurrency`、`tidb_build_stats_concurrency` 的顺序逐一调整，并观察对系统的影响。这三个变量的值越大，对系统资源的消耗越大。 #### `tidb_build_stats_concurrency` -执行 `ANALYZE` 语句时，任务会被拆分为多个小任务。每个小任务仅处理一个列或索引的统计信息。你可以通过 [`tidb_build_stats_concurrency`](/system-variables.md#tidb_build_stats_concurrency) 变量控制同时运行的小任务数。默认值为 `2`。v7.4.0 及更早版本默认值为 `4`。 +执行 `ANALYZE` 语句时，任务会被拆分为多个小任务。每个小任务只处理一个列或索引的统计信息。你可以通过 [`tidb_build_stats_concurrency`](/system-variables.md#tidb_build_stats_concurrency) 变量控制同时进行的小任务数。默认值为 `2`。v7.4.0 及更早版本默认值为 `4`。 #### `tidb_build_sampling_stats_concurrency` -分析普通列时，可通过 [`tidb_build_sampling_stats_concurrency`](/system-variables.md#tidb_build_sampling_stats_concurrency-new-in-v750) 控制采样任务的并发度。默认值为 `2`。 +分析普通列时，可以通过 [`tidb_build_sampling_stats_concurrency`](/system-variables.md#tidb_build_sampling_stats_concurrency-new-in-v750) 控制采样任务的并发度。默认值为 `2`。 #### `tidb_analyze_partition_concurrency` -执行 `ANALYZE` 语句时，可通过 [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) 控制分区表读写统计信息的并发度。默认值为 `2`。v7.4.0 及更早版本默认值为 `1`。 +执行 `ANALYZE` 语句时，可以通过 [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) 控制分区表读写统计信息的并发度。默认值为 `2`。v7.4.0 及更早版本默认值为 `1`。 #### `tidb_distsql_scan_concurrency` -分析普通列时，可通过 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) 变量控制一次读取的 Region 数量。默认值为 `15`。注意，修改该值会影响查询性能，请谨慎调整。 +分析普通列时，可以通过 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) 变量控制一次读取的 Region 数量。默认值为 `15`。注意，修改该值会影响查询性能，请谨慎调整。 #### `tidb_index_serial_scan_concurrency` -分析索引列时，可通过 [`tidb_index_serial_scan_concurrency`](/system-variables.md#tidb_index_serial_scan_concurrency) 变量控制一次读取的 Region 数量。默认值为 `1`。注意，修改该值会影响查询性能，请谨慎调整。 +分析索引列时，可以通过 [`tidb_index_serial_scan_concurrency`](/system-variables.md#tidb_index_serial_scan_concurrency) 变量控制一次读取的 Region 数量。默认值为 `1`。注意，修改该值会影响查询性能，请谨慎调整。 ## 另请参阅 diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index ce4a6d8080890..3efbaebf9889c 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -23,8 +23,8 @@ TiDB Cloud 让你轻松扩展数据库，处理复杂的管理任务，专注于 -- 在 AWS 上，TiDB Cloud 提供 **TiDB Cloud Starter**，适用于自动扩缩、成本高效的负载；**TiDB Cloud Essential**，适用于具备预配置容量的生产级负载；以及 **TiDB Cloud Dedicated**，为企业级应用提供专属资源和高级能力。 -- 在 Google Cloud 和 Azure 上，TiDB Cloud 提供 **TiDB Cloud Dedicated**，为企业级应用提供专属资源和高级能力。 +- 在 AWS 上，TiDB Cloud 提供 **TiDB Cloud Starter**，适用于自动扩缩、成本高效的负载，**TiDB Cloud Essential**，适用于具备预配置容量的生产级负载，以及 **TiDB Cloud Dedicated**，适用于企业级应用，具备专属资源和高级能力。 +- 在 Google Cloud 和 Azure 上，TiDB Cloud 提供 **TiDB Cloud Dedicated**，适用于企业级应用，具备专属资源和高级能力。 - 在阿里云上，TiDB Cloud 提供 **TiDB Cloud Starter**，适用于自动扩缩、成本高效的负载，以及 **TiDB Cloud Essential**，适用于具备预配置容量的生产级负载。 @@ -38,27 +38,27 @@ TiDB Cloud 让你轻松扩展数据库，处理复杂的管理任务，专注于 ## TiDB Cloud Starter -TiDB Cloud Starter（原名 Serverless）是一款全托管的多租户 TiDB 服务，提供即开即用、自动扩缩的 MySQL 兼容数据库。 +TiDB Cloud Starter 是一款全托管的多租户 TiDB 服务，提供即开即用、自动扩缩的 MySQL 兼容数据库。 -Starter 集群方案非常适合刚开始使用 TiDB Cloud 的用户。它为开发者和小型团队提供以下特性： +Starter 集群方案非常适合初次使用 TiDB Cloud 的用户。它为开发者和小型团队提供以下特性： - **免费**：该方案完全免费，无需信用卡即可开始使用。 - **存储**：提供初始 5 GiB 的行存储和 5 GiB 的列存储。 -- **请求单位**：包含 5000 万 [请求单位（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 用于数据库操作。 +- **请求单元**：包含 5000 万 [请求单元（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 用于数据库操作。 ## TiDB Cloud Essential -对于负载持续增长、需要实时扩展的应用，Essential 集群方案提供灵活性和性能，助力你的业务增长，具备以下特性： +对于负载持续增长、需要实时扩展的应用，Essential 集群方案提供灵活性和性能，助力你的业务持续发展，具备以下特性： - **增强能力**：包含 Starter 方案的全部能力，并具备处理更大、更复杂负载的能力，以及高级安全特性。 - **自动扩缩**：自动调整存储和计算资源，高效应对不断变化的负载需求。 -- **高可用性**：内置容错和冗余机制，即使在基础设施故障时，也能确保你的应用持续可用且具备弹性。 -- **可预测的定价**：根据存储和计算资源的请求容量单位（RCUs）计费，提供透明、按用量计费的定价模式，随需扩展，按实际使用付费，无隐藏费用。 +- **高可用性**：内置容错和冗余机制，即使在基础设施故障时，也能确保应用的可用性和弹性。 +- **可预测的定价**：根据存储和计算资源的请求容量单元（RCUs）计费，提供透明、按用量计费的定价模式，随需扩展，按实际使用付费，无隐藏费用。 TiDB Cloud Essential 提供两种高可用性选项，以满足不同的运维需求。 -- 默认情况下，选择分区高可用（Zonal High Availability）选项的集群，其所有组件都位于同一可用区，网络延迟更低。 -- 对于需要最大基础设施隔离和冗余的应用，区域高可用（Regional High Availability）选项会将节点分布在多个可用区。 +- 默认情况下，选择分区高可用（Zonal High Availability）选项的集群，其所有组件都位于同一可用区，带来更低的网络延迟。 +- 对于需要最大基础设施隔离和冗余的应用，可以选择区域高可用（Regional High Availability）选项，将节点分布在多个可用区。 更多信息，参见 [TiDB Cloud Starter 和 Essential 的高可用性](/tidb-cloud/serverless-high-availability.md)。 @@ -86,7 +86,7 @@ TiDB Cloud CLI，即 `ticloud`，允许你通过简单命令在终端直接管 ## TiDB Cloud API（Beta） -TiDB Cloud API 是基于 REST 的接口，提供对 TiDB Cloud Starter 和 TiDB Cloud Dedicated 资源的编程访问能力。它支持自动化、高效地管理项目、集群、备份、恢复、数据导入、计费以及 [TiDB Cloud Data Service](/tidb-cloud/data-service-overview.md) 中的其他资源。 +TiDB Cloud API 是基于 REST 的接口，提供对 TiDB Cloud Starter 和 TiDB Cloud Dedicated 资源的编程访问能力。它支持自动化、高效地处理项目、集群、备份、恢复、数据导入、计费以及 [TiDB Cloud Data Service](/tidb-cloud/data-service-overview.md) 中的其他资源管理任务。 更多信息，参见 [TiDB Cloud API 概览](/tidb-cloud/api-overview.md)。 @@ -101,7 +101,7 @@ TiDB Cloud API 是基于 REST 的接口，提供对 TiDB Cloud Starter 和 TiDB [TiDB 节点](/tidb-computing.md) 是无状态的 SQL 层，通过 MySQL 兼容的端点与应用连接。它负责解析、优化 SQL 查询，并生成分布式执行计划。 -你可以部署多个 TiDB 节点以实现水平扩展，承载更高的负载。这些节点通常与负载均衡器（如 TiProxy 或 HAProxy）配合使用，提供无缝接口。TiDB 节点本身不存储数据——它们会将数据请求转发给 TiKV 节点（行存储）或 TiFlash 节点（列存储）。 +你可以部署多个 TiDB 节点以实现水平扩展，承载更高的负载。这些节点通常与负载均衡器（如 TiProxy 或 HAProxy）配合使用，提供无缝的访问接口。TiDB 节点本身不存储数据——它们会将数据请求转发给 TiKV 节点（行存储）或 TiFlash 节点（列存储）。 ### TiKV 节点 @@ -117,16 +117,16 @@ TiDB Cloud API 是基于 REST 的接口，提供对 TiDB Cloud Starter 和 TiDB - **事务支持** - TiKV 节点在键值层面原生支持分布式事务，默认隔离级别为快照隔离（Snapshot Isolation）。 - - TiDB 节点会将 SQL 执行计划转化为对 TiKV 节点 API 的调用，从而实现无缝的 SQL 级事务支持。 + - TiDB 节点将 SQL 执行计划转换为对 TiKV 节点 API 的调用，实现无缝的 SQL 级事务支持。 - **高可用性** - - TiKV 节点中的所有数据都会被复制（默认三副本），以保证数据持久性。 + - TiKV 节点中的所有数据都会被复制（默认 3 副本），以保证数据持久性。 - TiKV 原生支持高可用和自动故障转移，防止节点故障带来的影响。 - **可扩展性与可靠性** - - TiKV 节点设计用于处理不断扩展的数据集，同时保持分布式一致性和容错能力。 + - TiKV 节点设计用于应对不断扩展的数据集，同时保持分布式一致性和容错能力。 ### TiFlash 节点 @@ -136,7 +136,7 @@ TiDB Cloud API 是基于 REST 的接口，提供对 TiDB Cloud Starter 和 TiDB - **列式存储** - TiFlash 节点以列存储格式保存数据，针对分析型查询进行了优化，大幅提升了读密集型负载的性能。 + TiFlash 节点以列式格式存储数据，针对分析型查询进行了优化，大幅提升了读密集型负载的性能。 - **向量检索索引支持** diff --git a/tidb-cloud/changefeed-overview.md b/tidb-cloud/changefeed-overview.md index 116e1619281d6..4c65524c89b07 100644 --- a/tidb-cloud/changefeed-overview.md +++ b/tidb-cloud/changefeed-overview.md @@ -11,7 +11,7 @@ TiDB Cloud changefeed 帮助你将数据从 TiDB Cloud 流式传输到其他数 > > - 目前，TiDB Cloud 每个集群最多只允许创建 100 个 changefeed。 > - 目前，TiDB Cloud 每个 changefeed 最多只允许配置 100 条表过滤规则。 -> - 对于 [TiDB Cloud Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)，暂不支持 changefeed 功能。 +> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，changefeed 功能不可用。 ## 查看 Changefeed 页面 @@ -40,16 +40,16 @@ TiDB Cloud changefeed 帮助你将数据从 TiDB Cloud 流式传输到其他数 1. 进入目标 TiDB 集群的 [**Changefeed**](#view-the-changefeed-page) 页面。 2. 找到你想要查询的 changefeed，在 **Action** 列点击 **...** > **View**。 -3. 你可以在页面的 **Specification** 区域看到当前 TiCDC Replication Capacity Units（RCU）。 +3. 你可以在页面的 **Specification** 区域看到当前的 TiCDC Replication Capacity Units（RCU）。 ## 扩缩容 changefeed -你可以通过扩容或缩容 changefeed 来调整其 TiCDC Replication Capacity Units（RCU）。 +你可以通过扩容或缩容 changefeed 来更改 TiCDC Replication Capacity Units（RCU）。 > **注意：** > -> - 若要对某个集群的 changefeed 进行扩缩容，需确保该集群的所有 changefeed 均为 2023 年 3 月 28 日之后创建。 -> - 如果某个集群存在 2023 年 3 月 28 日之前创建的 changefeed，则该集群的所有 changefeed（包括新建的）均不支持扩缩容。 +> - 若要对集群的 changefeed 进行扩缩容，请确保该集群的所有 changefeed 均为 2023 年 3 月 28 日之后创建。 +> - 如果集群中存在 2023 年 3 月 28 日之前创建的 changefeed，则该集群的所有 changefeed（无论是已有的还是新建的）均不支持扩缩容。 1. 进入目标 TiDB 集群的 [**Changefeed**](#view-the-changefeed-page) 页面。 2. 找到你想要扩缩容的 changefeed，在 **Action** 列点击 **...** > **Scale Up/Down**。 @@ -67,11 +67,11 @@ TiDB Cloud changefeed 帮助你将数据从 TiDB Cloud 流式传输到其他数 > **注意：** > -> TiDB Cloud 目前仅支持在暂停状态下编辑 changefeed。 +> TiDB Cloud 目前仅允许在 changefeed 处于暂停状态时进行编辑。 1. 进入目标 TiDB 集群的 [**Changefeed**](#view-the-changefeed-page) 页面。 2. 找到你想要暂停的 changefeed，在 **Action** 列点击 **...** > **Pause**。 -3. 当 changefeed 状态变为 `Paused` 后，点击 **...** > **Edit** 编辑对应的 changefeed。 +3. 当 changefeed 状态变为 `Paused` 后，点击 **...** > **Edit**，即可编辑对应的 changefeed。 TiDB Cloud 会默认填充 changefeed 配置。你可以修改以下配置项： @@ -80,7 +80,7 @@ TiDB Cloud changefeed 帮助你将数据从 TiDB Cloud 流式传输到其他数 - TiDB Cloud sink：**TiDB Cloud Connection**、**Table Filter** 和 **Event Filter**。 - Cloud storage sink：**Storage Endpoint**、**Table Filter** 和 **Event Filter**。 -4. 编辑配置后，点击 **...** > **Resume** 恢复对应的 changefeed。 +4. 编辑配置后，点击 **...** > **Resume**，恢复对应的 changefeed。 ## 删除 changefeed @@ -89,11 +89,11 @@ TiDB Cloud changefeed 帮助你将数据从 TiDB Cloud 流式传输到其他数 ## Changefeed 计费 -关于 TiDB Cloud 中 changefeed 的计费方式，请参见 [Changefeed 计费](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md)。 +要了解 TiDB Cloud 中 changefeed 的计费方式，请参见 [Changefeed billing](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md)。 ## Changefeed 状态 -复制任务的状态表示复制任务的运行状态。在运行过程中，复制任务可能因错误失败，或被手动暂停、恢复。这些操作会导致复制任务状态的变化。 +复制任务的状态表示复制任务的运行状态。在运行过程中，复制任务可能因错误而失败，或被手动暂停、恢复。这些操作会导致复制任务状态的变化。 各状态说明如下： diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index b94aa091f27d5..a00b31c3f7edb 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -1,16 +1,16 @@ --- title: Sink to Apache Kafka -summary: 本文档介绍如何创建变更订阅（changefeed），将数据从 TiDB Cloud 流式同步到 Apache Kafka。内容包括限制、前置条件，以及为 Apache Kafka 配置变更订阅的步骤。该过程涉及网络连接设置、Kafka ACL 授权权限添加，以及变更订阅规范的配置。 +summary: 本文档介绍如何创建变更订阅（changefeed），将数据从 TiDB Cloud 流式同步到 Apache Kafka。内容包括限制、前置条件，以及为 Apache Kafka 配置变更订阅的步骤。该过程涉及网络连接设置、为 Kafka ACL 授权添加权限，以及配置变更订阅规范。 --- # Sink to Apache Kafka 本文档介绍如何创建变更订阅（changefeed），将数据从 TiDB Cloud 流式同步到 Apache Kafka。 -> **Note:** +> **注意：** > > - 要使用变更订阅功能，请确保你的 TiDB Cloud 专属集群版本为 v6.1.3 或更高版本。 -> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，变更订阅功能不可用。 +> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，变更订阅功能不可用。 ## 限制 @@ -34,87 +34,73 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将数据从 在创建变更订阅将数据流式同步到 Apache Kafka 之前，你需要完成以下前置条件： -- 配置网络连接 -- 添加 Kafka ACL 授权权限 +- 设置网络连接 +- 为 Kafka ACL 授权添加权限 ### 网络 -确保你的 TiDB 集群能够连接到 Apache Kafka 服务。你可以选择以下任一连接方式： +确保你的 TiDB 集群可以连接到 Apache Kafka 服务。你可以选择以下任一连接方式： - Private Connect：适用于避免 VPC CIDR 冲突并满足安全合规要求，但会产生额外的 [Private Data Link Cost](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md#private-data-link-cost)。 -- VPC Peering：作为一种经济高效的选项，但需要管理潜在的 VPC CIDR 冲突和安全问题。 -- Public IP：适用于快速搭建场景。 +- VPC Peering：作为一种性价比较高的选项，但需要管理潜在的 VPC CIDR 冲突和安全问题。 +- Public IP：适用于快速搭建环境。
-Private Connect 利用云服务商的 **Private Link** 或 **Private Service Connect** 技术，使你 VPC 中的资源能够通过私有 IP 地址连接到其他 VPC 中的服务，就像这些服务直接托管在你自己的 VPC 中一样。 +Private Connect 利用云服务商的 **Private Link** 或 **Private Service Connect** 技术，使你 VPC 中的资源能够通过私有 IP 地址连接到其他 VPC 中的服务，就像这些服务直接托管在你的 VPC 内一样。 -TiDB Cloud 目前仅支持自建 Kafka 的 Private Connect，不支持与 MSK、Confluent Kafka 或其他 Kafka SaaS 服务的直接集成。若需通过 Private Connect 连接这些 Kafka SaaS 服务，你可以部署一个 [kafka-proxy](https://github.com/grepplabs/kafka-proxy) 作为中间层，将 Kafka 服务暴露为自建 Kafka。详细示例可参考 [Set Up Self-Hosted Kafka Private Service Connect by Kafka-proxy in Google Cloud](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)。该方案适用于所有 Kafka SaaS 服务。 +TiDB Cloud 目前仅支持自建 Kafka 的 Private Connect。不支持与 MSK、Confluent Kafka 或其他 Kafka SaaS 服务的直接集成。若需通过 Private Connect 连接这些 Kafka SaaS 服务，你可以部署一个 [kafka-proxy](https://github.com/grepplabs/kafka-proxy) 作为中间层，将 Kafka 服务暴露为自建 Kafka。详细示例可参考 [Set Up Self-Hosted Kafka Private Service Connect by Kafka-proxy in Google Cloud](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)。该方案适用于所有 Kafka SaaS 服务。 -- 如果你的 Apache Kafka 服务托管在 AWS，请按照 [Set Up Self-Hosted Kafka Private Link Service in AWS](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md) 配置网络连接。配置完成后，在 TiDB Cloud 控制台创建变更订阅时需提供以下信息： - - - Kafka Advertised Listener Pattern 中的 ID - - Endpoint Service Name - - Bootstrap Ports - -- 如果你的 Apache Kafka 服务托管在 Google Cloud，请按照 [Set Up Self-Hosted Kafka Private Service Connect in Google Cloud](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md) 配置网络连接。配置完成后，在 TiDB Cloud 控制台创建变更订阅时需提供以下信息： - - - Kafka Advertised Listener Pattern 中的 ID - - Service Attachment - - Bootstrap Ports - -- 如果你的 Apache Kafka 服务托管在 Azure，请按照 [Set Up Self-Hosted Kafka Private Link Service in Azure](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md) 配置网络连接。配置完成后，在 TiDB Cloud 控制台创建变更订阅时需提供以下信息： - - - Kafka Advertised Listener Pattern 中的 ID - - Private Link Service 的别名（Alias） - - Bootstrap Ports +- 如果你的 Apache Kafka 服务部署在 AWS，请按照 [Set Up Self-Hosted Kafka Private Link Service in AWS](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md) 配置网络连接并获取 **Bootstrap Ports** 信息，然后参考 [Set Up Private Endpoint for Changefeeds](/tidb-cloud/set-up-sink-private-endpoint.md) 创建私有端点。 +- 如果你的 Apache Kafka 服务部署在 Google Cloud，请按照 [Set Up Self-Hosted Kafka Private Service Connect in Google Cloud](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md) 配置网络连接并获取 **Bootstrap Ports** 信息，然后参考 [Set Up Private Endpoint for Changefeeds](/tidb-cloud/set-up-sink-private-endpoint.md) 创建私有端点。 +- 如果你的 Apache Kafka 服务部署在 Azure，请按照 [Set Up Self-Hosted Kafka Private Link Service in Azure](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md) 配置网络连接并获取 **Bootstrap Ports** 信息，然后参考 [Set Up Private Endpoint for Changefeeds](/tidb-cloud/set-up-sink-private-endpoint.md) 创建私有端点。
-如果你的 Apache Kafka 服务位于没有互联网访问权限的 AWS VPC，请按以下步骤操作： +如果你的 Apache Kafka 服务位于没有互联网访问的 AWS VPC，请按以下步骤操作： 1. 在 Apache Kafka 服务所在 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 2. 修改 Apache Kafka 服务关联的安全组的入站规则。 - 你必须将 TiDB Cloud 集群所在区域的 CIDR 添加到入站规则中。该 CIDR 可在 **VPC Peering** 页面找到。这样可以允许 TiDB 集群的流量访问 Kafka broker。 + 你必须将 TiDB Cloud 集群所在区域的 CIDR 添加到入站规则中。该 CIDR 可在 **VPC Peering** 页面找到。这样可以允许来自 TiDB 集群到 Kafka broker 的流量。 3. 如果 Apache Kafka 的 URL 包含主机名，你需要允许 TiDB Cloud 能够解析 Apache Kafka broker 的 DNS 主机名。 1. 按照 [Enable DNS resolution for a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-dns.html) 的步骤操作。 2. 启用 **Accepter DNS resolution** 选项。 -如果你的 Apache Kafka 服务位于没有互联网访问权限的 Google Cloud VPC，请按以下步骤操作： +如果你的 Apache Kafka 服务位于没有互联网访问的 Google Cloud VPC，请按以下步骤操作： 1. 在 Apache Kafka 服务所在 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 2. 修改 Apache Kafka 所在 VPC 的 ingress 防火墙规则。 - 你必须将 TiDB Cloud 集群所在区域的 CIDR 添加到 ingress 防火墙规则中。该 CIDR 可在 **VPC Peering** 页面找到。这样可以允许 TiDB 集群的流量访问 Kafka broker。 + 你必须将 TiDB Cloud 集群所在区域的 CIDR 添加到 ingress 防火墙规则中。该 CIDR 可在 **VPC Peering** 页面找到。这样可以允许来自 TiDB 集群到 Kafka broker 的流量。
如果你希望通过 Public IP 访问 Apache Kafka 服务，请为所有 Kafka broker 分配 Public IP 地址。 -在生产环境中**不推荐**使用 Public IP。 +**不建议**在生产环境中使用 Public IP。
### Kafka ACL 授权 -为了允许 TiDB Cloud 变更订阅将数据流式同步到 Apache Kafka 并自动创建 Kafka topic，请确保在 Kafka 中添加以下权限： +为了让 TiDB Cloud 变更订阅能够将数据流式同步到 Apache Kafka 并自动创建 Kafka topic，请确保在 Kafka 中添加以下权限： -- 为 Kafka 的 topic 资源类型添加 `Create` 和 `Write` 权限。 -- 为 Kafka 的 cluster 资源类型添加 `DescribeConfigs` 权限。 +- 为 topic 资源类型添加 `Create` 和 `Write` 权限。 +- 为 cluster 资源类型添加 `DescribeConfigs` 权限。 例如，如果你的 Kafka 集群在 Confluent Cloud，可以参考 Confluent 文档中的 [Resources](https://docs.confluent.io/platform/current/kafka/authorization.html#resources) 和 [Adding ACLs](https://docs.confluent.io/platform/current/kafka/authorization.html#adding-acls) 获取更多信息。 ## 第 1 步：打开 Apache Kafka 的 Changefeed 页面 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com)。 -2. 进入目标 TiDB 集群的集群概览页面，然后点击左侧导航栏的 **Data** > **Changefeed**。 +2. 进入目标 TiDB 集群的集群总览页面，然后点击左侧导航栏的 **Data** > **Changefeed**。 3. 点击 **Create Changefeed**，并选择 **Kafka** 作为 **Destination**。 ## 第 2 步：配置变更订阅目标 @@ -124,89 +110,81 @@ TiDB Cloud 目前仅支持自建 Kafka 的 Private Connect，不支持与 MSK、
-1. 在 **Connectivity Method** 中选择 **VPC Peering** 或 **Public IP**，填写你的 Kafka broker endpoint。多个 endpoint 可用英文逗号 `,` 分隔。 -2. 根据你的 Kafka 认证配置选择 **Authentication** 选项。 +1. 在 **Connectivity Method** 选择 **VPC Peering** 或 **Public IP**，填写你的 Kafka broker 端点。多个端点可用英文逗号 `,` 分隔。 +2. 根据你的 Kafka 认证配置，选择 **Authentication** 选项。 - 如果 Kafka 不需要认证，保持默认选项 **Disable**。 - 如果 Kafka 需要认证，选择相应的认证类型，并填写 Kafka 账号的 **user name** 和 **password**。 3. 选择你的 **Kafka Version**。如果不确定，建议选择 **Kafka v2**。 -4. 选择本次变更订阅的数据 **Compression** 类型。 -5. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，则启用 **TLS Encryption** 选项。 +4. 选择本变更订阅的数据 **Compression** 类型。 +5. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，请启用 **TLS Encryption** 选项。 6. 点击 **Next** 测试网络连接。测试通过后会进入下一页面。
-1. 在 **Connectivity Method** 中选择 **Private Link**。 -2. 授权 TiDB Cloud 的 [AWS Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-accounts) 为你的 endpoint service 创建 endpoint。AWS Principal 信息可在网页提示中获取。 -3. 确保在 **Network** 部分 [Set Up Self-Hosted Kafka Private Link Service in AWS](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md) 时，选择了相同的 **Number of AZs**、**AZ IDs of Kafka Deployment**，并在 **Kafka Advertised Listener Pattern** 中填写了相同的唯一 ID。 -4. 填写在 [Set Up Self-Hosted Kafka Private Link Service in AWS](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md) 配置的 **Endpoint Service Name**。 -5. 填写 **Bootstrap Ports**。建议每个 AZ 至少设置一个端口，多个端口可用英文逗号 `,` 分隔。 -6. 根据你的 Kafka 认证配置选择 **Authentication** 选项。 +1. 在 **Connectivity Method** 选择 **Private Link**。 +2. 在 **Private Endpoint** 选择你在 [Network](#network) 部分创建的私有端点。确保私有端点的 AZ 与 Kafka 部署的 AZ 匹配。 +3. 填写你在 [Network](#network) 部分获取的 **Bootstrap Ports**。建议每个 AZ 至少设置一个端口。多个端口可用英文逗号 `,` 分隔。 +4. 根据你的 Kafka 认证配置，选择 **Authentication** 选项。 - 如果 Kafka 不需要认证，保持默认选项 **Disable**。 - 如果 Kafka 需要认证，选择相应的认证类型，并填写 Kafka 账号的 **user name** 和 **password**。 - -7. 选择你的 **Kafka Version**。如果不确定，建议选择 **Kafka v2**。 -8. 选择本次变更订阅的数据 **Compression** 类型。 -9. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，则启用 **TLS Encryption** 选项。 -10. 点击 **Next** 测试网络连接。测试通过后会进入下一页面。 -11. TiDB Cloud 会为 **Private Link** 创建 endpoint，可能需要几分钟时间。 -12. endpoint 创建完成后，登录你的云服务商控制台并接受连接请求。 -13. 返回 [TiDB Cloud 控制台](https://tidbcloud.com) 确认你已接受连接请求。TiDB Cloud 会测试连接，测试通过后进入下一页面。 +5. 选择你的 **Kafka Version**。如果不确定，建议选择 **Kafka v2**。 +6. 选择本变更订阅的数据 **Compression** 类型。 +7. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，请启用 **TLS Encryption** 选项。 +8. 点击 **Next** 测试网络连接。测试通过后会进入下一页面。 +9. TiDB Cloud 会为 **Private Link** 创建端点，可能需要几分钟时间。 +10. 端点创建完成后，登录你的云服务商控制台，接受连接请求。 +11. 返回 [TiDB Cloud 控制台](https://tidbcloud.com) 确认你已接受连接请求。TiDB Cloud 会测试连接，测试通过后进入下一页面。
-1. 在 **Connectivity Method** 中选择 **Private Service Connect**。 -2. 确保在 **Network** 部分 [Set Up Self-Hosted Kafka Private Service Connect in Google Cloud](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md) 时，在 **Kafka Advertised Listener Pattern** 中填写了相同的唯一 ID。 -3. 填写在 [Setup Self Hosted Kafka Private Service Connect in Google Cloud](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md) 配置的 **Service Attachment**。 -4. 填写 **Bootstrap Ports**。建议提供多个端口，多个端口可用英文逗号 `,` 分隔。 -5. 根据你的 Kafka 认证配置选择 **Authentication** 选项。 +1. 在 **Connectivity Method** 选择 **Private Service Connect**。 +2. 在 **Private Endpoint** 选择你在 [Network](#network) 部分创建的私有端点。 +3. 填写你在 [Network](#network) 部分获取的 **Bootstrap Ports**。建议提供多个端口。多个端口可用英文逗号 `,` 分隔。 +4. 根据你的 Kafka 认证配置，选择 **Authentication** 选项。 - 如果 Kafka 不需要认证，保持默认选项 **Disable**。 - 如果 Kafka 需要认证，选择相应的认证类型，并填写 Kafka 账号的 **user name** 和 **password**。 - -6. 选择你的 **Kafka Version**。如果不确定，建议选择 **Kafka v2**。 -7. 选择本次变更订阅的数据 **Compression** 类型。 -8. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，则启用 **TLS Encryption** 选项。 -9. 点击 **Next** 测试网络连接。测试通过后会进入下一页面。 -10. TiDB Cloud 会为 **Private Service Connect** 创建 endpoint，可能需要几分钟时间。 -11. endpoint 创建完成后，登录你的云服务商控制台并接受连接请求。 -12. 返回 [TiDB Cloud 控制台](https://tidbcloud.com) 确认你已接受连接请求。TiDB Cloud 会测试连接，测试通过后进入下一页面。 +5. 选择你的 **Kafka Version**。如果不确定，建议选择 **Kafka v2**。 +6. 选择本变更订阅的数据 **Compression** 类型。 +7. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，请启用 **TLS Encryption** 选项。 +8. 点击 **Next** 测试网络连接。测试通过后会进入下一页面。 +9. TiDB Cloud 会为 **Private Service Connect** 创建端点，可能需要几分钟时间。 +10. 端点创建完成后，登录你的云服务商控制台，接受连接请求。 +11. 返回 [TiDB Cloud 控制台](https://tidbcloud.com) 确认你已接受连接请求。TiDB Cloud 会测试连接，测试通过后进入下一页面。
-1. 在 **Connectivity Method** 中选择 **Private Link**。 -2. 在创建变更订阅前，授权 TiDB Cloud 的 Azure 订阅，或允许任何拥有你别名的人访问你的 Private Link 服务。Azure 订阅信息可在网页的 **Reminders before proceeding** 提示中获取。关于 Private Link 服务可见性，详见 Azure 文档 [Control service exposure](https://learn.microsoft.com/en-us/azure/private-link/private-link-service-overview#control-service-exposure)。 -3. 确保在 **Network** 部分 [Set Up Self-Hosted Kafka Private Link Service in Azure](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md) 时，在 **Kafka Advertised Listener Pattern** 中填写了相同的唯一 ID。 -4. 填写在 [Set Up Self-Hosted Kafka Private Link Service in Azure](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md) 配置的 **Alias of Private Link Service**。 -5. 填写 **Bootstrap Ports**。建议每个 AZ 至少设置一个端口，多个端口可用英文逗号 `,` 分隔。 -6. 根据你的 Kafka 认证配置选择 **Authentication** 选项。 +1. 在 **Connectivity Method** 选择 **Private Link**。 +2. 在 **Private Endpoint** 选择你在 [Network](#network) 部分创建的私有端点。 +3. 填写你在 [Network](#network) 部分获取的 **Bootstrap Ports**。建议每个 AZ 至少设置一个端口。多个端口可用英文逗号 `,` 分隔。 +4. 根据你的 Kafka 认证配置，选择 **Authentication** 选项。 - 如果 Kafka 不需要认证，保持默认选项 **Disable**。 - 如果 Kafka 需要认证，选择相应的认证类型，并填写 Kafka 账号的 **user name** 和 **password**。 - -7. 选择你的 **Kafka Version**。如果不确定，建议选择 **Kafka v2**。 -8. 选择本次变更订阅的数据 **Compression** 类型。 -9. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，则启用 **TLS Encryption** 选项。 -10. 点击 **Next** 测试网络连接。测试通过后会进入下一页面。 -11. TiDB Cloud 会为 **Private Link** 创建 endpoint，可能需要几分钟时间。 -12. endpoint 创建完成后，登录 [Azure portal](https://portal.azure.com/) 并接受连接请求。 -13. 返回 [TiDB Cloud 控制台](https://tidbcloud.com) 确认你已接受连接请求。TiDB Cloud 会测试连接，测试通过后进入下一页面。 +5. 选择你的 **Kafka Version**。如果不确定，建议选择 **Kafka v2**。 +6. 选择本变更订阅的数据 **Compression** 类型。 +7. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，请启用 **TLS Encryption** 选项。 +8. 点击 **Next** 测试网络连接。测试通过后会进入下一页面。 +9. TiDB Cloud 会为 **Private Link** 创建端点，可能需要几分钟时间。 +10. 端点创建完成后，登录 [Azure portal](https://portal.azure.com/) 并接受连接请求。 +11. 返回 [TiDB Cloud 控制台](https://tidbcloud.com) 确认你已接受连接请求。TiDB Cloud 会测试连接，测试通过后进入下一页面。
## 第 3 步：设置变更订阅 -1. 自定义 **Table Filter**，筛选你希望同步的表。规则语法详见 [table filter rules](/table-filter.md)。 +1. 自定义 **Table Filter**，筛选你希望同步的表。规则语法可参考 [table filter rules](/table-filter.md)。 - **Case Sensitive**：你可以设置过滤规则中数据库和表名的匹配是否区分大小写。默认情况下，匹配不区分大小写。 - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则后，TiDB Cloud 会查询 TiDB 中所有表，并在右侧仅显示匹配规则的表。最多可添加 100 条过滤规则。 - - **Tables with valid keys**：此列显示具有有效键（主键或唯一索引）的表。 + - **Tables with valid keys**：此列显示具有有效键（包括主键或唯一索引）的表。 - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步时存在挑战，因为缺少唯一标识符可能导致下游处理重复事件时数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一键或主键，或通过过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 2. 自定义 **Event Filter**，筛选你希望同步的事件。 @@ -218,83 +196,83 @@ TiDB Cloud 目前仅支持自建 Kafka 的 Private Connect，不支持与 MSK、 - **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 delete value expression**：排除满足指定条件的 `DELETE` 语句。例如，`name = 'john'` 排除 `name` 为 `'john'` 的 `DELETE` 语句。 3. 自定义 **Column Selector**，选择事件中的列，仅将这些列的数据变更发送到下游。 - **Tables matching**：指定列选择器应用于哪些表。未匹配任何规则的表将发送所有列。 - - **Column Selector**：指定匹配表中将发送到下游的列。 + - **Column Selector**：指定匹配表中哪些列会被发送到下游。 - 关于匹配规则的更多信息，参见 [Column selectors](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-kafka/#column-selectors)。 + 更多匹配规则说明，参见 [Column selectors](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-kafka/#column-selectors)。 4. 在 **Data Format** 区域，选择你期望的 Kafka 消息格式。 - - Avro 是一种紧凑、高效的二进制数据格式，支持丰富的数据结构，广泛应用于各种流式系统。详见 [Avro data format](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)。 + - Avro 是一种紧凑、高效的二进制数据格式，支持丰富的数据结构，广泛应用于各类流式系统。详见 [Avro data format](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)。 - Canal-JSON 是一种纯 JSON 文本格式，易于解析。详见 [Canal-JSON data format](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)。 - - Open Protocol 是一种行级数据变更通知协议，可为监控、缓存、全文索引、分析引擎及不同数据库间主从复制等场景提供数据源。详见 [Open Protocol data format](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)。 + - Open Protocol 是一种行级数据变更通知协议，为监控、缓存、全文索引、分析引擎以及不同数据库间主从复制等场景提供数据源。详见 [Open Protocol data format](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)。 - Debezium 是一个捕获数据库变更的工具。它将每个捕获到的数据库变更转换为一个称为“事件”的消息，并将这些事件发送到 Kafka。详见 [Debezium data format](https://docs.pingcap.com/tidb/stable/ticdc-debezium)。 -5. 如果你希望在 Kafka 消息体中添加 TiDB 扩展字段，可启用 **TiDB Extension** 选项。 +5. 如果你希望在 Kafka 消息体中添加 TiDB 扩展字段，请启用 **TiDB Extension** 选项。 - 关于 TiDB 扩展字段的更多信息，参见 [Avro 数据格式中的 TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol#tidb-extension-fields) 和 [Canal-JSON 数据格式中的 TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)。 + 有关 TiDB 扩展字段的更多信息，参见 [Avro 数据格式中的 TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol#tidb-extension-fields) 和 [Canal-JSON 数据格式中的 TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)。 6. 如果你选择 **Avro** 作为数据格式，页面会显示一些 Avro 专属配置。你可以按如下方式填写： - 在 **Decimal** 和 **Unsigned BigInt** 配置项中，指定 TiDB Cloud 如何在 Kafka 消息中处理 decimal 和 unsigned bigint 数据类型。 - - 在 **Schema Registry** 区域，填写你的 schema registry endpoint。如果启用 **HTTP Authentication**，会显示用户名和密码字段，并自动填入 TiDB 集群 endpoint 和密码。 + - 在 **Schema Registry** 区域，填写你的 schema registry 端点。如果启用 **HTTP Authentication**，会显示用户名和密码字段，并自动填入 TiDB 集群的端点和密码。 7. 在 **Topic Distribution** 区域，选择分发模式，并根据所选模式填写 topic 名称配置。 如果你选择 **Avro** 作为数据格式，则只能在 **Distribution Mode** 下拉列表中选择 **Distribute changelogs by table to Kafka Topics** 模式。 - 分发模式控制变更订阅如何创建 Kafka topic，可以按表、按数据库，或将所有变更日志发送到同一个 topic。 + 分发模式控制变更订阅如何创建 Kafka topic：按表、按库，或所有变更日志共用一个 topic。 - **Distribute changelogs by table to Kafka Topics** - 如果你希望为每个表创建专用的 Kafka topic，选择此模式。这样，某个表的所有 Kafka 消息都会发送到专用 topic。你可以通过设置 topic 前缀、数据库名与表名之间的分隔符、后缀自定义 topic 名称。例如，分隔符设置为 `_` 时，topic 名称格式为 `_`。 + 如果你希望为每个表创建一个专用的 Kafka topic，请选择此模式。这样，某个表的所有 Kafka 消息都会发送到该表专用的 Kafka topic。你可以通过设置 topic 前缀、数据库名与表名之间的分隔符以及后缀自定义 topic 名称。例如，分隔符设置为 `_` 时，topic 名称格式为 `_`。 - 对于非行级事件（如 Create Schema Event）的变更日志，可以在 **Default Topic Name** 字段指定 topic 名称，变更订阅会相应创建 topic 收集这些变更日志。 + 对于非行级事件（如 Create Schema Event）的变更日志，你可以在 **Default Topic Name** 字段指定 topic 名称，变更订阅会相应创建 topic 收集这些变更日志。 - **Distribute changelogs by database to Kafka Topics** - 如果你希望为每个数据库创建专用的 Kafka topic，选择此模式。这样，某个数据库的所有 Kafka 消息都会发送到专用 topic。你可以通过设置 topic 前缀和后缀自定义数据库的 topic 名称。 + 如果你希望为每个数据库创建一个专用的 Kafka topic，请选择此模式。这样，某个数据库的所有 Kafka 消息都会发送到该数据库专用的 Kafka topic。你可以通过设置 topic 前缀和后缀自定义数据库的 topic 名称。 - 对于非行级事件（如 Resolved Ts Event）的变更日志，可以在 **Default Topic Name** 字段指定 topic 名称，变更订阅会相应创建 topic 收集这些变更日志。 + 对于非行级事件（如 Resolved Ts Event）的变更日志，你可以在 **Default Topic Name** 字段指定 topic 名称，变更订阅会相应创建 topic 收集这些变更日志。 - **Send all changelogs to one specified Kafka Topic** - 如果你希望所有变更日志都发送到同一个 Kafka topic，选择此模式。这样，变更订阅中的所有 Kafka 消息都会发送到一个 topic。你可以在 **Topic Name** 字段定义 topic 名称。 + 如果你希望所有变更日志共用一个 Kafka topic，请选择此模式。这样，变更订阅中的所有 Kafka 消息都会发送到同一个 Kafka topic。你可以在 **Topic Name** 字段定义 topic 名称。 -8. 在 **Partition Distribution** 区域，你可以决定 Kafka 消息将被发送到哪个分区。你可以为所有表定义**单一分区分发器**，也可以为不同表定义**不同的分区分发器**。TiDB Cloud 提供四种分发器类型： +8. 在 **Partition Distribution** 区域，你可以决定 Kafka 消息将被发送到哪个分区。你可以为所有表定义 **单一分区分发器**，也可以为不同表定义 **不同的分区分发器**。TiDB Cloud 提供四种分发器类型： - **Distribute changelogs by primary key or index value to Kafka partition** - 如果你希望将某个表的 Kafka 消息分发到不同分区，选择此方式。行变更日志的主键或索引值将决定其被发送到哪个分区。该方式可实现更好的分区均衡，并保证行级有序性。 + 如果你希望将某个表的 Kafka 消息分发到不同分区，请选择此方式。行变更日志的主键或索引值将决定其被发送到哪个分区。该方式可实现更好的分区均衡，并保证行级有序性。 - **Distribute changelogs by table to Kafka partition** - 如果你希望将某个表的 Kafka 消息全部发送到同一个分区，选择此方式。行变更日志的表名将决定其被发送到哪个分区。该方式保证表级有序性，但可能导致分区不均衡。 + 如果你希望将某个表的 Kafka 消息全部发送到同一个分区，请选择此方式。行变更日志的表名将决定其被发送到哪个分区。该方式保证表级有序性，但可能导致分区不均衡。 - **Distribute changelogs by timestamp to Kafka partition** - 如果你希望将 Kafka 消息随机分发到不同分区，选择此方式。行变更日志的 commitTs 将决定其被发送到哪个分区。该方式可实现更好的分区均衡，并保证每个分区内有序。但同一数据项的多次变更可能被发送到不同分区，不同消费者的消费进度可能不同，可能导致数据不一致。因此，消费者需在消费前按 commitTs 对多分区数据进行排序。 + 如果你希望将 Kafka 消息随机分发到不同分区，请选择此方式。行变更日志的 commitTs 将决定其被发送到哪个分区。该方式可实现更好的分区均衡，并保证每个分区内的有序性。但同一数据项的多次变更可能被发送到不同分区，不同消费者的消费进度可能不同，可能导致数据不一致。因此，消费者需要在消费前按 commitTs 对多分区数据进行排序。 - **Distribute changelogs by column value to Kafka partition** - 如果你希望将某个表的 Kafka 消息分发到不同分区，选择此方式。行变更日志的指定列值将决定其被发送到哪个分区。该方式保证每个分区内有序，并确保相同列值的变更日志被发送到同一分区。 + 如果你希望将某个表的 Kafka 消息分发到不同分区，请选择此方式。行变更日志的指定列值将决定其被发送到哪个分区。该方式保证每个分区内的有序性，并确保相同列值的变更日志被发送到同一分区。 9. 在 **Topic Configuration** 区域，配置以下数值。变更订阅会根据这些数值自动创建 Kafka topic。 - - **Replication Factor**：控制每条 Kafka 消息被复制到多少台 Kafka 服务器。有效取值范围为 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas) 到 Kafka broker 数量。 + - **Replication Factor**：控制每条 Kafka 消息会被复制到多少台 Kafka 服务器。有效取值范围为 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas) 到 Kafka broker 数量。 - **Partition Number**：控制每个 topic 的分区数。有效取值范围为 `[1, 10 * Kafka broker 数量]`。 -10. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件拆分为单独的 `DELETE` 和 `INSERT` 事件，或保持为原始 `UPDATE` 事件。详见 [Split primary or unique key UPDATE events for non-MySQL sinks](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 +10. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件拆分为单独的 `DELETE` 和 `INSERT` 事件，或保持原始 `UPDATE` 事件。详见 [Split primary or unique key UPDATE events for non-MySQL sinks](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 11. 点击 **Next**。 ## 第 4 步：配置变更订阅规范 -1. 在 **Changefeed Specification** 区域，指定变更订阅使用的 Replication Capacity Units（RCU）数量。 +1. 在 **Changefeed Specification** 区域，指定变更订阅使用的 Replication Capacity Unit（RCU）数量。 2. 在 **Changefeed Name** 区域，为变更订阅指定名称。 3. 点击 **Next** 检查你设置的配置，并进入下一页面。 diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index c07becc6d764c..794215a6b9d30 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -5,19 +5,19 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 # Sink to Apache Pulsar -本文档介绍如何创建变更订阅（changefeed），以将数据从 TiDB Cloud 流式传输到 Apache Pulsar。 +本文档描述了如何创建变更订阅（changefeed），以将数据从 TiDB Cloud 流式传输到 Apache Pulsar。 > **Note:** > -> - 若要使用变更订阅功能将数据同步到 Apache Pulsar，请确保你的 TiDB Cloud Dedicated 集群版本为 v7.5.1 或更高版本。 -> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，变更订阅功能不可用。 +> - 若要使用变更订阅功能将数据同步到 Apache Pulsar，请确保你的 TiDB Cloud Dedicated 集群版本为 v7.5.1 或更高。 +> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，变更订阅功能不可用。 ## 限制条件 - 每个 TiDB Cloud 集群最多可创建 100 个变更订阅。 - 目前，TiDB Cloud 不支持上传自签名 TLS 证书以连接到 Pulsar broker。 - 由于 TiDB Cloud 使用 TiCDC 建立变更订阅，因此具有与 [TiCDC 相同的限制](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)。 -- 如果待同步的表没有主键或非空唯一索引，在某些重试场景下，由于缺乏唯一约束，可能会导致下游插入重复数据。 +- 如果待同步的表没有主键或非空唯一索引，在某些重试场景下，由于缺少唯一约束，可能会导致下游插入重复数据。 - 目前，TiCDC 不会自动创建 Pulsar topic。在向 topic 分发事件之前，请确保该 topic 已在 Pulsar 中存在。 ## 前置条件 @@ -40,29 +40,29 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 如果你的 Apache Pulsar 服务部署在没有互联网访问权限的 AWS VPC 中，请按照以下步骤操作： -1. 在 Apache Pulsar 服务所在的 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 +1. 在 Apache Pulsar 服务所在 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 2. 修改 Apache Pulsar 服务关联的安全组的入站规则。 - 你需要将 TiDB Cloud 集群所在区域的 CIDR 添加到入站规则中。该 CIDR 可在 **VPC Peering** 页面找到。这样可以允许来自 TiDB 集群到 Pulsar broker 的流量。 + 你需要将 TiDB Cloud 集群所在区域的 CIDR 添加到入站规则中。该 CIDR 可在 **VPC Peering** 页面找到。这样可以允许来自 TiDB 集群的流量访问 Pulsar broker。 -3. 如果 Apache Pulsar 的 URL 包含主机名，你需要允许 TiDB Cloud 解析 Apache Pulsar broker 的 DNS 主机名。 +3. 如果 Apache Pulsar URL 包含主机名，你需要允许 TiDB Cloud 解析 Apache Pulsar broker 的 DNS 主机名。 - 1. 按照 [为 VPC Peering 连接启用 DNS 解析](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-dns.html) 的步骤操作。 + 1. 按照 [为 VPC Peering 连接启用 DNS 解析](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-dns.html) 中的步骤操作。 2. 启用 **Accepter DNS resolution** 选项。 如果你的 Apache Pulsar 服务部署在没有互联网访问权限的 Google Cloud VPC 中，请按照以下步骤操作： -1. 在 Apache Pulsar 服务所在的 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 +1. 在 Apache Pulsar 服务所在 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 2. 修改 Apache Pulsar 所在 VPC 的 ingress 防火墙规则。 - 你需要将 TiDB Cloud 集群所在区域的 CIDR 添加到 ingress 防火墙规则中。该 CIDR 可在 **VPC Peering** 页面找到。这样可以允许来自 TiDB 集群到 Pulsar broker 的流量。 + 你需要将 TiDB Cloud 集群所在区域的 CIDR 添加到 ingress 防火墙规则中。该 CIDR 可在 **VPC Peering** 页面找到。这样可以允许来自 TiDB 集群的流量访问 Pulsar broker。
如果你希望通过公网 IP 访问 Apache Pulsar 服务，需要为所有 Pulsar broker 分配公网 IP 地址。 -**不推荐**在生产环境中使用公网 IP。 +**不推荐** 在生产环境中使用公网 IP。
@@ -75,7 +75,7 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 - 若希望每个表的 Pulsar 消息分发到专用 topic，则需为每个需要同步的表，按 `` 格式创建 topic。 - 若希望每个数据库的 Pulsar 消息分发到专用 topic，则需为每个需要同步的数据库，按 `` 格式创建 topic。 -根据你的配置，可能还需要为非行事件（如 schema 变更）准备一个默认 topic。 +根据你的配置，可能还需要为非行事件（如 schema 变更）创建一个默认 topic。 更多信息请参见 Apache Pulsar 官方文档 [How to create a topic](https://pulsar.apache.org/docs/4.0.x/tutorials-topic/)。 @@ -91,14 +91,14 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 2. 在 **Connection** 区域，填写以下信息： - **Destination Protocol**：选择 **Pulsar** 或 **Pulsar+SSL**。 - - **Connectivity Method**：根据你计划如何连接到 Pulsar 端点，选择 **VPC Peering** 或 **Public**。 - - **Pulsar Broker**：填写你的 Pulsar broker 的端点。端口与域名或 IP 地址之间用冒号分隔，例如 `example.org:6650`。 + - **Connectivity Method**：根据你计划连接 Pulsar 的方式，选择 **VPC Peering** 或 **Public**。 + - **Pulsar Broker**：填写你的 Pulsar broker 的 endpoint。端口与域名或 IP 地址之间用冒号分隔，例如 `example.org:6650`。 -3. 在 **Authentication** 区域，根据你的 Pulsar 认证配置选择 **Auth Type** 选项，并根据选择填写所需的凭证信息。 +3. 在 **Authentication** 区域，根据你的 Pulsar 认证配置选择 **Auth Type** 选项。根据选择填写所需的凭证信息。 4. 可选：在 **Advanced Settings** 区域，配置其他高级设置： - - **Compression**：为本变更订阅中的数据选择可选的压缩算法。 - - **Max Messages per Batch** 和 **Max Publish Delay**：指定发送到 Pulsar 的事件消息批量设置。**Max Messages per Batch** 设置每批最大消息数，**Max Publish Delay** 设置发送一批消息前的最大等待时间。 + - **Compression**：为该变更订阅中的数据选择可选的压缩算法。 + - **Max Messages per Batch** 和 **Max Publish Delay**：指定发送到 Pulsar 的事件消息批处理方式。**Max Messages per Batch** 设置每批最大消息数，**Max Publish Delay** 设置发送一批消息前的最大等待时间。 - **Connection Timeout**：调整与 Pulsar 建立 TCP 连接的超时时间。 - **Operation Timeout**：调整使用 TiCDC Pulsar 客户端发起操作的超时时间。 - **Send Timeout**：调整 TiCDC Pulsar producer 发送消息的超时时间。 @@ -110,13 +110,13 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 1. 自定义 **Table Filter**，筛选你希望同步的表。规则语法参见 [table filter rules](/table-filter.md)。 - **Case Sensitive**：你可以设置过滤规则中数据库和表名的匹配是否区分大小写。默认情况下，匹配不区分大小写。 - - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则后，TiDB Cloud 会查询 TiDB 中的所有表，并在右侧框中仅显示符合规则的表。最多可添加 100 条过滤规则。 + - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则后，TiDB Cloud 会查询 TiDB 中所有表，并在右侧框中仅显示匹配规则的表。最多可添加 100 条过滤规则。 - **Tables with valid keys**：此列显示具有有效键（包括主键或唯一索引）的表。 - - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步过程中存在挑战，因为缺乏唯一标识符可能导致下游处理重复事件时数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一键或主键，或通过添加过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 + - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步过程中存在挑战，因为缺少唯一标识符可能导致下游处理重复事件时数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一键或主键，或通过添加过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 2. 自定义 **Event Filter**，筛选你希望同步的事件。 - - **Tables matching**：你可以在此列设置事件过滤器应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个变更订阅最多可添加 10 条事件过滤规则。 + - **Tables matching**：你可以设置事件过滤器应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个变更订阅最多可添加 10 条事件过滤规则。 - **Event Filter**：你可以使用以下事件过滤器从变更订阅中排除特定事件： - **Ignore event**：排除指定类型的事件。 - **Ignore SQL**：排除匹配指定表达式的 DDL 事件。例如，`^drop` 排除以 `DROP` 开头的语句，`add column` 排除包含 `ADD COLUMN` 的语句。 @@ -143,7 +143,7 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 > **Note:** > - > 当你选择 Pulsar 作为下游时，变更订阅不会自动创建 topic。你必须提前创建所需的 topic。 + > 当你选择 Pulsar 作为下游时，变更订阅不会自动创建 topic。你必须提前在 Pulsar 上创建所需的 topic。 - **Send all changelogs to one specified Pulsar Topic** @@ -153,13 +153,13 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 如果你希望变更订阅将每个表的 Pulsar 消息发送到专用 Pulsar topic，请选择此模式。你可以通过设置 **Topic Prefix**、数据库名与表名之间的 **Separator** 以及 **Topic Suffix**，为表指定 topic 名称。例如，若分隔符设置为 `_`，则 Pulsar 消息将发送到名称为 `_` 的 topic。你需要提前在 Pulsar 上创建这些 topic。 - 对于非行事件（如 Create Schema Event）的变更日志，你可以在 **Default Topic Name** 字段中指定 topic 名称。变更订阅会将这些非行事件发送到该 topic 以收集相关变更日志。 + 对于非行事件的变更日志（如 Create Schema Event），你可以在 **Default Topic Name** 字段中指定 topic 名称。变更订阅会将这些非行事件发送到该 topic 以收集相关变更日志。 - **Distribute changelogs by database to Pulsar Topics** 如果你希望变更订阅将每个数据库的 Pulsar 消息发送到专用 Pulsar topic，请选择此模式。你可以通过设置 **Topic Prefix** 和 **Topic Suffix**，为数据库指定 topic 名称。 - 对于非行事件（如 Resolved Ts Event）的变更日志，你可以在 **Default Topic Name** 字段中指定 topic 名称。变更订阅会将这些非行事件发送到该 topic 以收集相关变更日志。 + 对于非行事件的变更日志（如 Resolved Ts Event），你可以在 **Default Topic Name** 字段中指定 topic 名称。变更订阅会将这些非行事件发送到该 topic 以收集相关变更日志。 由于 Pulsar 支持多租户，如果 **Pulsar Tenant** 和 **Pulsar Namespace** 与默认值不同，你也可以进行设置。 @@ -175,11 +175,11 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 - **Timestamp** - 如果你希望变更订阅根据时间戳将 Pulsar 消息分发到不同 Pulsar 分区，请选择此分发方式。行变更日志的 commitTs 决定该变更日志发送到哪个分区。该方式可实现更好的分区均衡，并保证每个分区内的有序性。但同一数据项的多次变更可能被发送到不同分区，不同消费者的消费进度可能不同，可能导致数据不一致。因此，消费者需要在消费前按 commitTs 对来自多个分区的数据进行排序。 + 如果你希望变更订阅根据时间戳将 Pulsar 消息分发到不同 Pulsar 分区，请选择此分发方式。行变更日志的 commitTs 决定该变更日志发送到哪个分区。该方式可实现更好的分区均衡，并保证每个分区内的有序性。但同一数据项的多次变更可能被发送到不同分区，不同消费者的消费进度可能不同，可能导致数据不一致。因此，消费者需要在消费前按 commitTs 对多个分区的数据进行排序。 - **Column value** - 如果你希望变更订阅将表的 Pulsar 消息分发到不同分区，请选择此分发方式。行变更日志中指定的列值将决定该变更日志发送到哪个分区。该方式保证每个分区内的有序性，并确保具有相同列值的变更日志被发送到同一分区。 + 如果你希望变更订阅将表的 Pulsar 消息分发到不同分区，请选择此分发方式。行变更日志中指定的列值将决定该变更日志发送到哪个分区。该方式保证每个分区内的有序性，并确保具有相同列值的变更日志发送到同一分区。 7. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件拆分为独立的 `DELETE` 和 `INSERT` 事件，或保持为原始的 `UPDATE` 事件。更多信息参见 [为非 MySQL sink 拆分主键或唯一键 UPDATE 事件](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 @@ -189,7 +189,7 @@ summary: 本文档介绍如何创建变更订阅（changefeed），以将数据 1. 在 **Specification and Name** 区域： - - 指定该变更订阅的 [Replication Capacity Units (RCUs)](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md) 数量。 + - 为变更订阅指定 [Replication Capacity Units (RCUs)](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md) 数量。 - 输入变更订阅的名称。 2. 审核所有变更订阅配置。 diff --git a/tidb-cloud/changefeed-sink-to-cloud-storage.md b/tidb-cloud/changefeed-sink-to-cloud-storage.md index 067290fff6797..95ebedba0e471 100644 --- a/tidb-cloud/changefeed-sink-to-cloud-storage.md +++ b/tidb-cloud/changefeed-sink-to-cloud-storage.md @@ -10,7 +10,7 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou > **注意：** > > - 若要将数据流式同步到云存储，请确保你的 TiDB 集群版本为 v7.1.1 或更高版本。如需将 TiDB Cloud Dedicated 集群升级到 v7.1.1 或更高版本，请[联系 TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 -> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，变更订阅功能不可用。 +> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，变更订阅功能不可用。 ## 限制 @@ -34,7 +34,7 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou 对于 **GCS**，在填写 **GCS Endpoint** 之前，需要先授予 GCS bucket 访问权限。请按照以下步骤操作： -1. 在 TiDB Cloud 控制台，记录下 **Service Account ID**，该 ID 用于授权 TiDB Cloud 访问你的 GCS bucket。 +1. 在 TiDB Cloud 控制台，记录下 **Service Account ID**，该 ID 用于授予 TiDB Cloud 访问你的 GCS bucket 的权限。 ![gcs_endpoint](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-endpoint.png) @@ -65,7 +65,7 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou 5. 填写以下信息以授予 bucket 访问权限，然后点击 **Save**。 - - 在 **New Principals** 字段中，粘贴之前记录的目标 TiDB 集群的 **Service Account ID**。 + - 在 **New Principals** 字段中，粘贴你之前记录的目标 TiDB 集群的 **Service Account ID**。 - 在 **Select a role** 下拉列表中，输入你刚刚创建的 IAM 角色名称，并从筛选结果中选择该名称。 > **注意：** @@ -101,14 +101,14 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou - **Case Sensitive**：你可以设置过滤规则中数据库和表名的匹配是否区分大小写。默认情况下，匹配不区分大小写。 - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则后，TiDB Cloud 会查询 TiDB 中的所有表，并在右侧框中仅显示符合规则的表。最多可添加 100 条过滤规则。 - **Tables with valid keys**：此列显示具有有效键（包括主键或唯一索引）的表。 - - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这类表在同步过程中存在挑战，因为缺乏唯一标识符，处理下游重复事件时可能导致数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一键或主键，或者通过过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 + - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步过程中存在挑战，因为缺乏唯一标识符，处理下游重复事件时可能导致数据不一致。为确保数据一致性，建议在启动同步前为这些表添加唯一键或主键，或通过过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 2. 自定义 **Event Filter**，筛选你希望同步的事件。 - **Tables matching**：你可以在此列设置事件过滤器应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个变更订阅最多可添加 10 条事件过滤规则。 - **Event Filter**：你可以使用以下事件过滤器，从变更订阅中排除特定事件： - **Ignore event**：排除指定类型的事件。 - - **Ignore SQL**：排除匹配指定表达式的 DDL 事件。例如，`^drop` 排除以 `DROP` 开头的语句，`add column` 排除包含 `ADD COLUMN` 的语句。 + - **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 的更新。 @@ -128,9 +128,9 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou 配置 **CSV** 格式时，需填写以下字段： - **Binary Encode Method**：二进制数据的编码方式。可选择 **base64**（默认）或 **hex**。如需与 AWS DMS 集成，建议选择 **hex**。 - - **Date Separator**：可按年、月、日对数据进行分片，或选择不分片。 + - **Date Separator**：可按年、月、日进行数据轮转，或选择不轮转。 - **Delimiter**：指定 CSV 文件中用于分隔值的字符。逗号（`,`）是最常用的分隔符。 - - **Quote**：指定用于包裹包含分隔符或特殊字符的值的字符。通常使用双引号（`"`）作为包裹字符。 + - **Quote**：指定用于包裹包含分隔符或特殊字符的值的字符。通常使用双引号（`"`）作为引用字符。 - **Null/Empty Values**：指定 CSV 文件中空值或 null 值的表示方式。这对于数据的正确处理和解析非常重要。 - **Include Commit Ts**：控制是否在 CSV 行中包含 [`commit-ts`](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-cloud-storage#replicate-change-data-to-storage-services)。 @@ -139,24 +139,24 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou Canal-JSON 是一种纯文本 JSON 格式。配置时需填写以下字段： - - **Date Separator**：可按年、月、日对数据进行分片，或选择不分片。 - - **Enable TiDB Extension**：启用后，TiCDC 会发送 [WATERMARK 事件](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#watermark-event) 并在 Canal-JSON 消息中添加 [TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)。 + - **Date Separator**：可按年、月、日进行数据轮转，或选择不轮转。 + - **Enable TiDB Extension**：启用后，TiCDC 会发送 [WATERMARK 事件](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#watermark-event)，并在 Canal-JSON 消息中添加 [TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)。
5. 在 **Flush Parameters** 区域，你可以配置以下两项： - - **Flush Interval**：默认设置为 60 秒，可在 2 秒至 10 分钟范围内调整； - - **File Size**：默认设置为 64 MB，可在 1 MB 至 512 MB 范围内调整。 + - **Flush Interval**：默认 60 秒，可在 2 秒到 10 分钟范围内调整； + - **File Size**：默认 64 MB，可在 1 MB 到 512 MB 范围内调整。 ![Flush Parameters](/media/tidb-cloud/changefeed/sink-to-cloud-storage-flush-parameters.jpg) > **注意：** > - > 这两个参数会影响每个数据库表在云存储中生成的对象数量。如果表数量较多，使用相同配置会增加生成对象的数量，从而提升云存储 API 的调用成本。因此，建议根据你的恢复点目标（RPO）和成本需求合理配置这两个参数。 + > 这两个参数会影响每个数据库表在云存储中生成的对象数量。如果表数量较多，使用相同配置会增加生成对象的数量，并相应提高调用云存储 API 的成本。因此，建议根据你的恢复点目标（RPO）和成本需求合理配置这些参数。 -6. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件拆分为单独的 `DELETE` 和 `INSERT` 事件，或保留为原始的 `UPDATE` 事件。更多信息请参见 [Split primary or unique key UPDATE events for non-MySQL sinks](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 +6. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件拆分为单独的 `DELETE` 和 `INSERT` 事件，或保持为原始的 `UPDATE` 事件。更多信息请参见 [Split primary or unique key UPDATE events for non-MySQL sinks](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 ## 步骤 3. 配置规范 diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md index 497304a5abf65..56bcabfb7245d 100644 --- a/tidb-cloud/changefeed-sink-to-mysql.md +++ b/tidb-cloud/changefeed-sink-to-mysql.md @@ -1,64 +1,79 @@ --- title: Sink to MySQL -summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 TiDB Cloud 实时同步到 MySQL。内容包括限制条件、前置条件，以及创建 MySQL sink 进行数据同步的步骤。该过程涉及网络连接配置、将已有数据导入 MySQL 以及在 MySQL 中创建目标表。完成前置条件后，用户即可创建 MySQL sink，将数据同步到 MySQL。 +summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 TiDB Cloud 实时同步到 MySQL。内容包括限制条件、前置条件，以及创建 MySQL sink 进行数据同步的步骤。该过程涉及网络连接设置、将现有数据导入 MySQL 以及在 MySQL 中创建目标表。完成前置条件后，用户即可创建 MySQL sink，将数据同步到 MySQL。 --- # Sink to MySQL -本文档描述了如何使用 **Sink to MySQL** changefeed，将数据从 TiDB Cloud 实时同步到 MySQL。 +本文档介绍如何使用 **Sink to MySQL** changefeed，将数据从 TiDB Cloud 实时同步到 MySQL。 > **注意：** > > - 要使用 changefeed 功能，请确保你的 TiDB Cloud Dedicated 集群版本为 v6.1.3 或更高版本。 -> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，changefeed 功能不可用。 +> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，changefeed 功能不可用。 ## 限制条件 - 每个 TiDB Cloud 集群最多可以创建 100 个 changefeed。 - 由于 TiDB Cloud 使用 TiCDC 建立 changefeed，因此具有与 [TiCDC 相同的限制](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)。 -- 如果需要同步的表没有主键或非空唯一索引，在某些重试场景下，由于缺少唯一约束，可能会导致下游插入重复数据。 +- 如果待同步的表没有主键或非空唯一索引，在某些重试场景下，由于缺少唯一约束，可能会导致下游插入重复数据。 ## 前置条件 在创建 changefeed 之前，你需要完成以下前置条件： -- 配置网络连接 -- 导出并导入已有数据到 MySQL（可选） -- 如果你不导入已有数据，仅希望同步增量数据到 MySQL，则需要在 MySQL 中手动创建对应的目标表 +- 设置网络连接 +- 导出并加载现有数据到 MySQL（可选） +- 如果你不加载现有数据，仅希望同步增量数据到 MySQL，则需要在 MySQL 中手动创建对应的目标表 ### 网络 -确保你的 TiDB 集群能够连接到 MySQL 服务。 +确保你的 TiDB Cloud 集群能够连接到 MySQL 服务。 + + +
如果你的 MySQL 服务位于没有公网访问权限的 AWS VPC 中，请按照以下步骤操作： -1. 在 MySQL 服务所在 VPC 与 TiDB 集群之间 [建立 VPC 对等连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 +1. 在 MySQL 服务所在的 VPC 与 TiDB 集群之间 [建立 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 对等连接启用 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 对等连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 +2. 在 MySQL 服务所在的 VPC 与 TiDB 集群之间 [建立 VPC Peering 连接](/tidb-cloud/set-up-vpc-peering-connections.md)。 3. 修改 MySQL 所在 VPC 的入站防火墙规则。 - 你必须将 [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 Cloud 集群的流量访问 MySQL 端点。 + +
+ +
+ +私有端点利用云服务商的 **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) 创建一个私有端点。 -### 导入已有数据（可选） +
-**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** 所需的时间 例如： @@ -67,11 +82,11 @@ summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 T 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 @@ -83,7 +98,7 @@ summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 T ### 在 MySQL 中创建目标表 -如果你没有导入已有数据，需要在 MySQL 中手动创建对应的目标表，用于存储来自 TiDB 的增量数据。否则，数据将无法被同步。 +如果你没有加载现有数据，需要在 MySQL 中手动创建对应的目标表，用于存储来自 TiDB 的增量数据。否则，数据将无法同步。 ## 创建 MySQL sink @@ -93,23 +108,28 @@ summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 T 2. 点击 **Create Changefeed**，并选择 **MySQL** 作为 **Destination**。 -3. 在 **MySQL Connection** 中填写 MySQL 的端点、用户名和密码。 +3. 在 **Connectivity Method** 中，选择连接 MySQL 服务的方法。 + + - 如果选择 **VPC Peering** 或 **Public IP**，请填写你的 MySQL 端点。 + - 如果选择 **Private Link**，请选择你在 [网络](#network) 部分创建的私有端点，并填写 MySQL 服务的端口。 + +4. 在 **Authentication** 中，填写 MySQL 服务的用户名和密码。 -4. 点击 **Next**，测试 TiDB 是否可以成功连接到 MySQL： +5. 点击 **Next** 测试 TiDB 是否能够成功连接到 MySQL： - - 如果可以连接，将进入下一步配置。 - - 如果连接失败，会显示连接错误，你需要处理该错误。错误解决后，重新点击 **Next**。 + - 如果连接成功，将进入下一步配置。 + - 如果连接失败，会显示连接错误，你需要排查并解决问题。解决后再次点击 **Next**。 -5. 自定义 **Table Filter**，筛选你希望同步的表。规则语法详见 [table filter rules](/table-filter.md)。 +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`。 -6. 自定义 **Event Filter**，筛选你希望同步的事件。 +7. 自定义 **Event Filter**，筛选你希望同步的事件。 - - **Tables matching**：你可以在此列设置事件过滤器应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个 changefeed 最多可添加 10 条事件过滤规则。 + - **Tables matching**：你可以设置事件过滤器应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个 changefeed 最多可添加 10 条事件过滤规则。 - **Event Filter**：你可以使用以下事件过滤器，从 changefeed 中排除特定事件： - **Ignore event**：排除指定类型的事件。 - **Ignore SQL**：排除匹配指定表达式的 DDL 事件。例如，`^drop` 排除以 `DROP` 开头的语句，`add column` 排除包含 `ADD COLUMN` 的语句。 @@ -118,28 +138,28 @@ summary: 本文档介绍如何使用 **Sink to MySQL** changefeed 将数据从 T - **Ignore update old value expression**：排除旧值满足指定条件的 `UPDATE` 语句。例如，`age < 18` 排除旧值 `age` 小于 18 的更新操作。 - **Ignore delete value expression**：排除满足指定条件的 `DELETE` 语句。例如，`name = 'john'` 排除 `name` 为 `'john'` 的 `DELETE` 语句。 -7. 在 **Start Replication Position** 中，配置 MySQL sink 的起始同步位置。 +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**。 + - 如果你已通过 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**，自定义起始时间点。 -8. 点击 **Next**，配置 changefeed 规格。 +9. 点击 **Next** 配置 changefeed 规格。 - - 在 **Changefeed Specification** 区域，指定 changefeed 使用的 Replication Capacity Units（RCUs）数量。 + - 在 **Changefeed Specification** 区域，指定 changefeed 使用的 Replication Capacity Units（RCU）数量。 - 在 **Changefeed Name** 区域，指定 changefeed 的名称。 -9. 点击 **Next**，检查 changefeed 配置。 +10. 点击 **Next**，检查 changefeed 配置。 如果确认所有配置无误，勾选跨区域同步合规性，并点击 **Create**。 - 如果需要修改某些配置，点击 **Previous** 返回上一步配置页面。 + 如果需要修改配置，点击 **Previous** 返回上一步。 -10. sink 很快会启动，你可以看到 sink 的状态从 **Creating** 变为 **Running**。 +11. sink 很快会启动，你可以看到 sink 状态从 **Creating** 变为 **Running**。 - 点击 changefeed 名称，可以查看更多 changefeed 详情，如 checkpoint、同步延迟及其他指标。 + 点击 changefeed 名称，可以查看更多关于 changefeed 的详细信息，如 checkpoint、同步延迟及其他指标。 -11. 如果你已通过 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/connect-via-sql-shell.md b/tidb-cloud/connect-via-sql-shell.md index 643f2b748db70..2e6b667c50450 100644 --- a/tidb-cloud/connect-via-sql-shell.md +++ b/tidb-cloud/connect-via-sql-shell.md @@ -9,9 +9,9 @@ summary: 了解如何通过 SQL Shell 连接到你的 TiDB 集群。 > **注意：** > -> 你无法使用 SQL Shell 连接到 [TiDB Cloud Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)。要连接到你的 TiDB Cloud Serverless 集群，请参阅 [连接到 TiDB Cloud Serverless 集群](/tidb-cloud/connect-to-tidb-cluster-serverless.md)。 +> 你无法使用 SQL Shell 连接到 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 或 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)。如需连接到你的 TiDB Cloud Starter 或 TiDB Cloud Essential 集群，请参阅 [Connect to TiDB Cloud Starter or Essential Cluster](/tidb-cloud/connect-to-tidb-cluster-serverless.md)。 -要使用 SQL shell 连接到你的 TiDB 集群，请按照以下步骤操作： +要使用 SQL shell 连接到你的 TiDB 集群，请执行以下步骤： 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，并导航到你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 @@ -21,4 +21,4 @@ summary: 了解如何通过 SQL Shell 连接到你的 TiDB 集群。 2. 点击目标集群的名称，进入该集群的概览页面，然后点击左侧导航栏中的 **Settings** > **Networking**。 3. 在 **Networking** 页面，点击右上角的 **Web SQL Shell**。 -4. 在弹出的 **Enter password** 行中，输入当前集群的 root 密码。然后你的应用就会连接到 TiDB 集群。 \ No newline at end of file +4. 在弹出的 **Enter password** 行中，输入当前集群的 root 密码。然后你的应用程序就会连接到 TiDB 集群。 \ No newline at end of file diff --git a/tidb-cloud/create-tidb-cluster-serverless.md b/tidb-cloud/create-tidb-cluster-serverless.md index 8b5e59d72269b..d847d2753922a 100644 --- a/tidb-cloud/create-tidb-cluster-serverless.md +++ b/tidb-cloud/create-tidb-cluster-serverless.md @@ -7,7 +7,7 @@ summary: 了解如何创建 TiDB Cloud Starter 或 TiDB Cloud Essential 集群 本文档介绍如何在 [TiDB Cloud 控制台](https://tidbcloud.com/) 中创建 TiDB Cloud Starter 或 TiDB Cloud Essential 集群。 -> **提示：** +> **Tip:** > > 如果你想了解如何创建 TiDB Cloud Dedicated 集群，请参见 [Create a TiDB Cloud Dedicated Cluster](/tidb-cloud/create-tidb-cluster.md)。 @@ -18,10 +18,10 @@ summary: 了解如何创建 TiDB Cloud Starter 或 TiDB Cloud Essential 集群 - 你可以使用邮箱和密码注册，这样可以通过 TiDB Cloud 管理你的密码，或者使用 Google、GitHub 或 Microsoft 账号注册。 -- 对于 AWS Marketplace 用户，你也可以通过 AWS Marketplace 注册。方法是，在 [AWS Marketplace](https://aws.amazon.com/marketplace) 搜索 `TiDB Cloud`，订阅 TiDB Cloud，然后按照屏幕上的指引设置你的 TiDB Cloud 账号。 -- 对于 Azure Marketplace 用户，你也可以通过 Azure Marketplace 注册。方法是，在 [Azure Marketplace](https://azuremarketplace.microsoft.com) 搜索 `TiDB Cloud`，订阅 TiDB Cloud，然后按照屏幕上的指引设置你的 TiDB Cloud 账号。 -- 对于 Google Cloud Marketplace 用户，你也可以通过 Google Cloud Marketplace 注册。方法是，在 [Google Cloud Marketplace](https://console.cloud.google.com/marketplace) 搜索 `TiDB Cloud`，订阅 TiDB Cloud，然后按照屏幕上的指引设置你的 TiDB Cloud 账号。 -- 对于阿里云云市场用户，你也可以通过阿里云云市场注册。方法是，在 [阿里云云市场](https://marketplace.alibabacloud.com/) 搜索 `TiDB Cloud`，订阅 TiDB Cloud，然后按照屏幕上的指引设置你的 TiDB Cloud 账号。 +- 对于 AWS Marketplace 用户，你也可以通过 AWS Marketplace 注册。方法是，在 [AWS Marketplace](https://aws.amazon.com/marketplace) 中搜索 `TiDB Cloud`，订阅 TiDB Cloud，然后按照屏幕上的指引设置你的 TiDB Cloud 账号。 +- 对于 Azure Marketplace 用户，你也可以通过 Azure Marketplace 注册。方法是，在 [Azure Marketplace](https://azuremarketplace.microsoft.com) 中搜索 `TiDB Cloud`，订阅 TiDB Cloud，然后按照屏幕上的指引设置你的 TiDB Cloud 账号。 +- 对于 Google Cloud Marketplace 用户，你也可以通过 Google Cloud Marketplace 注册。方法是，在 [Google Cloud Marketplace](https://console.cloud.google.com/marketplace) 中搜索 `TiDB Cloud`，订阅 TiDB Cloud，然后按照屏幕上的指引设置你的 TiDB Cloud 账号。 +- 对于阿里云云市场用户，你也可以通过阿里云云市场注册。方法是，在 [阿里云云市场](https://marketplace.alibabacloud.com/) 中搜索 `TiDB Cloud`，订阅 TiDB Cloud，然后按照屏幕上的指引设置你的 TiDB Cloud 账号。 @@ -56,13 +56,13 @@ summary: 了解如何创建 TiDB Cloud Starter 或 TiDB Cloud Essential 集群 - 你可以设置集群的消费上限。如果消费上限设置为 0，集群将保持免费。如果消费上限大于 0，则需要在创建集群前添加信用卡。 - - 默认情况下，每个组织最多可以创建五个[免费 Starter 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)。如需创建更多 Starter 集群，必须添加信用卡并指定消费上限。 + - 默认情况下，每个组织最多可以创建 5 个[免费 Starter 集群](/tidb-cloud/select-cluster-tier.md#starter)。如需创建更多 Starter 集群，必须添加信用卡并指定消费上限。 - **Essential** 方案： - 你必须为集群指定最小和最大 Request Capacity Units（RCUs）。 - - RCU 代表为你的工作负载分配的计算资源。TiDB Cloud 会根据需求在该范围内自动扩缩你的集群。 + - RCU 代表为你的工作负载预留的计算资源。TiDB Cloud 会根据需求在该范围内自动扩缩你的集群。 7. 点击 **Create**。 @@ -72,6 +72,6 @@ summary: 了解如何创建 TiDB Cloud Starter 或 TiDB Cloud Essential 集群 集群创建完成后，请按照 [Connect to TiDB Cloud via Public Endpoint](/tidb-cloud/connect-via-standard-connection-serverless.md) 的指引为你的集群创建密码。 -> **注意：** +> **Note:** > > 如果你未设置密码，将无法连接到集群。 \ No newline at end of file diff --git a/tidb-cloud/data-service-overview.md b/tidb-cloud/data-service-overview.md index 444cf2097eccd..d594eee3935e2 100644 --- a/tidb-cloud/data-service-overview.md +++ b/tidb-cloud/data-service-overview.md @@ -5,13 +5,13 @@ summary: 了解 TiDB Cloud 中的 Data Service 及其应用场景。 # TiDB Cloud Data Service (Beta) 概述 -TiDB Cloud [Data Service (beta)](https://tidbcloud.com/project/data-service) 是一款全托管的低代码后端即服务（Backend-as-a-Service）解决方案，简化了后端应用开发，帮助开发者快速构建高可扩展性、安全、数据驱动的应用。 +TiDB Cloud [Data Service (beta)](https://tidbcloud.com/project/data-service) 是一款全托管的低代码后端即服务（backend-as-a-service）解决方案，简化了后端应用开发，帮助开发者快速构建高可扩展性、安全、数据驱动的应用。 -Data Service 允许你通过自定义 API 端点，以 HTTPS 请求的方式访问 TiDB Cloud 数据。该功能采用无服务器架构，自动处理计算资源和弹性扩缩容，因此你只需专注于端点中的查询逻辑，无需担心基础设施或运维成本。 +Data Service 允许你通过自定义 API 端点，以 HTTPS 请求的方式访问 TiDB Cloud 数据。该功能采用无服务器架构，自动处理计算资源和弹性扩展，因此你可以专注于端点中的查询逻辑，而无需担心基础设施或运维成本。 > **Note:** > -> Data Service 仅适用于托管在 AWS 上的 TiDB Cloud Starter（原 Serverless）。如需在 TiDB Cloud Dedicated 集群中使用 Data Service，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 +> Data Service 仅适用于托管在 AWS 上的 TiDB Cloud Starter。如需在 TiDB Cloud Dedicated 集群中使用 Data Service，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 Data Service 中的端点是你可以自定义以执行 SQL 语句的 Web API。你可以为 SQL 语句指定参数，例如 `WHERE` 子句中使用的值。当客户端调用端点并在请求 URL 中提供参数值时，端点会使用提供的参数执行相应的 SQL 语句，并将结果作为 HTTP 响应的一部分返回。 @@ -19,9 +19,9 @@ Data Service 中的端点是你可以自定义以执行 SQL 语句的 Web API。 > **Tip:** > -> TiDB Cloud 为 TiDB 集群提供了 Chat2Query API。启用后，TiDB Cloud 会自动创建一个名为 **Chat2Query** 的系统 Data App 以及一个 Chat2Data 端点。你可以调用该端点，通过提供指令让 AI 生成并执行 SQL 语句。 +> TiDB Cloud 为 TiDB 集群提供了 Chat2Query API。启用后，TiDB Cloud 会自动创建一个名为 **Chat2Query** 的系统 Data App 以及一个 Chat2Data 端点在 Data Service 中。你可以调用该端点，通过提供指令让 AI 生成并执行 SQL 语句。 > -> 详细信息请参见 [Get started with Chat2Query API](/tidb-cloud/use-chat2query-api.md)。 +> 更多信息，参见 [Get started with Chat2Query API](/tidb-cloud/use-chat2query-api.md)。 ## 应用场景 diff --git a/tidb-cloud/delete-tidb-cluster.md b/tidb-cloud/delete-tidb-cluster.md index 1a36203c0e0b5..77fa07ad484ef 100644 --- a/tidb-cloud/delete-tidb-cluster.md +++ b/tidb-cloud/delete-tidb-cluster.md @@ -7,7 +7,7 @@ summary: 了解如何删除 TiDB 集群。 本文档介绍如何在 TiDB Cloud 上删除 TiDB 集群。 -你可以随时通过以下步骤删除集群： +你可以随时按照以下步骤删除集群： 1. 进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 2. 在你想要删除的目标集群所在行，点击 **...**。 @@ -19,21 +19,21 @@ summary: 了解如何删除 TiDB 集群。 3. 在下拉菜单中点击 **Delete**。 4. 在集群删除窗口中，确认删除操作： - - 如果你至少有一个手动或自动备份，你可以看到备份的数量以及备份的计费策略。点击 **Continue** 并输入 `//`。 + - 如果你至少有一次手动或自动备份，你可以看到备份的数量以及备份的计费策略。点击 **Continue** 并输入 `//`。 - 如果你没有任何备份，只需输入 `//`。 - 如果你希望将来恢复该集群，请确保你已经对集群进行了备份。否则，将无法再恢复。关于如何备份 TiDB Cloud Dedicated 集群的更多信息，请参见 [Back Up and Restore TiDB Cloud Dedicated Data](/tidb-cloud/backup-and-restore.md)。 + 如果你希望将来恢复该集群，请确保你已经对集群进行了备份。否则，你将无法再恢复它。关于如何备份 TiDB Cloud Dedicated 集群的更多信息，请参见 [Back Up and Restore TiDB Cloud Dedicated Data](/tidb-cloud/backup-and-restore.md)。 > **注意：** > - > [TiDB Cloud Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 在删除后不支持数据恢复。如果你想删除 TiDB Cloud Serverless 集群并在将来恢复其数据，请参见 [Export Data from TiDB Cloud Serverless](/tidb-cloud/serverless-export.md) 将你的数据导出作为备份。 + > [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群在删除后不支持数据恢复。如果你想删除 TiDB Cloud Starter 或 TiDB Cloud Essential 集群并在未来恢复其数据，请参见 [Export Data from TiDB Cloud Starter or Essential](/tidb-cloud/serverless-export.md) 将你的数据导出作为备份。 5. 点击 **I understand, delete it**。 一旦已备份的 TiDB Cloud Dedicated 集群被删除，该集群现有的备份文件会被移动到回收站。 - - 自动备份将在保留期结束后过期并自动删除。如果你没有修改，默认保留期为 7 天。 - - 手动备份会一直保留在回收站，直到你手动删除。 + - 自动备份将在保留期结束后过期并被自动删除。如果你未修改，默认保留期为 7 天。 + - 手动备份会一直保留在回收站，直到被手动删除。 > **注意：** > diff --git a/tidb-cloud/explore-data-with-chat2query.md b/tidb-cloud/explore-data-with-chat2query.md index 38a0ea6e27002..86dd74fc1f565 100644 --- a/tidb-cloud/explore-data-with-chat2query.md +++ b/tidb-cloud/explore-data-with-chat2query.md @@ -20,8 +20,8 @@ SQL 编辑器推荐的使用场景如下： ## 限制 - AI 生成的 SQL 查询可能并非 100% 准确，你可能需要对其进行完善。 -- SQL 编辑器仅支持部署在 AWS 上、版本为 v6.5.0 及以上的 TiDB 集群。 -- SQL 编辑器默认对 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群开放。若要在 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群上使用 SQL 编辑器和 Chat2Query，请联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 +- SQL 编辑器仅支持部署在 AWS 上且版本为 v6.5.0 或更高的 TiDB 集群。 +- SQL 编辑器仅适用于部署在 AWS 上的 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群。如需在 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群上使用 SQL 编辑器和 Chat2Query，请联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 ## 访问 SQL 编辑器 @@ -37,7 +37,7 @@ SQL 编辑器推荐的使用场景如下： > > 在以下情况下，**SQL Editor** 入口会显示为灰色且不可点击。 > - > - 你的 TiDB Cloud Dedicated 集群版本低于 v6.5.0。若要使用 SQL 编辑器，你需要联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md) 升级你的集群。 + > - 你的 TiDB Cloud Dedicated 集群版本低于 v6.5.0。如需使用 SQL 编辑器，你需要联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md) 升级你的集群。 > - 你的 TiDB Cloud Dedicated 集群刚刚创建，SQL 编辑器的运行环境仍在准备中。此时请等待几分钟，Chat2Query 即可使用。 > - 你的 TiDB Cloud Dedicated 集群已被 [暂停](/tidb-cloud/pause-or-resume-tidb-cluster.md)。 @@ -45,15 +45,15 @@ SQL 编辑器推荐的使用场景如下： PingCAP 将用户数据的隐私和安全放在首位。SQL 编辑器中 Chat2Query 的 AI 能力仅需访问数据库 schema 以生成 SQL 查询，不会访问你的数据本身。更多信息请参见 [Chat2Query 隐私常见问题](https://www.pingcap.com/privacy-policy/privacy-chat2query)。 -首次访问 Chat2Query 时，你会看到一个对话框，询问是否允许 PingCAP 和 Amazon Bedrock 使用你的代码片段进行服务研究和改进。 +首次访问 Chat2Query 时，会弹出对话框，询问你是否允许 PingCAP 和 Amazon Bedrock 使用你的代码片段进行服务研究和改进。 -- 若要启用 AI 生成 SQL 查询，勾选复选框并点击 **Save and Get Started**。 +- 若要启用 AI 生成 SQL 查询，请勾选复选框并点击 **Save and Get Started**。 - 若要禁用 AI 生成 SQL 查询，直接关闭该对话框即可。 首次访问后，你仍可按如下方式更改 AI 设置： -- 启用 AI：在 Chat2Query 右上角点击 **Enable AI power for data exploration**。 -- 禁用 AI：在 [TiDB Cloud 控制台](https://tidbcloud.com/)左下角点击 ，点击 **Account Settings**，切换到 **AI & Privacy** 标签页，然后关闭 **AI-powered Data Exploration** 选项。 +- 若要启用 AI，在 Chat2Query 右上角点击 **Enable AI power for data exploration**。 +- 若要禁用 AI，在 [TiDB Cloud 控制台](https://tidbcloud.com/) 左下角点击 ，点击 **Account Settings**，切换到 **AI & Privacy** 标签页，然后关闭 **AI-powered Data Exploration** 选项。 ## 编写并运行 SQL 查询 @@ -64,25 +64,25 @@ PingCAP 将用户数据的隐私和安全放在首位。SQL 编辑器中 Chat2Qu
- 针对 macOS： + 对于 macOS： - 如果已启用 AI，只需按下 **⌘ + I**，输入你的指令并按 **Enter**，即可让 AI 自动生成 SQL 查询。 对于 Chat2Query 生成的 SQL 查询，点击 **Accept** 接受该查询并继续编辑。如果查询不符合你的需求，点击 **Discard** 拒绝该查询。你也可以点击 **Regenerate** 让 Chat2Query 重新生成查询。 - - 如果未启用 AI，则手动编写 SQL 查询。 + - 如果未启用 AI，请手动编写 SQL 查询。
- 针对 Windows 或 Linux： + 对于 Windows 或 Linux： - 如果已启用 AI，只需按下 **Ctrl + I**，输入你的指令并按 **Enter**，即可让 AI 自动生成 SQL 查询。 对于 Chat2Query 生成的 SQL 查询，点击 **Accept** 接受该查询并继续编辑。如果查询不符合你的需求，点击 **Discard** 拒绝该查询。你也可以点击 **Regenerate** 让 Chat2Query 重新生成查询。 - - 如果未启用 AI，则手动编写 SQL 查询。 + - 如果未启用 AI，请手动编写 SQL 查询。
@@ -92,25 +92,25 @@ PingCAP 将用户数据的隐私和安全放在首位。SQL 编辑器中 Chat2Qu
- 针对 macOS： + 对于 macOS： - 如果编辑器中只有一个查询，按 **⌘ + Enter** 或点击 **Run** 即可运行。 - - 如果编辑器中有多个查询，想要顺序运行其中一个或多个，选中目标查询的行，然后按 **⌘ + Enter** 或点击 **Run**。 + - 如果编辑器中有多个查询，选中目标查询的行，然后按 **⌘ + Enter** 或点击 **Run**，即可依次运行选中的查询。 - - 若要顺序运行编辑器中的所有查询，按 **⇧ + ⌘ + Enter**，或选中所有查询的行后点击 **Run**。 + - 若要依次运行编辑器中的所有查询，按 **⇧ + ⌘ + Enter**，或选中所有查询的行后点击 **Run**。
- 针对 Windows 或 Linux： + 对于 Windows 或 Linux： - 如果编辑器中只有一个查询，按 **Ctrl + Enter** 或点击 **Run** 即可运行。 - - 如果编辑器中有多个查询，想要顺序运行其中一个或多个，选中目标查询的行，然后按 **Ctrl + Enter** 或点击 **Run**。 + - 如果编辑器中有多个查询，选中目标查询的行，然后按 **Ctrl + Enter** 或点击 **Run**，即可依次运行选中的查询。 - - 若要顺序运行编辑器中的所有查询，按 **Shift + Ctrl + Enter**，或选中所有查询的行后点击 **Run**。 + - 若要依次运行编辑器中的所有查询，按 **Shift + Ctrl + Enter**，或选中所有查询的行后点击 **Run**。
@@ -127,7 +127,7 @@ PingCAP 将用户数据的隐私和安全放在首位。SQL 编辑器中 Chat2Qu 1. 用光标选中你想要重写的 SQL 查询行。 -2. 按照你的操作系统，使用快捷键调用 Chat2Query 进行重写： +2. 使用对应操作系统的快捷键调用 Chat2Query 进行重写： - macOS 上为 ⌘ + I - Windows 或 Linux 上为 Control + I @@ -142,7 +142,7 @@ PingCAP 将用户数据的隐私和安全放在首位。SQL 编辑器中 Chat2Qu > **注意：** > -> Chat2Query 使用 AI 算法提供优化和修正建议。建议你在最终确定查询前，仔细审核这些建议。 +> Chat2Query 使用 AI 算法提供优化和修正建议。建议你在最终确定查询前，仔细审查这些建议。 ## 管理 SQL 文件 @@ -150,7 +150,7 @@ PingCAP 将用户数据的隐私和安全放在首位。SQL 编辑器中 Chat2Qu - 新增 SQL 文件：点击 **SQL Files** 标签页上的 **+**。 - 重命名 SQL 文件：将光标移到文件名上，点击文件名旁的 **...**，然后选择 **Rename**。 -- 删除 SQL 文件：将光标移到文件名上，点击文件名旁的 **...**，然后选择 **Delete**。注意，当 **SQL Files** 标签页上只有一个 SQL 文件时，无法删除该文件。 +- 删除 SQL 文件：将光标移到文件名上，点击文件名旁的 **...**，然后选择 **Delete**。注意，当 **SQL Files** 标签页上只剩一个 SQL 文件时，无法删除该文件。 ## 通过 API 访问 Chat2Query @@ -161,18 +161,18 @@ PingCAP 将用户数据的隐私和安全放在首位。SQL 编辑器中 Chat2Qu 1. 点击右上角的 **...**，然后点击 **Access Chat2Query via API**。 2. 在弹出的对话框中，执行以下操作之一： - - 创建新的 Chat2Query Data App，点击 **New Chat2Query Data App**。 - - 访问已有的 Chat2Query Data App，点击目标 Data App 的名称。 + - 若要创建新的 Chat2Query Data App，点击 **New Chat2Query Data App**。 + - 若要访问已有的 Chat2Query Data App，点击目标 Data App 的名称。 更多信息请参见 [Get started with Chat2Query API](/tidb-cloud/use-chat2query-api.md)。 -## 从 SQL 文件生成接口 +## 从 SQL 文件生成 endpoint -对于 TiDB 集群，TiDB Cloud 提供了 [Data Service (beta)](/tidb-cloud/data-service-overview.md) 功能，使你可以通过自定义 API endpoint 以 HTTPS 请求访问 TiDB Cloud 数据。在 SQL 编辑器中，你可以通过以下步骤从 SQL 文件生成 Data Service (beta) 的接口： +对于 TiDB 集群，TiDB Cloud 提供了 [Data Service (beta)](/tidb-cloud/data-service-overview.md) 功能，使你可以通过自定义 API endpoint 以 HTTPS 请求方式访问 TiDB Cloud 数据。在 SQL 编辑器中，你可以通过以下步骤从 SQL 文件生成 Data Service (beta) 的 endpoint： 1. 将光标移到文件名上，点击文件名旁的 **...**，然后选择 **Generate endpoint**。 -2. 在 **Generate endpoint** 对话框中，选择你要为其生成接口的 Data App，并输入接口名称。 -3. 点击 **Generate**。接口生成后会显示其详情页。 +2. 在 **Generate endpoint** 对话框中，选择你要为其生成 endpoint 的 Data App，并输入 endpoint 名称。 +3. 点击 **Generate**。endpoint 生成后会显示其详情页面。 更多信息请参见 [Manage an endpoint](/tidb-cloud/data-service-manage-endpoint.md)。 @@ -186,5 +186,5 @@ PingCAP 将用户数据的隐私和安全放在首位。SQL 编辑器中 Chat2Qu 更改设置的步骤如下： 1. 在 **SQL Editor** 右上角点击 **...** 并选择 **Settings**。 -2. 根据需要更改设置。 +2. 根据你的需求更改设置。 3. 点击 **Save**。 \ No newline at end of file diff --git a/tidb-cloud/get-started-with-cli.md b/tidb-cloud/get-started-with-cli.md index 261b28fc84342..90bda8f4a1f6a 100644 --- a/tidb-cloud/get-started-with-cli.md +++ b/tidb-cloud/get-started-with-cli.md @@ -87,7 +87,7 @@ TiDB Cloud 提供了一个命令行界面（CLI）[`ticloud`](https://github.com ## 快速入门 -[TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 是体验 TiDB Cloud 的最佳方式。本节将介绍如何使用 TiDB Cloud CLI 创建一个 TiDB Cloud Serverless 集群。 +[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 是开始体验 TiDB Cloud 的最佳方式。本节将介绍如何使用 TiDB Cloud CLI 创建一个 TiDB Cloud Starter 集群。 ### 创建用户配置文件或登录 TiDB Cloud @@ -115,9 +115,9 @@ TiDB Cloud 提供了一个命令行界面（CLI）[`ticloud`](https://github.com > > 在上述两种方式中，TiDB Cloud API key 的优先级高于 OAuth token。如果两者都存在，将优先使用 API key。 -### 创建 TiDB Cloud Serverless 集群 +### 创建 TiDB Cloud Starter 集群 -要创建 TiDB Cloud Serverless 集群，输入以下命令，并根据 CLI 提示填写所需信息： +要创建 TiDB Cloud Starter 集群，输入以下命令，并根据 CLI 提示填写所需信息： ```shell ticloud serverless create @@ -171,4 +171,4 @@ tiup update cloud ## 反馈 -如果你对 TiDB Cloud CLI 有任何问题或建议，欢迎创建 [issue](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)。同时也欢迎任何贡献。 \ No newline at end of file +如果你对 TiDB Cloud CLI 有任何疑问或建议，欢迎创建 [issue](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)。同时也欢迎任何贡献。 \ No newline at end of file diff --git a/tidb-cloud/integrate-tidbcloud-with-netlify.md b/tidb-cloud/integrate-tidbcloud-with-netlify.md index 7fc323585d230..605f023ee26d1 100644 --- a/tidb-cloud/integrate-tidbcloud-with-netlify.md +++ b/tidb-cloud/integrate-tidbcloud-with-netlify.md @@ -24,7 +24,7 @@ summary: 了解如何将你的 TiDB Cloud 集群连接到 Netlify 项目。 你需要在 TiDB Cloud 中拥有一个账号和一个集群。如果还没有，请参考以下内容创建： -- [创建 TiDB Cloud Serverless 集群](/tidb-cloud/create-tidb-cluster-serverless.md) +- [创建 TiDB Cloud Starter 或 TiDB Cloud Essential 集群](/tidb-cloud/create-tidb-cluster-serverless.md) - [创建 TiDB Cloud Dedicated 集群](/tidb-cloud/create-tidb-cluster.md) 一个 TiDB Cloud 集群可以连接到多个 Netlify 站点。 @@ -33,11 +33,11 @@ summary: 了解如何将你的 TiDB Cloud 集群连接到 Netlify 项目。 对于 TiDB Cloud Dedicated 集群，请确保集群的流量过滤器允许所有 IP 地址（设置为 `0.0.0.0/0`）进行连接。这是因为 Netlify 部署使用动态 IP 地址。 -TiDB Cloud Serverless 集群默认允许所有 IP 地址连接，因此无需配置任何流量过滤器。 +TiDB Cloud Starter 和 TiDB Cloud Essential 集群默认允许所有 IP 地址连接，因此无需配置任何流量过滤器。 ## 步骤 1. 获取示例项目和连接字符串 -为了帮助你快速上手，TiDB Cloud 提供了一个基于 TypeScript、Next.js、React 和 Prisma Client 的全栈示例应用。它是一个简单的博客站点，你可以在其中发布和删除自己的博客。所有内容都通过 Prisma 存储在 TiDB Cloud 中。 +为了帮助你快速入门，TiDB Cloud 提供了一个使用 TypeScript、Next.js、React 和 Prisma Client 的全栈示例应用。它是一个简单的博客站点，你可以在其中发布和删除自己的博客。所有内容都通过 Prisma 存储在 TiDB Cloud 中。 ### Fork 示例项目并克隆到你的空间 @@ -52,14 +52,14 @@ TiDB Cloud Serverless 集群默认允许所有 IP 地址连接，因此无需配 ### 获取 TiDB Cloud 连接字符串 -对于 TiDB Cloud Serverless 集群，你可以通过 [TiDB Cloud CLI](/tidb-cloud/cli-reference.md) 或 [TiDB Cloud 控制台](https://tidbcloud.com/) 获取连接字符串。 +对于 TiDB Cloud Starter 或 TiDB Cloud Essential 集群，你可以通过 [TiDB Cloud CLI](/tidb-cloud/cli-reference.md) 或 [TiDB Cloud 控制台](https://tidbcloud.com/) 获取连接字符串。 对于 TiDB Cloud Dedicated 集群，你只能通过 TiDB Cloud 控制台获取连接字符串。
-> **提示：** +> **Tip:** > > 如果你还没有安装 Cloud CLI，请参考 [TiDB Cloud CLI 快速入门](/tidb-cloud/get-started-with-cli.md) 进行快速安装，然后再执行以下步骤。 @@ -89,7 +89,7 @@ TiDB Cloud Serverless 集群默认允许所有 IP 地址连接，因此无需配 } ``` - > **注意：** + > **Note:** > > 在后续使用连接字符串时，请注意以下事项： > @@ -99,7 +99,7 @@ TiDB Cloud Serverless 集群默认允许所有 IP 地址连接，因此无需配
-1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/) 中，进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群名称进入其概览页，然后点击右上角的 **Connect**。在弹出的对话框中，你可以从连接字符串中获取以下连接参数： +1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/) 中，进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群名称进入其概览页面，然后点击右上角的 **Connect**。在弹出的对话框中，你可以从连接字符串中获取以下连接参数： - `${host}` - `${port}` @@ -112,7 +112,7 @@ TiDB Cloud Serverless 集群默认允许所有 IP 地址连接，因此无需配 mysql://:@:/?sslaccept=strict ``` - > **注意：** + > **Note:** > > 在后续使用连接字符串时，请注意以下事项： > @@ -199,9 +199,9 @@ TiDB Cloud Serverless 集群默认允许所有 IP 地址连接，因此无需配 4. 在本地构建应用并将 schema 迁移到你的 TiDB Cloud 集群。 - > **提示：** + > **Tips:** > - > 如果你想跳过本地部署，直接将应用部署到 Netlify，请直接跳到第 6 步。 + > 如果你想跳过本地部署，直接将应用部署到 Netlify，可以直接跳到第 6 步。 ```shell npm install . @@ -222,7 +222,7 @@ TiDB Cloud Serverless 集群默认允许所有 IP 地址连接，因此无需配 netlify deploy --prod --trigger ``` - 前往你的 Netlify 控制台查看部署状态。部署完成后，应用的站点将拥有 Netlify 提供的公网 IP 地址，所有人都可以访问。 + 前往你的 Netlify 控制台查看部署状态。部署完成后，应用站点将拥有 Netlify 提供的公网 IP，所有人都可以访问。 ## 使用 edge function @@ -236,13 +236,13 @@ TiDB Cloud Serverless 集群默认允许所有 IP 地址连接，因此无需配 ```typescript import { connect } from 'https://esm.sh/@tidbcloud/serverless' - + export default async () => { const conn = connect({url: Netlify.env.get('DATABASE_URL')}) const result = await conn.execute('show databases') return new Response(JSON.stringify(result)); } - + export const config = { path: "/api/hello" }; ``` diff --git a/tidb-cloud/manage-serverless-spend-limit.md b/tidb-cloud/manage-serverless-spend-limit.md index 6f9958d7aacbe..81d7849eb05f2 100644 --- a/tidb-cloud/manage-serverless-spend-limit.md +++ b/tidb-cloud/manage-serverless-spend-limit.md @@ -9,9 +9,9 @@ summary: 了解如何管理 TiDB Cloud Starter 集群的消费限额。 > > 消费限额仅适用于 TiDB Cloud Starter 集群。 -消费限额是指你每月愿意为某个特定工作负载支付的最大金额。它是一种成本控制机制，可以让你为 TiDB Cloud Starter 集群设置预算。 +消费限额是指你每月愿意在某个特定工作负载上花费的最大金额。它是一种成本控制机制，可以让你为 TiDB Cloud Starter 集群设置预算。 -在 TiDB Cloud 的每个组织中，默认最多可以创建五个 [免费 TiDB Cloud Starter 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)。如果你需要创建更多 TiDB Cloud Starter 集群，则需要添加信用卡并为使用设置每月消费限额。但如果你在创建更多集群之前删除了一些已有集群，则新集群仍然可以在无需信用卡的情况下创建。 +在 TiDB Cloud 的每个组织中，默认最多可以创建五个 [免费 TiDB Cloud Starter 集群](/tidb-cloud/select-cluster-tier.md#starter)。如果你需要创建更多 TiDB Cloud Starter 集群，则需要添加信用卡并为使用设置每月消费限额。但如果你在创建更多集群之前删除了一些已有集群，则新集群仍然可以在无需信用卡的情况下创建。 ## 使用配额 @@ -19,9 +19,9 @@ summary: 了解如何管理 TiDB Cloud Starter 集群的消费限额。 - 行存储：5 GiB - 列存储：5 GiB -- [请求单位（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit)：每月 5000 万 RUs +- [请求单位（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit)：每月 5000 万 RU -当某个集群达到其使用配额时，将立即拒绝任何新的连接尝试，直到你 [提升配额](#update-spending-limit) 或新月开始时用量被重置。已在达到配额前建立的连接会保持活跃，但会受到限流。例如，当免费集群的行存储超过 5 GiB 时，该集群会自动限制任何新的连接尝试。 +一旦某个集群达到其使用配额，将会立即拒绝任何新的连接尝试，直到你 [增加配额](#update-spending-limit) 或者在新月开始时用量被重置。已在达到配额前建立的连接会保持活跃，但会受到限流。例如，当免费集群的行存储超过 5 GiB 时，该集群会自动限制任何新的连接尝试。 如需了解不同资源（包括读、写、SQL CPU 和网络出口）的 RU 消耗、定价详情以及限流信息，请参见 [TiDB Cloud Starter Pricing Details](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 @@ -29,11 +29,11 @@ summary: 了解如何管理 TiDB Cloud Starter 集群的消费限额。 ## 更新消费限额 -对于 TiDB Cloud Starter 免费集群，你可以在创建集群时设置每月消费限额以提升使用配额。对于已有集群，你可以直接调整每月消费限额。 +对于 TiDB Cloud Starter 免费集群，你可以在创建集群时通过设置每月消费限额来提升使用配额。对于已存在的集群，你可以直接调整每月消费限额。 要为 TiDB Cloud Starter 集群更新消费限额，请执行以下步骤： -1. 在项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群名称进入其概览页面。 +1. 在项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群的名称，进入其概览页面。 > **Tip:** > @@ -41,7 +41,7 @@ summary: 了解如何管理 TiDB Cloud Starter 集群的消费限额。 2. 在 **Capacity used this month** 区域，点击 **Set Spending Limit**。 - 如果你之前已设置过消费限额并希望更新，点击 **Edit**。 + 如果你之前已经设置过消费限额并希望更新，点击 **Edit**。 -3. 根据需要编辑每月消费限额。如果你尚未添加支付方式，编辑限额后需要添加信用卡。 +3. 根据需要编辑每月消费限额。如果你还未添加支付方式，编辑限额后需要添加信用卡。 4. 点击 **Update Spending Limit**。 \ No newline at end of file diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index 888659874130f..52875c31c27a6 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -5,7 +5,7 @@ summary: 了解如何通过 Datadog 集成监控你的 TiDB 集群。 # 集成 TiDB Cloud 与 Datadog -TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你的 TiDB 集群的指标发送到 [Datadog](https://www.datadoghq.com/)。之后，你可以直接在 Datadog 的仪表盘中查看这些指标。 +TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于 TiDB 集群的指标发送到 [Datadog](https://www.datadoghq.com/)。之后，你可以直接在 Datadog 仪表盘中查看这些指标。 ## Datadog 集成版本 @@ -24,9 +24,9 @@ TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你 ## 限制 -- 你无法在 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 或 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群中使用 Datadog 集成。 +- Datadog 集成目前仅适用于 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 -- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，Datadog 集成不可用。 +- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，无法使用 Datadog 集成。 - 当带有 Datadog 集成的集群被删除时，其关联的集成服务也会被移除。 @@ -37,9 +37,9 @@ TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你 根据你的 [Datadog 集成版本](#datadog-integration-version)，访问集成页面的步骤有所不同。 -
+
-1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入你项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称进入其概览页面。 +1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入你项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称，进入其概览页面。 2. 在左侧导航栏，点击 **Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to Datadog**。 4. 输入你的 Datadog API key 并选择你的 Datadog 站点。 @@ -51,7 +51,7 @@ TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你 6. 点击 **Confirm** 完成集成。
-
+
1. 在 [TiDB Cloud 控制台](https://tidbcloud.com)中，使用左上角的下拉框切换到你的目标项目。 2. 在左侧导航栏，点击 **Project Settings** > **Integrations**。 @@ -69,7 +69,7 @@ TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你 ### 步骤 2. 在 Datadog 中安装 TiDB Cloud 集成 -> **注意：** +> **Note:** > > 如果你已经在 Datadog 中安装了 TiDB Cloud 集成，可以跳过本节的以下步骤。[**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker) 或 [**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview) 仪表盘会自动出现在你的 Datadog [**Dashboard List**](https://app.datadoghq.com/dashboard/lists) 中。 @@ -86,7 +86,7 @@ TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你 2. 在 **Datadog** 区域点击 **Dashboard** 链接。 - 对于集群级 Datadog 集成，**Dashboard** 链接会打开新版仪表盘，包含增强版本中引入的最新指标。 - - 对于遗留项目级 Datadog 集成（Beta），**Dashboard** 链接会打开旧版仪表盘，不包含集群级 Datadog 集成引入的最新指标。 + - 对于遗留项目级 Datadog 集成（Beta），**Dashboard** 链接会打开遗留仪表盘，不包含集群级 Datadog 集成中引入的最新指标。 ## Datadog 可用指标 @@ -97,37 +97,37 @@ Datadog 会跟踪你的 TiDB 集群的以下指标。 | tidb_cloud.db_database_time| gauge | sql_type: Select\|Insert\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每秒在 TiDB 中运行的所有 SQL 语句消耗的总时间，包括所有进程的 CPU 时间和非空闲等待时间。 | | tidb_cloud.db_query_per_second| gauge | type: Select\|Insert\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 所有 TiDB 实例每秒执行的 SQL 语句数量，按语句类型（`SELECT`、`INSERT` 或 `UPDATE`）统计。 | | tidb_cloud.db_average_query_duration| gauge | sql_type: Select\|Insert\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 客户端网络请求发送到 TiDB 与 TiDB 执行后返回给客户端之间的持续时间。 | -| tidb_cloud.db_failed_queries| gauge | type: executor:xxxx\|parser:xxxx\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每秒每个 TiDB 实例发生的 SQL 执行错误的错误类型统计（如语法错误、主键冲突等）。 | +| tidb_cloud.db_failed_queries| gauge | type: executor:xxxx\|parser:xxxx\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每个 TiDB 实例每秒发生的 SQL 执行错误，按错误类型（如语法错误、主键冲突等）统计。 | | tidb_cloud.db_total_connection| gauge | cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 当前 TiDB 服务器的连接数。 | | tidb_cloud.db_active_connections| gauge | cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 活跃连接数。 | | tidb_cloud.db_disconnections| gauge | result: ok\|error\|undetermined
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 断开连接的客户端数量。 | -| tidb_cloud.db_command_per_second| gauge | type: Query\|StmtPrepare\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | TiDB 每秒处理的命令数量，按命令执行结果的成功或失败分类。 | +| tidb_cloud.db_command_per_second| gauge | type: Query\|StmtPrepare\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | TiDB 每秒处理的命令数，按命令执行结果的成功或失败分类。 | | tidb_cloud.db_queries_using_plan_cache_ops| gauge | cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每秒使用 [Plan Cache](/sql-prepared-plan-cache.md) 的查询统计。执行计划缓存仅支持 prepared statement 命令。 | | tidb_cloud.db_transaction_per_second| gauge | txn_mode: pessimistic\|optimistic
type: abort\|commit\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每秒执行的事务数量。 | -| tidb_cloud.node_storage_used_bytes | gauge | cluster_name: ``
instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…
component: tikv\|tiflash | TiKV/TiFlash 节点的磁盘使用量（字节）。 | -| tidb_cloud.node_storage_capacity_bytes | gauge | cluster_name: ``
instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…
component: tikv\|tiflash | TiKV/TiFlash 节点的磁盘容量（字节）。 | +| tidb_cloud.node_storage_used_bytes | gauge | cluster_name: ``
instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…
component: tikv\|tiflash | TiKV/TiFlash 节点的磁盘使用量，单位为字节。 | +| tidb_cloud.node_storage_capacity_bytes | gauge | cluster_name: ``
instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…
component: tikv\|tiflash | TiKV/TiFlash 节点的磁盘容量，单位为字节。 | | tidb_cloud.node_cpu_seconds_total | count | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的 CPU 使用量。 | | tidb_cloud.node_cpu_capacity_cores | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的 CPU 核心数上限。 | -| tidb_cloud.node_memory_used_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点已用内存（字节）。 | -| tidb_cloud.node_memory_capacity_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的内存容量（字节）。 | +| tidb_cloud.node_memory_used_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点已用内存，单位为字节。 | +| tidb_cloud.node_memory_capacity_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的内存容量，单位为字节。 | -对于集群级 Datadog 集成，还可获得以下额外指标： +对于集群级 Datadog 集成，还支持以下额外指标： | 指标名称 | 指标类型 | 标签 | 描述 | | :------------| :---------- | :------| :----------------------------------------------------- | -| tidb_cloud.node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: `` | TiKV/TiFlash 节点可用磁盘空间（字节）。 | -| tidb_cloud.node_disk_read_latency | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的读延迟（秒）。 | -| tidb_cloud.node_disk_write_latency | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的写延迟（秒）。 | -| tidb_cloud.db_kv_request_duration | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv`
cluster_name: ``
`type`: `BatchGet\|Commit\|Prewrite\|...` | 按类型统计的 TiKV 请求持续时间（秒）。 | -| tidb_cloud.db_component_uptime | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tidb\|tikv\|tiflash`
cluster_name: `` | TiDB 组件的运行时长（秒）。 | -| tidb_cloud.cdc_changefeed_latency (AKA cdc_changefeed_checkpoint_ts_lag) | gauge | changefeed_id: ``
cluster_name: ``| changefeed owner 的 checkpoint timestamp 延迟（秒）。 | -| tidb_cloud.cdc_changefeed_resolved_ts_lag | gauge | changefeed_id: ``
cluster_name: `` | changefeed owner 的 resolved timestamp 延迟（秒）。 | +| tidb_cloud.node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: `` | TiKV/TiFlash 节点可用磁盘空间，单位为字节。 | +| tidb_cloud.node_disk_read_latency | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的读延迟，单位为秒。 | +| tidb_cloud.node_disk_write_latency | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的写延迟，单位为秒。 | +| tidb_cloud.db_kv_request_duration | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv`
cluster_name: ``
`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 按类型请求的持续时间，单位为秒。 | +| tidb_cloud.db_component_uptime | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tidb\|tikv\|tiflash`
cluster_name: `` | TiDB 组件的运行时间（单位为秒）。 | +| tidb_cloud.cdc_changefeed_latency (AKA cdc_changefeed_checkpoint_ts_lag) | gauge | changefeed_id: ``
cluster_name: ``| changefeed owner 的 checkpoint timestamp 延迟（单位为秒）。 | +| tidb_cloud.cdc_changefeed_resolved_ts_lag | gauge | changefeed_id: ``
cluster_name: `` | changefeed owner 的 resolved timestamp 延迟（单位为秒）。 | | tidb_cloud.cdc_changefeed_status | gauge | changefeed_id: ``
cluster_name: `` | Changefeed 状态：
`-1`: Unknown
`0`: Normal
`1`: Warning
`2`: Failed
`3`: Stopped
`4`: Finished
`6`: Warning
`7`: Other | | tidb_cloud.resource_manager_resource_unit_read_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的读请求单元（RU）。 | | tidb_cloud.resource_manager_resource_unit_write_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的写请求单元（RU）。 | -| tidb_cloud.dm_task_state | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移的任务状态：
0: Invalid
1: New
2: Running
3: Paused
4: Stopped
5: Finished
15: Error | +| tidb_cloud.dm_task_state | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移任务状态：
0: Invalid
1: New
2: Running
3: Paused
4: Stopped
5: Finished
15: Error | | tidb_cloud.dm_syncer_replication_lag_bucket | gauge | instance: `instance`
cluster_name: `` | 数据迁移的复制延迟（bucket）。 | | tidb_cloud.dm_syncer_replication_lag_gauge | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移的复制延迟（gauge）。 | | tidb_cloud.dm_relay_read_error_count | gauge | instance: `instance`
cluster_name: `` | 从主库读取 binlog 失败次数。 | -| tidb_cloud.node_memory_available_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点可用内存（字节）。 | +| tidb_cloud.node_memory_available_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点可用内存，单位为字节。 | | tidb_cloud.cdc_changefeed_replica_rows | gauge | changefeed_id: ``
cluster_name: `` | TiCDC 节点每秒写入下游的事件数。 | \ No newline at end of file diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index 21173e9f4f6a0..2328dd694223e 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -5,30 +5,30 @@ summary: 了解如何通过 New Relic 集成监控你的 TiDB 集群。 # 集成 TiDB Cloud 与 New Relic -TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将你的 TiDB 集群的指标发送到 [New Relic](https://newrelic.com/)。之后，你可以直接在 New Relic 的仪表盘中查看这些指标。 +TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB 集群的指标发送到 [New Relic](https://newrelic.com/)。之后，你可以直接在 New Relic 仪表盘中查看这些指标。 ## New Relic 集成版本 自 2023 年 4 月 11 日起，TiDB Cloud 支持项目级 New Relic 集成（Beta）。自 2025 年 7 月 31 日起，TiDB Cloud 推出集群级 New Relic 集成（预览版）。自 2025 年 9 月 30 日起，集群级 New Relic 集成将正式发布（GA）。 - **集群级 New Relic 集成**：如果在 2025 年 7 月 31 日前，你的组织内没有未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 将为你的组织提供集群级 New Relic 集成，以体验最新的增强功能。 -- **旧版项目级 New Relic 集成（Beta）**：如果在 2025 年 7 月 31 日前，你的组织内至少有一个未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 会在项目级保留现有和新建的集成，以避免影响当前的仪表盘。请注意，旧版项目级 New Relic 集成将于 2025 年 10 月 31 日弃用。如果你的组织仍在使用这些旧版集成，请按照 [迁移 Datadog 和 New Relic 集成](/tidb-cloud/migrate-metrics-integrations.md) 的指引，迁移到新的集群级集成，以最大程度减少对指标相关服务的影响。 +- **旧版项目级 New Relic 集成（Beta）**：如果在 2025 年 7 月 31 日前，你的组织内至少有一个未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 会在项目级保留现有和新建的集成，以避免影响当前的仪表盘。请注意，旧版项目级 New Relic 集成将于 2025 年 10 月 31 日弃用。如果你的组织仍在使用这些旧版集成，请按照 [迁移 Datadog 和 New Relic 集成](/tidb-cloud/migrate-metrics-integrations.md) 迁移到新的集群级集成，以最大程度减少对指标相关服务的影响。 ## 前提条件 -- 若要将 TiDB Cloud 与 New Relic 集成，你必须拥有一个 [New Relic](https://newrelic.com/) 账号，并[创建一个 `Ingest - License` 类型的 New Relic API key](https://one.newrelic.com/admin-portal/api-keys/home?)。 +- 要将 TiDB Cloud 与 New Relic 集成，你必须拥有一个 [New Relic](https://newrelic.com/) 账号，并[创建一个 `Ingest - License` 类型的 New Relic API 密钥](https://one.newrelic.com/admin-portal/api-keys/home?)。 如果你还没有 New Relic 账号，请在 [这里](https://newrelic.com/signup) 注册。 -- 若要为 TiDB Cloud 设置第三方指标集成，你必须在 TiDB Cloud 中拥有 `Organization Owner` 或 `Project Owner` 权限。若要通过提供的链接查看集成页面或访问已配置的仪表盘，你至少需要 `Project Viewer` 角色，以访问 TiDB Cloud 项目下的目标集群。 +- 要为 TiDB Cloud 设置第三方指标集成，你必须在 TiDB Cloud 中拥有 `Organization Owner` 或 `Project Owner` 权限。要通过提供的链接查看集成页面或访问已配置的仪表盘，你至少需要 `Project Viewer` 角色，以访问项目下的目标集群。 ## 限制 -- 你无法在 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 或 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群中使用 New Relic 集成。 +- New Relic 集成目前仅适用于 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 -- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，New Relic 集成不可用。 +- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，不支持 New Relic 集成。 -- 当带有 New Relic 集成的集群被删除时，其关联的集成服务也会被移除。 +- 当删除已集成 New Relic 的集群时，其关联的集成服务也会被移除。 ## 操作步骤 @@ -39,10 +39,10 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将你的 T
-1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入你项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称，进入其概览页面。 +1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入你项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称进入其概览页面。 2. 在左侧导航栏，点击 **Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to New Relic**。 -4. 输入你的 New Relic API key，并选择 New Relic 的站点。 +4. 输入你的 New Relic API Key，并选择 New Relic 的站点。 5. 点击 **Test Integration**。 - 如果测试成功，会显示 **Confirm** 按钮。 @@ -56,7 +56,7 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将你的 T 1. 在 [TiDB Cloud 控制台](https://tidbcloud.com)中，使用左上角的下拉框切换到目标项目。 2. 在左侧导航栏，点击 **Project Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to New Relic (BETA)**。 -4. 输入你的 New Relic API key，并选择 New Relic 的站点。 +4. 输入你的 New Relic API Key，并选择 New Relic 的站点。 5. 点击 **Test Integration**。 - 如果测试成功，会显示 **Confirm** 按钮。 @@ -102,7 +102,7 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将你的 T > **注意**： > - > 为避免集成出错，请确保你的账号 ID 已添加到 JSON 文件中所有的 `"accountIds"` 字段。 + > 为避免集成报错，请确保你的账号 ID 已添加到 JSON 文件中所有 `"accountIds"` 字段。 2. 登录 [New Relic](https://one.newrelic.com/)，点击左侧导航栏的 **Dashboards**，然后点击右上角的 **Import dashboard**。 3. 在弹出的对话框中，将准备好的 JSON 文件内容全部粘贴到文本区域，然后点击 **Import dashboard**。 @@ -121,7 +121,7 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将你的 T 1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入 **Integrations** 页面。 -2. 在 **New Relic** 区域点击 **Dashboard** 链接，查看你的 TiDB 集群的预置仪表盘。 +2. 在 **New Relic** 区域点击 **Dashboard** 链接，查看 TiDB 集群的预置仪表盘。 3. 根据你的 [New Relic 集成版本](#new-relic-集成版本)，执行以下操作之一： @@ -136,8 +136,8 @@ New Relic 会跟踪你的 TiDB 集群的以下指标。 | :------------| :---------- | :------| :----------------------------------------------------- | | tidb_cloud.db_database_time| gauge | sql_type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒在 TiDB 中运行的所有 SQL 语句消耗的总时间，包括所有进程的 CPU 时间和非空闲等待时间。 | | tidb_cloud.db_query_per_second| gauge | type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 所有 TiDB 实例每秒执行的 SQL 语句数量，按 `SELECT`、`INSERT`、`UPDATE` 等语句类型统计。 | -| tidb_cloud.db_average_query_duration| gauge | sql_type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 客户端网络请求发送到 TiDB 与 TiDB 执行后返回给客户端之间的耗时。 | -| tidb_cloud.db_failed_queries| gauge | type: executor:xxxx\|parser:xxxx\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒每个 TiDB 实例发生的 SQL 执行错误，按错误类型（如语法错误、主键冲突等）统计。 | +| tidb_cloud.db_average_query_duration| gauge | sql_type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 客户端网络请求发送到 TiDB 与 TiDB 执行后返回给客户端之间的持续时间。 | +| tidb_cloud.db_failed_queries| gauge | type: executor:xxxx\|parser:xxxx\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒每个 TiDB 实例发生的 SQL 执行错误（如语法错误、主键冲突等）类型统计。 | | tidb_cloud.db_total_connection| gauge | cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 当前 TiDB 服务器的连接数。 | | tidb_cloud.db_active_connections| gauge | cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 活跃连接数。 | | tidb_cloud.db_disconnections| gauge | result: ok\|error\|undetermined

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 断开连接的客户端数量。 | @@ -158,7 +158,7 @@ New Relic 会跟踪你的 TiDB 集群的以下指标。 | tidb_cloud.node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv\|tiflash`

cluster_name: `` | TiKV 或 TiFlash 节点可用磁盘空间（字节）。 | | tidb_cloud.node_disk_read_latency | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv\|tiflash`

cluster_name: ``

`device`: `nvme.*\|dm.*` | 每个存储设备的读延迟（秒）。 | | tidb_cloud.node_disk_write_latency | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv\|tiflash`

cluster_name: ``

`device`: `nvme.*\|dm.*` | 每个存储设备的写延迟（秒）。 | -| tidb_cloud.db_kv_request_duration | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv`

cluster_name: ``

`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 按类型请求的耗时（秒）。 | +| tidb_cloud.db_kv_request_duration | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv`

cluster_name: ``

`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 按类型请求的持续时间（秒）。 | | tidb_cloud.db_component_uptime | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tidb\|tikv\|tiflash`

cluster_name: `` | TiDB 组件的运行时长（秒）。 | | tidb_cloud.cdc_changefeed_latency (AKA cdc_changefeed_checkpoint_ts_lag) | gauge | changefeed_id: ``

cluster_name: ``| changefeed owner 的 checkpoint timestamp 延迟（秒）。 | | tidb_cloud.cdc_changefeed_resolved_ts_lag | gauge | changefeed_id: ``

cluster_name: `` | changefeed owner 的 resolved timestamp 延迟（秒）。 | diff --git a/tidb-cloud/monitor-prometheus-and-grafana-integration.md b/tidb-cloud/monitor-prometheus-and-grafana-integration.md index 2c5ed198f8688..da60f2a8e735a 100644 --- a/tidb-cloud/monitor-prometheus-and-grafana-integration.md +++ b/tidb-cloud/monitor-prometheus-and-grafana-integration.md @@ -1,79 +1,107 @@ --- -title: 集成 TiDB Cloud 与 Prometheus 和 Grafana（Beta） +title: 集成 TiDB Cloud 与 Prometheus 和 Grafana summary: 了解如何通过 Prometheus 和 Grafana 集成监控你的 TiDB 集群。 --- -# 集成 TiDB Cloud 与 Prometheus 和 Grafana（Beta） +# 集成 TiDB Cloud 与 Prometheus 和 Grafana -TiDB Cloud 提供了一个 [Prometheus](https://prometheus.io/) API 端点（Beta）。如果你拥有 Prometheus 服务，可以轻松地通过该端点监控 TiDB Cloud 的关键指标。 +TiDB Cloud 提供了一个 [Prometheus](https://prometheus.io/) API 端点。如果你拥有 Prometheus 服务，可以轻松地通过该端点监控 TiDB Cloud 的关键指标。 本文档介绍了如何配置 Prometheus 服务以从 TiDB Cloud 端点读取关键指标，以及如何使用 [Grafana](https://grafana.com/) 查看这些指标。 +## Prometheus 集成版本 + +自 2022 年 3 月 15 日起，TiDB Cloud 支持项目级 Prometheus 集成（Beta）。自 2025 年 10 月 21 日起，TiDB Cloud 推出了集群级 Prometheus 集成（预览版）。 + +- **集群级 Prometheus 集成（预览版）**：如果在 2025 年 10 月 21 日前，你的组织内没有未删除的遗留项目级 Prometheus 集成，TiDB Cloud 将为你的组织提供集群级 Prometheus 集成（预览版），以体验最新的增强功能。 + + > **注意** + > + > 目前，集群级 Prometheus 集成（预览版）仅适用于托管在 AWS 和 Google Cloud 上的 TiDB Cloud Dedicated 集群。 + +- **遗留项目级 Prometheus 集成（Beta）**：如果在 2025 年 10 月 21 日前，你的组织内至少有一个未删除的遗留项目级 Prometheus 集成，TiDB Cloud 会保留现有和新建的项目级集成，以避免影响当前的仪表盘。 + ## 前提条件 -- 若要将 TiDB Cloud 与 Prometheus 集成，你必须拥有自托管或托管的 Prometheus 服务。 +- 要将 TiDB Cloud 与 Prometheus 集成，你必须拥有自托管或托管的 Prometheus 服务。 -- 若要编辑 TiDB Cloud 的第三方集成设置，你必须拥有组织的 **Organization Owner** 权限，或在 TiDB Cloud 中拥有目标项目的 **Project Member** 权限。 +- 要为 TiDB Cloud 设置第三方指标集成，你必须在 TiDB Cloud 中拥有 `Organization Owner` 或 `Project Owner` 权限。要查看集成页面，至少需要 `Project Viewer` 角色以访问 TiDB Cloud 项目下的目标集群。 ## 限制 -- 你无法在 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群中使用 Prometheus 和 Grafana 集成。 - -- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，Prometheus 和 Grafana 集成不可用。 +- Prometheus 和 Grafana 集成目前仅适用于 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 +- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，不支持 Prometheus 和 Grafana 集成。 ## 步骤 ### 步骤 1. 获取 Prometheus 的 scrape_config 文件 -在配置 Prometheus 服务以读取 TiDB Cloud 指标之前，你需要先在 TiDB Cloud 中生成一个 `scrape_config` YAML 文件。该 `scrape_config` 文件包含一个唯一的 bearer token，允许 Prometheus 服务监控当前项目中的所有数据库集群。 +在配置 Prometheus 服务以读取 TiDB Cloud 指标之前，你需要先在 TiDB Cloud 中生成一个 `scrape_config` YAML 文件。该 `scrape_config` 文件包含一个唯一的 bearer token，允许 Prometheus 服务监控你的目标集群。 + +根据你的 [Prometheus 集成版本](#prometheus-集成版本)，获取 Prometheus 的 `scrape_config` 文件和访问集成页面的步骤有所不同。 + + +
-要获取 Prometheus 的 `scrape_config` 文件，请执行以下操作： +1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，导航到你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称进入其概览页面。 +2. 在左侧导航栏，点击 **Settings** > **Integrations**。 +3. 在 **Integrations** 页面，点击 **Integration to Prometheus (Preview)**。 +4. 点击 **Add File**，为当前集群生成并显示 `scrape_config` 文件。 +5. 复制 `scrape_config` 文件内容，供后续使用。 -1. 在 [TiDB Cloud 控制台](https://tidbcloud.com) 中，使用左上角的下拉框切换到你的目标项目。 +
+
+ +1. 在 [TiDB Cloud 控制台](https://tidbcloud.com)中，使用左上角的下拉框切换到目标项目。 2. 在左侧导航栏，点击 **Project Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to Prometheus (BETA)**。 4. 点击 **Add File**，为当前项目生成并显示 scrape_config 文件。 +5. 复制 scrape_config 文件内容，供后续使用。 -5. 复制 `scrape_config` 文件的内容，以备后续使用。 +
+ - > **注意：** - > - > 出于安全考虑，TiDB Cloud 只会显示新生成的 `scrape_config` 文件一次。请确保在关闭文件窗口前复制内容。如果忘记复制，需要在 TiDB Cloud 中删除该 `scrape_config` 文件并重新生成。要删除 `scrape_config` 文件，选择该文件，点击 **...**，然后点击 **Delete**。 +> **注意：** +> +> 出于安全考虑，TiDB Cloud 只会显示新生成的 `scrape_config` 文件一次。请确保在关闭文件窗口前复制内容。如果忘记复制，需要在 TiDB Cloud 中删除该 `scrape_config` 文件并重新生成。要删除 `scrape_config` 文件，选择该文件，点击 **...**，然后点击 **Delete**。 ### 步骤 2. 集成 Prometheus -1. 在你的 Prometheus 服务指定的监控目录中，找到 Prometheus 配置文件。 +1. 在你的 Prometheus 服务指定的监控目录下，找到 Prometheus 配置文件。 - 例如，`/etc/prometheus/prometheus.yml`。 + 例如：`/etc/prometheus/prometheus.yml`。 2. 在 Prometheus 配置文件中，找到 `scrape_configs` 部分，然后将从 TiDB Cloud 获取的 `scrape_config` 文件内容复制到该部分。 -3. 在你的 Prometheus 服务中，检查 **Status** > **Targets**，确认新的 `scrape_config` 文件已被读取。如果没有，你可能需要重启 Prometheus 服务。 +3. 在 Prometheus 服务中，检查 **Status** > **Targets**，确认新的 `scrape_config` 文件已被读取。如果没有生效，可能需要重启 Prometheus 服务。 ### 步骤 3. 使用 Grafana GUI 仪表盘可视化指标 当你的 Prometheus 服务已从 TiDB Cloud 读取指标后，可以按如下方式使用 Grafana GUI 仪表盘进行可视化： -1. 在 [此处](https://github.com/pingcap/docs/blob/master/tidb-cloud/monitor-prometheus-and-grafana-integration-grafana-dashboard-UI.json) 下载 TiDB Cloud 的 Grafana 仪表盘 JSON 文件。 +1. 根据你的 [Prometheus 集成版本](#prometheus-集成版本)，下载 TiDB Cloud for Prometheus 的 Grafana 仪表盘 JSON 文件的链接不同。 + + - 对于集群级 Prometheus 集成（预览版），请在 [此处](https://github.com/pingcap/docs/blob/master/tidb-cloud/monitor-prometheus-and-grafana-integration-tidb-cloud-dynamic-tracker.json) 下载 Grafana 仪表盘 JSON 文件。 + - 对于遗留项目级 Prometheus 集成（Beta），请在 [此处](https://github.com/pingcap/docs/blob/master/tidb-cloud/monitor-prometheus-and-grafana-integration-grafana-dashboard-UI.json) 下载 Grafana 仪表盘 JSON 文件。 + +2. [将该 JSON 导入到你自己的 Grafana GUI](https://grafana.com/docs/grafana/v8.5/dashboards/export-import/#import-dashboard)，以可视化指标。 -2. [将该 JSON 导入到你自己的 Grafana GUI](https://grafana.com/docs/grafana/v8.5/dashboards/export-import/#import-dashboard) 以可视化指标。 - > **注意：** > - > 如果你已经在使用 Prometheus 和 Grafana 监控 TiDB Cloud，并希望引入新提供的指标，建议新建一个仪表盘，而不是直接更新现有仪表盘的 JSON。 + > 如果你已经在使用 Prometheus 和 Grafana 监控 TiDB Cloud，并希望引入新可用的指标，建议新建一个仪表盘，而不是直接更新现有仪表盘的 JSON。 -3. （可选）根据需要自定义仪表盘，例如添加或移除面板、变更数据源、修改显示选项等。 +3. （可选）根据需要自定义仪表盘，例如添加或移除面板、修改数据源和调整显示选项。 关于如何使用 Grafana 的更多信息，请参见 [Grafana 文档](https://grafana.com/docs/grafana/latest/getting-started/getting-started-prometheus/)。 -## scrape_config 的轮换最佳实践 +## scrape_config 轮换的最佳实践 -为提升数据安全性，建议定期轮换 `scrape_config` 文件中的 bearer token。 +为提升数据安全性，建议定期轮换 `scrape_config` 文件的 bearer token。 -1. 按照 [步骤 1](#step-1-get-a-scrape_config-file-for-prometheus) 为 Prometheus 创建新的 `scrape_config` 文件。 -2. 将新文件的内容添加到你的 Prometheus 配置文件中。 +1. 按照 [步骤 1](#步骤-1-获取-prometheus-的-scrape_config-文件) 为 Prometheus 创建新的 `scrape_config` 文件。 +2. 将新文件的内容添加到 Prometheus 配置文件中。 3. 确认 Prometheus 服务仍能从 TiDB Cloud 读取数据后，从 Prometheus 配置文件中移除旧的 `scrape_config` 文件内容。 -4. 在项目的 **Integrations** 页面，删除对应的旧 `scrape_config` 文件，防止他人使用其读取 TiDB Cloud Prometheus 端点。 +4. 在项目或集群的 **Integrations** 页面，删除对应的旧 `scrape_config` 文件，以阻止他人使用其访问 TiDB Cloud Prometheus 端点。 ## Prometheus 可用指标 @@ -85,27 +113,36 @@ Prometheus 会跟踪你的 TiDB 集群的以下指标数据。 | tidbcloud_db_failed_queries_total | count | type: `planner:xxx\|executor:2345\|...`
cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 执行错误的总数 | | tidbcloud_db_connections | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 当前 TiDB 服务器的连接数 | | tidbcloud_db_query_duration_seconds | histogram | sql_type: `Select\|Insert\|...`
cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 语句的耗时直方图 | -| tidbcloud_changefeed_latency | gauge | changefeed_id | changefeed 上游与下游之间的数据同步延迟 | -| tidbcloud_changefeed_checkpoint_ts | gauge | changefeed_id | changefeed 的检查点时间戳，表示已成功写入下游的最大 TSO（Timestamp Oracle）| +| tidbcloud_changefeed_latency | gauge | changefeed_id | changefeed 上游与下游的数据同步延迟 | +| tidbcloud_changefeed_checkpoint_ts | gauge | changefeed_id | changefeed 的检查点时间戳，表示已成功写入下游的最大 TSO（Timestamp Oracle） | | tidbcloud_changefeed_replica_rows | gauge | changefeed_id | changefeed 每秒写入下游的同步行数 | | tidbcloud_node_storage_used_bytes | gauge | cluster_name: ``
instance: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
component: `tikv\|tiflash` | TiKV/TiFlash 节点的磁盘已用字节数 | | tidbcloud_node_storage_capacity_bytes | gauge | cluster_name: ``
instance: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
component: `tikv\|tiflash` | TiKV/TiFlash 节点的磁盘容量字节数 | | tidbcloud_node_cpu_seconds_total | count | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的 CPU 使用量 | -| tidbcloud_node_cpu_capacity_cores | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的 CPU 限制核数 | +| tidbcloud_node_cpu_capacity_cores | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的 CPU 限制核心数 | | tidbcloud_node_memory_used_bytes | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的已用内存字节数 | | tidbcloud_node_memory_capacity_bytes | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的内存容量字节数 | -| tidbcloud_node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: `` | TiKV/TiFlash 节点可用磁盘空间（字节）| -| tidbcloud_disk_read_latency | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的读延迟（秒）| -| tidbcloud_disk_write_latency | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的写延迟（秒）| -| tidbcloud_kv_request_duration | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv`
cluster_name: ``
`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 按类型请求的耗时（秒）| -| tidbcloud_component_uptime | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tidb\|tikv\|tiflash`
cluster_name: `` | TiDB 组件的运行时长（秒）| -| tidbcloud_ticdc_owner_resolved_ts_lag | gauge | changefeed_id: ``
cluster_name: `` | changefeed owner 的 resolved timestamp 延迟（秒）| +| tidbcloud_node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: `` | TiKV/TiFlash 节点可用磁盘空间（字节） | +| tidbcloud_disk_read_latency | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的读延迟（秒） | +| tidbcloud_disk_write_latency | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的写延迟（秒） | +| tidbcloud_kv_request_duration | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv`
cluster_name: ``
`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 按类型请求的耗时（秒） | +| tidbcloud_component_uptime | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tidb\|tikv\|tiflash`
cluster_name: `` | TiDB 组件的运行时长（秒） | +| tidbcloud_ticdc_owner_resolved_ts_lag | gauge | changefeed_id: ``
cluster_name: `` | changefeed owner 的 resolved timestamp 延迟（秒） | | tidbcloud_changefeed_status | gauge | changefeed_id: ``
cluster_name: `` | changefeed 状态：
`-1`: 未知
`0`: 正常
`1`: 警告
`2`: 失败
`3`: 已停止
`4`: 已完成
`6`: 警告
`7`: 其他 | | tidbcloud_resource_manager_resource_unit_read_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的读请求单元 | | tidbcloud_resource_manager_resource_unit_write_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的写请求单元 | +对于集群级 Prometheus 集成，还可获取以下额外指标： + +| 指标名称 | 指标类型 | 标签 | 描述 | +|:--- |:--- |:--- |:--- | +| tidbcloud_dm_task_status | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移任务状态：
0: Invalid
1: New
2: Running
3: Paused
4: Stopped
5: Finished
15: Error | +| tidbcloud_dm_syncer_replication_lag_bucket | gauge | instance: `instance`
cluster_name: `` | 数据迁移的同步延迟（bucket） | +| tidbcloud_dm_syncer_replication_lag_gauge | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移的同步延迟（gauge） | +| tidbcloud_dm_relay_read_error_count | count | instance: `instance`
cluster_name: `` | 从主库读取 binlog 失败的次数 | + ## 常见问题 - 为什么同一指标在 Grafana 和 TiDB Cloud 控制台上同时显示的数值不同？ - 因为 Grafana 和 TiDB Cloud 的聚合计算逻辑不同，所以显示的聚合值可能会有差异。你可以调整 Grafana 中的 `mini step` 配置，以获得更细粒度的指标值。 \ No newline at end of file + Grafana 和 TiDB Cloud 的聚合计算逻辑不同，因此显示的聚合值可能存在差异。你可以在 Grafana 中调整 `mini step` 配置，以获得更细粒度的指标值。 \ No newline at end of file diff --git a/tidb-cloud/monitoring-concepts.md b/tidb-cloud/monitoring-concepts.md index 755d05192a23c..65bf961a3c436 100644 --- a/tidb-cloud/monitoring-concepts.md +++ b/tidb-cloud/monitoring-concepts.md @@ -9,7 +9,7 @@ TiDB Cloud 的监控为你提供了工具和集成，能够监督集群性能、 ## 内置指标 -内置指标是指 TiDB Cloud 收集并在 **Metrics** 页面展示的集群标准指标全集。通过这些指标，你可以轻松识别性能问题，并判断当前的数据库部署是否满足你的需求。 +内置指标是指 TiDB Cloud 收集并在 **Metrics** 页面展示的集群全套标准指标。通过这些指标，你可以轻松识别性能问题，并判断当前的数据库部署是否满足你的需求。 更多信息，参见 [TiDB Cloud Built-in Metrics](/tidb-cloud/built-in-monitoring.md)。 @@ -39,6 +39,6 @@ TiDB Cloud 支持集成以下任一第三方指标服务，以接收 TiDB Cloud - [Datadog integration](/tidb-cloud/monitor-datadog-integration.md) -- [Prometheus and Grafana integration (Beta)](/tidb-cloud/monitor-prometheus-and-grafana-integration.md) +- [Prometheus and Grafana integration](/tidb-cloud/monitor-prometheus-and-grafana-integration.md) - [New Relic integration](/tidb-cloud/monitor-new-relic-integration.md) \ No newline at end of file diff --git a/tidb-cloud/notifications.md b/tidb-cloud/notifications.md index 53b18ccacd025..646eb7cdf21f1 100644 --- a/tidb-cloud/notifications.md +++ b/tidb-cloud/notifications.md @@ -13,7 +13,7 @@ summary: 了解 TiDB Cloud 控制台中的通知，包括通知类型、用途 - **Informational notifications** - 提供有用的更新信息，如功能使用提示、应用变更或即将到来的事件提醒。 + 提供有用的更新信息，如功能使用提示、应用变更或即将发生事件的提醒。 - **Actionable notifications** @@ -29,7 +29,7 @@ summary: 了解 TiDB Cloud 控制台中的通知，包括通知类型、用途 - **Feedback notifications** - 请求你对某个功能的使用体验进行反馈，例如对最近的交互进行评分或完成调查问卷。 + 邀请你对某项功能的使用体验进行反馈，例如对最近的交互进行评分或填写调查问卷。 ## 通知列表 @@ -37,15 +37,17 @@ summary: 了解 TiDB Cloud 控制台中的通知，包括通知类型、用途 | Notification | Trigger event | Notification recipient | | --- | --- | --- | -| TiDB Cloud Serverless cluster creation | 创建了一个 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群。 | 所有项目成员 | -| TiDB Cloud Serverless cluster deletion | 删除了一个 TiDB Cloud Serverless 集群。 | 所有项目成员 | +| TiDB Cloud Starter cluster creation | 创建了一个 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群。 | 所有项目成员 | +| TiDB Cloud Starter cluster deletion | 删除了一个 TiDB Cloud Starter 集群。 | 所有项目成员 | +| TiDB Cloud Essential cluster creation | 创建了一个 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群。 | 所有项目成员 | +| TiDB Cloud Essential cluster deletion | 删除了一个 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群。 | 所有项目成员 | | TiDB Cloud Dedicated cluster creation | 创建了一个 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 | 所有项目成员 | | TiDB Cloud Dedicated cluster deletion | 删除了一个 TiDB Cloud Dedicated 集群。 | 所有项目成员 | | Organization Budget threshold alert | 达到组织的 [预算阈值](/tidb-cloud/tidb-cloud-budget.md)。 | `Organization Owner`、`Organization Billing Manager` 和 `Organization Billing Viewer` | | Project Budget threshold alert | 达到项目的 [预算阈值](/tidb-cloud/tidb-cloud-budget.md)。 | `Organization Owner`、`Organization Billing Manager`、`Organization Billing Viewer` 和 `Project Owner` | -| Serverless cluster spending limit threshold alert | 组织内 TiDB Cloud Serverless 集群的 [消费限额阈值](/tidb-cloud/manage-serverless-spend-limit.md) 达到。 | `Organization Owner`、`Organization Billing Manager`、`Organization Billing Viewer` 和 `Project Owner` | -| Credits update | 组织的 [Credits](/tidb-cloud/tidb-cloud-billing.md#credits) 被应用、全部用完、回收或过期。 | `Organization Owner`、`Organization Billing Manager` 和 `Organization Billing Viewer` | -| Discount update | 组织的 [Discounts](/tidb-cloud/tidb-cloud-billing.md#discounts) 被应用、回收或过期。 | `Organization Owner`、`Organization Billing Manager` 和 `Organization Billing Viewer` | +| Starter cluster spending limit threshold alert | 组织中 TiDB Cloud Starter 集群的 [消费限额阈值](/tidb-cloud/manage-serverless-spend-limit.md) 达到。 | `Organization Owner`、`Organization Billing Manager`、`Organization Billing Viewer` 和 `Project Owner` | +| Credits update | 组织的 [积分](/tidb-cloud/tidb-cloud-billing.md#credits) 被应用、全部用完、被回收或过期。 | `Organization Owner`、`Organization Billing Manager` 和 `Organization Billing Viewer` | +| Discount update | 组织的 [折扣](/tidb-cloud/tidb-cloud-billing.md#discounts) 被应用、被回收或过期。 | `Organization Owner`、`Organization Billing Manager` 和 `Organization Billing Viewer` | | Marketplace update | 组织通过云服务商市场订阅或取消订阅。 | 所有组织成员 | | Support plan update | 组织的支持计划订阅发生变更。 | 所有组织成员 | @@ -53,4 +55,4 @@ summary: 了解 TiDB Cloud 控制台中的通知，包括通知类型、用途 要查看通知，请点击 [TiDB Cloud 控制台](https://tidbcloud.com/) 左下角的 **Notification**。 -当有新通知时，**Notification** 旁会显示一个数字，表示有多少条未读通知。 \ No newline at end of file +当有新通知时，**Notification** 旁会显示一个数字，表示有多少条通知未读。 \ No newline at end of file diff --git a/tidb-cloud/pause-or-resume-tidb-cluster.md b/tidb-cloud/pause-or-resume-tidb-cluster.md index bfbf55d5071a5..dfb608283eab9 100644 --- a/tidb-cloud/pause-or-resume-tidb-cluster.md +++ b/tidb-cloud/pause-or-resume-tidb-cluster.md @@ -1,11 +1,11 @@ --- -title: 暂停或恢复 TiDB Cloud Dedicated 集群 -summary: 了解如何暂停或恢复 TiDB Cloud Dedicated 集群。 +title: 暂停或恢复 TiDB Cloud 专属集群 +summary: 了解如何暂停或恢复 TiDB Cloud 专属集群。 --- -# 暂停或恢复 TiDB Cloud Dedicated 集群 +# 暂停或恢复 TiDB Cloud 专属集群 -你可以在 TiDB Cloud 中轻松暂停和恢复并非始终运行的 TiDB Cloud Dedicated 集群。 +你可以在 TiDB Cloud 中轻松暂停和恢复并非始终运行的 TiDB Cloud 专属集群。 暂停操作不会影响存储在集群中的数据，只是停止监控信息的收集和计算资源的消耗。暂停后，你可以随时恢复集群。 @@ -13,21 +13,21 @@ summary: 了解如何暂停或恢复 TiDB Cloud Dedicated 集群。 > **注意：** > -> 你无法暂停 [TiDB Cloud Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)。 +> 你无法暂停 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 或 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群。 ## 限制 - 只有当集群处于 **Available** 状态时，你才能暂停集群。如果集群处于 **Modifying** 等其他状态，你必须等待当前操作完成后才能暂停集群。 - 当有数据导入任务正在进行时，无法暂停集群。你可以等待导入任务完成或取消导入任务。 -- 当有备份任务正在进行时，无法暂停集群。你可以等待当前备份任务完成或[删除正在运行的备份任务](/tidb-cloud/backup-and-restore.md#delete-a-running-backup-job)。 -- 如果集群存在任何 [changefeeds](/tidb-cloud/changefeed-overview.md)，则无法暂停集群。你需要[删除现有的 changefeed](/tidb-cloud/changefeed-overview.md#delete-a-changefeed) 后才能暂停集群。 +- 当有备份任务正在进行时，无法暂停集群。你可以等待当前备份任务完成，或[删除正在运行的备份任务](/tidb-cloud/backup-and-restore.md#delete-a-running-backup-job)。 +- 如果集群存在任何 [changefeeds](/tidb-cloud/changefeed-overview.md)，则无法暂停。你需要[删除现有的 changefeed](/tidb-cloud/changefeed-overview.md#delete-a-changefeed) 后才能暂停集群。 ## 暂停 TiDB 集群 暂停时长和行为取决于你的组织创建日期： -- 2024 年 11 月 12 日之后创建的组织，采用标准暂停行为，最长暂停时长为 7 天。 -- 2024 年 11 月 12 日及之前创建的组织，采用兼容暂停行为，允许更长的暂停时长。这些组织将逐步过渡到标准的 7 天限制。 +- 2024 年 11 月 12 日之后创建的组织，遵循标准暂停行为，最长暂停时长为 7 天。 +- 2024 年 11 月 12 日及之前创建的组织，遵循兼容暂停行为，允许更长的暂停时长。这些组织将逐步过渡到标准的 7 天限制。
@@ -51,7 +51,7 @@ summary: 了解如何暂停或恢复 TiDB Cloud Dedicated 集群。 > **注意：** > -> 如果你的组织是在 2024 年 11 月 12 日之前创建的，集群仍采用兼容暂停行为。TiDB Cloud 会在过渡到新的标准暂停行为前通知你。 +> 如果你的组织是在 2024 年 11 月 12 日之前创建的，集群仍然遵循兼容暂停行为。TiDB Cloud 会在过渡到新的标准暂停行为前通知你。 当集群被暂停时，请注意以下事项： @@ -86,7 +86,7 @@ summary: 了解如何暂停或恢复 TiDB Cloud Dedicated 集群。 点击 **Pause** 后，集群会先进入 **Pausing** 状态。暂停操作完成后，集群会变为 **Paused** 状态。 -你也可以通过 TiDB Cloud API 暂停集群。目前，TiDB Cloud API 仍处于 beta 阶段。更多信息请参见 [TiDB Cloud API Documentation](https://docs.pingcap.com/tidbcloud/api/v1beta)。 +你也可以使用 TiDB Cloud API 暂停集群。目前，TiDB Cloud API 仍处于 beta 阶段。更多信息请参见 [TiDB Cloud API Documentation](https://docs.pingcap.com/tidbcloud/api/v1beta)。 ## 恢复 TiDB 集群 @@ -103,10 +103,10 @@ summary: 了解如何暂停或恢复 TiDB Cloud Dedicated 集群。 > **注意：** > - > 处于 **Pausing** 状态的集群无法恢复。 + > 你无法恢复处于 **Pausing** 状态的集群。 3. 在对话框中点击 **Resume** 以确认你的选择。集群状态会变为 **Resuming**。 根据你的集群规模，恢复集群可能需要几分钟。集群恢复后，状态会从 **Resuming** 变为 **Available**。 -你也可以通过 TiDB Cloud API 恢复集群。目前，TiDB Cloud API 仍处于 beta 阶段。更多信息请参见 [TiDB Cloud API Documentation](https://docs.pingcap.com/tidbcloud/api/v1beta)。 \ No newline at end of file +你也可以使用 TiDB Cloud API 恢复集群。目前，TiDB Cloud API 仍处于 beta 阶段。更多信息请参见 [TiDB Cloud API Documentation](https://docs.pingcap.com/tidbcloud/api/v1beta)。 \ No newline at end of file diff --git a/tidb-cloud/release-notes-2021.md b/tidb-cloud/release-notes-2021.md index ec62a3f2c1dd5..c9113b34896e7 100644 --- a/tidb-cloud/release-notes-2021.md +++ b/tidb-cloud/release-notes-2021.md @@ -1,128 +1,128 @@ --- -title: 2021 年 TiDB Cloud 发布说明 +title: TiDB Cloud Release Notes in 2021 summary: 了解 2021 年 TiDB Cloud 的发布说明。 --- # 2021 年 TiDB Cloud 发布说明 -本页列出了 2021 年 [TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 的发布说明。 +本页面列出了 [TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 在 2021 年的发布说明。 ## 2021 年 12 月 28 日 新功能： -* 支持[将 Apache Parquet 文件从 Amazon S3 或 GCS 导入到 TiDB Cloud](/tidb-cloud/import-parquet-files.md) +* 支持 [从 Amazon S3 或 GCS 导入 Apache Parquet 文件到 TiDB Cloud](/tidb-cloud/import-parquet-files.md) Bug 修复： -* 修复了向 TiDB Cloud 导入超过 1000 个文件时发生的导入错误 -* 修复了 TiDB Cloud 允许将数据导入到已有数据的现有表的问题 +* 修复了向 TiDB Cloud 导入超过 1000 个文件时出现的导入错误 +* 修复了 TiDB Cloud 允许向已有数据的现有表导入数据的问题 ## 2021 年 11 月 30 日 通用变更： -* 将 TiDB Cloud 的开发者层级升级到 [TiDB v5.3.0](https://docs.pingcap.com/tidb/stable/release-5.3.0) +* 将 TiDB Cloud 的 Developer Tier 升级到 [TiDB v5.3.0](https://docs.pingcap.com/tidb/stable/release-5.3.0) 新功能： -* 支持[为你的 TiDB Cloud 项目添加 VPC CIDR](/tidb-cloud/set-up-vpc-peering-connections.md) +* 支持 [为你的 TiDB Cloud 项目添加 VPC CIDR](/tidb-cloud/set-up-vpc-peering-connections.md) 改进： -* 提升开发者层级的监控能力 -* 支持将自动备份时间设置为与开发者层级集群的创建时间相同 +* 提升了 Developer Tier 的监控能力 +* 支持将自动备份时间设置为与 Developer Tier 集群创建时间相同 Bug 修复： -* 修复开发者层级中由于磁盘满导致的 TiKV 崩溃问题 -* 修复 HTML 注入漏洞 +* 修复了 Developer Tier 中由于磁盘满导致的 TiKV 崩溃问题 +* 修复了 HTML 注入漏洞 ## 2021 年 11 月 8 日 -* 发布 [开发者层级](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)，为你提供 TiDB Cloud 一年的免费试用 +* 上线 [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)，为你提供为期一年的 TiDB Cloud 免费试用 - 每个开发者层级集群都是一个功能齐全的 TiDB 集群，并包含以下内容： + 每个 Developer Tier 集群都是一个全功能的 TiDB 集群，并包含以下内容： * 一个 TiDB 共享节点 - * 一个 TiKV 共享节点（具有 500 MiB 的 OLTP 存储） - * 一个 TiFlash 共享节点（具有 500 MiB 的 OLAP 存储） + * 一个 TiKV 共享节点（含 500 MiB OLTP 存储） + * 一个 TiFlash 共享节点（含 500 MiB OLAP 存储） - 从[这里](/tidb-cloud/tidb-cloud-quickstart.md)开始。 + 立即开始 [使用](/tidb-cloud/tidb-cloud-quickstart.md)。 ## 2021 年 10 月 21 日 -* 开放个人邮箱账户的用户注册 -* 支持[从 Amazon S3 或 GCS 导入或迁移到 TiDB Cloud](/tidb-cloud/import-csv-files.md) +* 开放用户注册支持个人邮箱账号 +* 支持 [从 Amazon S3 或 GCS 导入或迁移到 TiDB Cloud](/tidb-cloud/import-csv-files.md) ## 2021 年 10 月 11 日 -* 支持[查看和导出 TiDB Cloud 的账单明细](/tidb-cloud/tidb-cloud-billing.md#billing-details)，包括每个服务和每个项目的成本 -* 修复了 TiDB Cloud 内部功能的几个问题 +* 支持 [查看和导出 TiDB Cloud 的账单明细](/tidb-cloud/tidb-cloud-billing.md#billing-details)，包括每项服务和每个项目的费用 +* 修复了 TiDB Cloud 内部功能的若干问题 ## 2021 年 9 月 16 日 -* 将新部署集群的默认 TiDB 版本从 5.2.0 升级到 5.2.1。 有关 5.2.1 的详细更改，请参阅 [5.2.1](https://docs.pingcap.com/tidb/stable/release-5.2.1) 发行说明。 +* 新部署集群的默认 TiDB 版本从 5.2.0 升级到 5.2.1。详细变更请参见 [5.2.1](https://docs.pingcap.com/tidb/stable/release-5.2.1) 发布说明。 ## 2021 年 9 月 2 日 -* 将新部署集群的默认 TiDB 版本从 5.0.2 升级到 5.2.0。 有关 TiDB 5.1.0 和 5.2.0 功能的详细信息，请参阅 [5.2.0](https://docs.pingcap.com/tidb/stable/release-5.2.0) 和 [5.1.0](https://docs.pingcap.com/tidb/stable/release-5.1.0) 发行说明。 -* 修复了 TiDB Cloud 内部功能的几个问题。 +* 新部署集群的默认 TiDB 版本从 5.0.2 升级到 5.2.0。TiDB 5.1.0 和 5.2.0 的详细功能请参见 [5.2.0](https://docs.pingcap.com/tidb/stable/release-5.2.0) 和 [5.1.0](https://docs.pingcap.com/tidb/stable/release-5.1.0) 发布说明。 +* 修复了 TiDB Cloud 内部功能的若干问题。 ## 2021 年 8 月 19 日 -* 修复了 TiDB Cloud 内部功能的几个问题。此版本不带来任何用户行为的更改。 +* 修复了 TiDB Cloud 内部功能的若干问题。本次发布未带来任何用户行为变更。 ## 2021 年 8 月 5 日 -* 支持组织角色管理。组织所有者可以根据需要配置组织成员的权限。 -* 支持组织内多个项目的隔离。组织所有者可以根据需要创建和管理项目，并且项目之间的成员和实例支持网络和权限隔离。 -* 优化账单，以显示当月和上个月的每个项目的账单明细。 +* 支持组织角色管理。组织所有者可根据需要配置组织成员的权限。 +* 支持组织内多个项目的隔离。组织所有者可根据需要创建和管理项目，项目间的成员和实例支持网络与权限隔离。 +* 优化账单，展示当月及上月各项明细账单。 ## 2021 年 7 月 22 日 * 优化添加信用卡的用户体验 * 加强信用卡的安全管理 -* 修复集群从备份恢复后无法正常计费的问题 +* 修复了从备份恢复的集群无法正常计费的问题 ## 2021 年 7 月 6 日 -* 将新部署集群的默认 TiDB 版本从 4.0.11 升级到 5.0.2。此次升级带来了显著的性能和功能改进。详情请参见[此处](https://docs.pingcap.com/tidb/stable/release-5.0.0)。 +* 新部署集群的默认 TiDB 版本从 4.0.11 升级到 5.0.2。此次升级带来了显著的性能和功能提升。详情请参见 [这里](https://docs.pingcap.com/tidb/stable/release-5.0.0)。 ## 2021 年 6 月 25 日 -* 修复了 [TiDB Cloud 定价](https://www.pingcap.com/pricing/) 页面上 **选择区域** 功能无法使用的问题 +* 修复了 [TiDB Cloud Pricing](https://www.pingcap.com/pricing/) 页面 **Select Region** 不生效的问题 ## 2021 年 6 月 24 日 -* 修复将 Aurora 快照导入 TiDB 实例时 Parquet 文件的解析错误 -* 修复 PoC 用户创建集群并更改集群配置时，预计工时未更新的问题 +* 修复了将 Aurora 快照导入 TiDB 实例时 parquet 文件解析错误的问题 +* 修复了 PoC 用户创建集群并更改集群配置时 Estimated Hours 未更新的问题 ## 2021 年 6 月 16 日 -* 在注册账户时，**中国**已添加到**国家/地区**下拉列表中 +* 注册账号时，**Country/Region** 下拉列表中新增 **China** ## 2021 年 6 月 14 日 -* 修复将 Aurora 快照导入 TiDB 实例时挂载 EBS 错误的bug +* 修复了将 Aurora 快照导入 TiDB 实例时挂载 EBS 失败的问题 ## 2021 年 5 月 10 日 通用 -* TiDB Cloud 现在处于公开预览阶段。你可以[注册](https://tidbcloud.com/signup)并选择以下试用选项之一： +* TiDB Cloud 现已进入 Public Preview 阶段。你可以 [注册](https://tidbcloud.com/signup) 并选择以下试用选项之一： - * 48小时免费试用 - * 2周 PoC 免费试用 - * 预览按需 + * 48 小时免费试用 + * 2 周 PoC 免费试用 + * Preview On-Demand 管理控制台 -* 注册流程中增加了邮箱验证和反机器人 reCAPTCHA +* 注册流程中新增邮箱验证和反机器人 reCAPTCHA * [TiDB Cloud 服务协议](https://pingcap.com/legal/tidb-cloud-services-agreement) 和 [PingCAP 隐私政策](https://pingcap.com/legal/privacy-policy/) 已更新 -* 你可以通过在控制台中填写申请表来申请 [PoC](/tidb-cloud/tidb-cloud-poc.md) -* 你可以通过 UI 将示例数据导入到 TiDB Cloud 集群中 -* 不允许使用相同名称的集群，以避免混淆 -* 你可以通过点击 **支持** 菜单中的 **提供反馈** 来提供反馈 -* 数据备份和恢复功能适用于 PoC 和按需试用选项 -* 为免费试用和 PoC 添加了积分计算器和积分使用情况仪表板。所有试用选项均免除数据存储和传输成本 +* 你可以在控制台填写申请表，申请 [PoC](/tidb-cloud/tidb-cloud-poc.md) +* 你可以通过 UI 向 TiDB Cloud 集群导入示例数据 +* 不允许创建同名集群，以避免混淆 +* 你可以通过 **Support** 菜单中的 **Give Feedback** 提交反馈 +* PoC 和按需试用选项支持数据备份与恢复功能 +* 免费试用和 PoC 新增积分计算器和积分使用仪表盘。所有试用选项均免除数据存储和传输费用 \ No newline at end of file diff --git a/tidb-cloud/release-notes-2022.md b/tidb-cloud/release-notes-2022.md index c38011f483f59..f7c246f312084 100644 --- a/tidb-cloud/release-notes-2022.md +++ b/tidb-cloud/release-notes-2022.md @@ -1,9 +1,9 @@ --- -title: 2022 年 TiDB Cloud 发布说明 +title: TiDB Cloud 2022 年发布说明 summary: 了解 TiDB Cloud 在 2022 年的发布说明。 --- -# 2022 年 TiDB Cloud 发布说明 +# TiDB Cloud 2022 年发布说明 本页面列出了 [TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 在 2022 年的发布说明。 @@ -11,13 +11,13 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 **通用变更** -- 目前，在将所有 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的默认 TiDB 版本从 [v6.3.0](https://docs-archive.pingcap.com/tidb/v6.3/release-6.3.0) 升级到 [v6.4.0](https://docs-archive.pingcap.com/tidb/v6.4/release-6.4.0) 后，在某些情况下冷启动变得更慢。因此我们将所有 Serverless Tier 集群的默认 TiDB 版本从 v6.4.0 回滚到 v6.3.0，随后尽快修复该问题，并在之后再次升级。 +- 目前，在将所有 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的默认 TiDB 版本从 [v6.3.0](https://docs-archive.pingcap.com/tidb/v6.3/release-6.3.0) 升级到 [v6.4.0](https://docs-archive.pingcap.com/tidb/v6.4/release-6.4.0) 后，在某些情况下冷启动变得更慢。因此我们将所有 Serverless Tier 集群的默认 TiDB 版本从 v6.4.0 回滚到 v6.3.0，随后会尽快修复该问题，并在之后再次升级。 ## 2022 年 12 月 27 日 **通用变更** -- 将所有 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的默认 TiDB 版本从 [v6.3.0](https://docs-archive.pingcap.com/tidb/v6.3/release-6.3.0) 升级到 [v6.4.0](https://docs-archive.pingcap.com/tidb/v6.4/release-6.4.0)。 +- 将所有 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的默认 TiDB 版本从 [v6.3.0](https://docs-archive.pingcap.com/tidb/v6.3/release-6.3.0) 升级到 [v6.4.0](https://docs-archive.pingcap.com/tidb/v6.4/release-6.4.0)。 - 专属集群（Dedicated Tier）现已正式支持时间点恢复（PITR）。 @@ -29,10 +29,10 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 - 支持管理多个 changefeed 及编辑已有 changefeed。 - - 你现在可以根据需要创建多个 changefeed 来管理不同的数据同步任务。目前每个集群最多可有 10 个 changefeed。更多详情请参考 [Changefeed 概览](/tidb-cloud/changefeed-overview.md)。 - - 你可以在 changefeed 处于暂停状态时编辑其配置。详细信息参见 [编辑 changefeed](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)。 + - 你现在可以根据需要创建多个 changefeed 来管理不同的数据同步任务。目前每个集群最多可有 10 个 changefeed。详情参见 [Changefeed 概览](/tidb-cloud/changefeed-overview.md)。 + - 你可以在 changefeed 处于暂停状态时编辑其配置。更多信息参见 [编辑 changefeed](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)。 -- 支持将 Amazon Aurora MySQL、Amazon Relational Database Service (RDS) MySQL 或自建 MySQL 兼容数据库的数据直接在线迁移到 TiDB Cloud。该功能现已正式发布。 +- 支持将 Amazon Aurora MySQL、Amazon RDS MySQL 或自建 MySQL 兼容数据库的数据直接在线迁移到 TiDB Cloud。该功能现已正式发布。 - 在以下 6 个区域提供服务： - AWS Oregon (us-west-2) @@ -41,9 +41,9 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 - AWS Singapore (ap-southeast-1) - AWS Tokyo (ap-northeast-1) - AWS Frankfurt (eu-central-1) - - 支持多种规格。你可以根据所需性能选择合适的规格，以获得最佳数据迁移体验。 + - 支持多种规格。你可以根据所需性能选择合适的规格，以获得最佳的数据迁移体验。 - 有关如何迁移数据到 TiDB Cloud，请参考 [用户文档](/tidb-cloud/migrate-from-mysql-using-data-migration.md)。计费详情请参考 [数据迁移计费](/tidb-cloud/tidb-cloud-billing-dm.md)。 + 有关如何迁移数据到 TiDB Cloud，请参见 [用户文档](/tidb-cloud/migrate-from-mysql-using-data-migration.md)。计费详情参见 [数据迁移计费](/tidb-cloud/tidb-cloud-billing-dm.md)。 - 支持将本地 CSV 文件导入到 TiDB Cloud。 @@ -57,7 +57,7 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 - 在 [Datadog](/tidb-cloud/monitor-datadog-integration.md) Dashboard 中新增 `project name` 标签作为筛选项，以便提供项目信息。 - 你可以使用 `project name` 筛选器快速找到你想要的集群。 + 你可以通过 `project name` 筛选器快速找到目标集群。 ## 2022 年 12 月 13 日 @@ -65,34 +65,34 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 - 为 Serverless Tier 引入 TiDB Cloud SQL Editor（Beta）。 - 这是一个基于 Web 的 SQL 编辑器，允许你直接针对 Serverless Tier 的数据库编辑和运行 SQL 查询。你可以在 Serverless Tier 集群的左侧导航栏中轻松找到它。 + 这是一个基于 Web 的 SQL 编辑器，允许你直接编辑并运行针对 Serverless Tier 数据库的 SQL 查询。你可以在 Serverless Tier 集群的左侧导航栏中轻松找到该功能。 对于 Serverless Tier，Web SQL Shell 已被 SQL Editor 替代。 -- 支持使用 [Changefeeds](/tidb-cloud/changefeed-overview.md) 为 Dedicated Tier 实现数据流式传输。 +- 支持使用 [Changefeeds](/tidb-cloud/changefeed-overview.md) 为专属集群（Dedicated Tier）进行数据流式传输。 - - 支持 [将数据变更日志流式传输到 MySQL](/tidb-cloud/changefeed-sink-to-mysql.md)。 + - 支持 [将数据变更日志流式同步到 MySQL](/tidb-cloud/changefeed-sink-to-mysql.md)。 - 当数据从 MySQL/Aurora 迁移到 TiDB 时，通常需要使用 MySQL 作为备用数据库以防止意外的数据迁移问题。在这种情况下，你可以使用 MySQL sink 将数据从 TiDB 流式传输到 MySQL。 + 当你从 MySQL/Aurora 迁移数据到 TiDB 时，通常需要将 MySQL 作为备用数据库以防止意外的数据迁移问题。在这种情况下，你可以使用 MySQL sink 将数据从 TiDB 流式同步到 MySQL。 - - 支持 [将数据变更日志流式传输到 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md)（Beta）。 + - 支持 [将数据变更日志流式同步到 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md)（Beta）。 - 将 TiDB 数据流式传输到消息队列是数据集成场景中非常常见的需求。你可以使用 Kafka sink 实现与其他数据处理系统（如 Snowflake）的集成，或支持业务消费。 + 将 TiDB 数据流式同步到消息队列是数据集成场景中的常见需求。你可以使用 Kafka sink 实现与其他数据处理系统（如 Snowflake）的集成，或支持业务消费。 - 更多信息请参考 [Changefeed 概览](/tidb-cloud/changefeed-overview.md)。 + 更多信息参见 [Changefeed 概览](/tidb-cloud/changefeed-overview.md)。 -- 组织所有者可以在 **Organization Settings** 中编辑组织名称。 +- 组织所有者可在 **Organization Settings** 中编辑组织名称。 **控制台变更** -- 优化 [TiDB Cloud 控制台](https://tidbcloud.com) 的导航布局，为用户提供全新的导航体验。 +- 优化 [TiDB Cloud 控制台](https://tidbcloud.com) 的导航布局，为用户带来全新的导航体验。 - 新布局包括以下变更： + 新布局包括以下变化： - 引入左侧导航栏，最大化屏幕使用效率。 - 采用更扁平的导航层级。 -- 改进 [**Connect**](/tidb-cloud/connect-to-tidb-cluster-serverless.md) 体验，方便 Serverless Tier 用户。 +- 改进 [**Connect**](/tidb-cloud/connect-to-tidb-cluster-serverless.md) 体验，提升 Serverless Tier 用户的连接便捷性。 现在开发者只需几步点击即可连接到 SQL 编辑器或自己喜欢的工具，无需切换上下文。 @@ -106,25 +106,25 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 **通用变更** -- 改进来自 AWS Marketplace 和 Google Cloud Marketplace 的用户体验。 +- 优化来自 AWS Marketplace 和 Google Cloud Marketplace 的用户体验。 - 无论你是 TiDB Cloud 新用户还是已有 TiDB Cloud 账号，现在都可以关联 AWS 或 GCP 计费账号，更方便地完成 AWS 或 GCP Marketplace 订阅。 + 无论你是 TiDB Cloud 新用户还是已有账号，现在都可以关联 AWS 或 GCP 计费账号，更便捷地完成 AWS 或 GCP Marketplace 订阅。 - 有关如何关联，请参见 [云服务商 Marketplace 计费](/tidb-cloud/tidb-cloud-billing.md#billing-from-cloud-provider-marketplace)。 + 关联方法参见 [云服务商 Marketplace 计费](/tidb-cloud/tidb-cloud-billing.md#billing-from-cloud-provider-marketplace)。 ## 2022 年 11 月 22 日 **通用变更** -* 支持将 Amazon Aurora MySQL、Amazon Relational Database Service (RDS) MySQL 或自建 MySQL 兼容数据库的数据直接在线迁移到 TiDB Cloud（Beta）。 +* 支持将 Amazon Aurora MySQL、Amazon RDS MySQL 或自建 MySQL 兼容数据库的数据直接在线迁移到 TiDB Cloud（Beta）。 - 之前，你需要暂停业务并离线导入数据，或使用第三方工具将数据迁移到 TiDB Cloud，过程较为复杂。现在，通过 **Data Migration** 功能，你只需在 TiDB Cloud 控制台上操作，即可安全地将数据以最小停机时间迁移到 TiDB Cloud。 + 之前，你需要暂停业务并离线导入数据，或使用第三方工具迁移数据到 TiDB Cloud，过程较为复杂。现在，通过 **Data Migration** 功能，你只需在 TiDB Cloud 控制台操作，即可安全地将数据以最小停机时间迁移到 TiDB Cloud。 - 此外，Data Migration 提供全量和增量数据迁移能力，可将源端的现有数据和持续变更同步迁移到 TiDB Cloud。 + 此外，Data Migration 提供全量和增量数据迁移能力，可将源端的现有数据和持续变更同步到 TiDB Cloud。 - 目前，Data Migration 功能仍处于 **Beta** 阶段，仅适用于 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群，且仅在 AWS Oregon (us-west-2) 和 AWS Singapore (ap-southeast-1) 区域开放。每个组织可免费创建一个迁移任务。如需为组织创建多个迁移任务，请 [提交工单](/tidb-cloud/tidb-cloud-support.md)。 + 目前，Data Migration 功能仍处于 **Beta** 阶段，仅支持 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群，且仅在 AWS Oregon (us-west-2) 和 AWS Singapore (ap-southeast-1) 区域开放。每个组织可免费创建一个迁移任务。如需为同一组织创建多个迁移任务，请 [提交工单](/tidb-cloud/tidb-cloud-support.md)。 - 详细信息参见 [使用 Data Migration 将 MySQL 兼容数据库迁移到 TiDB Cloud](/tidb-cloud/migrate-from-mysql-using-data-migration.md)。 + 详细信息参见 [使用 Data Migration 迁移 MySQL 兼容数据库到 TiDB Cloud](/tidb-cloud/migrate-from-mysql-using-data-migration.md)。 ## 2022 年 11 月 15 日 @@ -138,20 +138,20 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * 通过恢复到错误事件发生前的时间点，解决数据写入错误。 * 审计业务的历史数据。 - 要使用 PITR 功能，请确保你的 TiDB 集群版本至少为 v6.3.0，且 TiKV 节点规格至少为 8 vCPU 和 16 GiB。 + 要使用 PITR 功能，请确保 TiDB 集群版本至少为 v6.3.0，且 TiKV 节点规格至少为 8 vCPU 和 16 GiB。 - 默认情况下，备份数据存储在集群创建所在的同一区域。在日本，对于启用 PITR 的 GCP 托管 TiDB 集群，你可以选择将备份数据存储在一个或两个区域（东京和/或大阪）。从备用区域恢复数据可提供更高的数据安全性，并能容忍区域故障。 + 默认情况下，备份数据存储在集群创建所在的同一区域。在日本，对于启用 PITR 的 GCP 托管 TiDB 集群，你可以选择将备份数据存储在一个或两个区域（东京和/或大阪）。从备用区域恢复数据可提升数据安全性，并容忍区域故障。 详细信息参见 [备份与恢复 TiDB 集群数据](/tidb-cloud/backup-and-restore.md)。 - 该功能仍处于 Beta 阶段，仅可按需申请： + 该功能仍处于 Beta 阶段，仅可通过申请获得： * 点击 TiDB Cloud 控制台右下角的 **Help**。 - * 在弹窗中，在 **Description** 字段填写 "Apply for PITR"，然后点击 **Send**。 + * 在弹窗中，**Description** 字段填写 "Apply for PITR"，然后点击 **Send**。 * 数据库审计日志功能现已正式发布（GA）。 - 你可以使用数据库审计日志记录用户访问详情（如执行的所有 SQL 语句）历史，并定期分析数据库审计日志，有助于保障数据库安全。 + 你可以使用数据库审计日志记录用户访问详情（如执行的 SQL 语句）历史，并定期分析数据库审计日志，有助于保障数据库安全。 详细信息参见 [数据库审计日志](/tidb-cloud/tidb-cloud-auditing.md)。 @@ -159,23 +159,23 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 **通用变更** -* 改进用户反馈渠道。 +* 优化用户反馈渠道。 现在你可以在 TiDB Cloud 控制台的 **Support** > **Give Feedback** 中申请演示或积分。如果你想进一步了解 TiDB Cloud，这将非常有帮助。 - 收到你的请求后，我们会尽快与你联系并提供帮助。 + 我们收到你的请求后会尽快与你联系并提供帮助。 ## 2022 年 10 月 28 日 **通用变更** -* Developer Tier 升级为 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)。Serverless Tier 是 TiDB 的全托管、自动弹性部署方案，现已开放 Beta 并可免费使用。 +* Developer Tier 升级为 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)。Serverless Tier 是 TiDB 的全托管、自动弹性伸缩部署方案，现已开放 Beta 并可免费试用。 * Serverless Tier 集群依然具备与 Dedicated Tier 集群相同的 HTAP 能力。 * Serverless Tier 提供更快的集群创建时间和瞬时冷启动时间。与 Developer Tier 相比，创建时间从分钟级缩短到秒级。 * 你无需关心部署拓扑，Serverless Tier 会根据你的请求自动调整。 * Serverless Tier [强制要求集群使用 TLS 连接以保障安全](/tidb-cloud/secure-connections-to-serverless-clusters.md)。 - * 现有的 Developer Tier 集群将在未来几个月内自动迁移到 Serverless Tier。你的集群使用不会受到影响，且在 Beta 期间使用 Serverless Tier 集群不会产生费用。 + * 现有 Developer Tier 集群将在未来几个月内自动迁移到 Serverless Tier。你的集群使用不会受到影响，且在 Beta 期间使用 Serverless Tier 集群不会产生费用。 立即开始体验 [快速上手](/tidb-cloud/tidb-cloud-quickstart.md)。 @@ -197,9 +197,9 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 SET GLOBAL tidb_committer_concurrency = 127; ``` - 如果变量在 `GLOBAL` 级别设置，则该变量会应用于整个集群并持久化（即使重启或重载服务器后依然生效）。`SESSION` 级别的变量不持久化，仅在当前会话内生效。 + 如果变量在 `GLOBAL` 级别设置，则会应用于整个集群并持久化（即使重启或重载服务器后依然生效）。`SESSION` 级别的变量不持久化，仅在当前会话内生效。 - **该功能仍处于 Beta 阶段**，目前仅支持有限数量的变量。不建议修改其他 [系统变量](/system-variables.md)，以避免不可预期的副作用。基于 TiDB v6.1，支持的变量如下： + **该功能仍处于 Beta 阶段**，目前仅支持有限数量的变量。不建议修改其他 [系统变量](/system-variables.md)，以避免不可预知的副作用。基于 TiDB v6.1，支持的变量如下： - [`require_secure_transport`](/system-variables.md#require_secure_transport-new-in-v610) - [`tidb_committer_concurrency`](/system-variables.md#tidb_committer_concurrency-new-in-v610) @@ -219,42 +219,42 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * 在 [Vercel Integration Marketplace](https://vercel.com/integrations#databases) 发布 [TiDB Cloud Vercel Integration](https://vercel.com/integrations/tidb-cloud)。 - [Vercel](https://vercel.com) 是为前端开发者打造的平台，提供创新者所需的速度和可靠性，助力灵感瞬间实现。通过 TiDB Cloud Vercel Integration，你可以轻松将 Vercel 项目连接到 TiDB Cloud 集群。详情请参见文档 [将 TiDB Cloud 集成到 Vercel](/tidb-cloud/integrate-tidbcloud-with-vercel.md)。 + [Vercel](https://vercel.com) 是面向前端开发者的平台，提供创新者所需的速度与可靠性，助力灵感落地。通过 TiDB Cloud Vercel Integration，你可以轻松将 Vercel 项目连接到 TiDB Cloud 集群。详情参见文档 [集成 TiDB Cloud 与 Vercel](/tidb-cloud/integrate-tidbcloud-with-vercel.md)。 * 在 [Vercel 模板列表](https://vercel.com/templates) 发布 [TiDB Cloud Starter Template](https://vercel.com/templates/next.js/tidb-cloud-starter)。 - 你可以使用该模板作为起点，体验 Vercel 与 TiDB Cloud 的结合。在使用该模板前，你需要先 [将数据导入 TiDB Cloud 集群](https://github.com/pingcap/tidb-prisma-vercel-demo#2-import-table-structures-and-data)。 + 你可以使用该模板作为起点，体验 Vercel 与 TiDB Cloud。在使用模板前，请先 [导入数据到你的 TiDB Cloud 集群](https://github.com/pingcap/tidb-prisma-vercel-demo#2-import-table-structures-and-data)。 ## 2022 年 10 月 18 日 **通用变更** -* 对于 Dedicated Tier 集群，TiKV 或 TiFlash 节点的最小存储规格从 500 GiB 调整为 200 GiB。对于小数据量场景的用户，这将更具性价比。 +* 对于 Dedicated Tier 集群，TiKV 或 TiFlash 节点的最小存储规格由 500 GiB 调整为 200 GiB。对于小数据量场景的用户，这将更具性价比。 详情参见 [TiKV 节点存储](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size) 和 [TiFlash 节点存储](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)。 * 引入在线合同功能，以便自定义 TiDB Cloud 订阅并满足合规需求。 - 在 TiDB Cloud 控制台的 **Billing** 页面新增 [**Contract** 标签](/tidb-cloud/tidb-cloud-billing.md#contract)。如果你已与销售达成合同并收到在线处理合同的邮件，可以前往 **Contract** 标签页查看并接受合同。想了解更多合同信息，欢迎 [联系我们的销售](https://www.pingcap.com/contact-us/)。 + 在 TiDB Cloud 控制台的 **Billing** 页面新增 [**Contract** 标签](/tidb-cloud/tidb-cloud-billing.md#contract)。如果你已与销售达成合同并收到处理合同的邮件，可前往 **Contract** 标签页查看并接受合同。了解更多合同信息，欢迎 [联系我们](https://www.pingcap.com/contact-us/)。 **文档变更** -* 新增 [TiDB Cloud Terraform Provider 文档](/tidb-cloud/terraform-tidbcloud-provider-overview.md)。 +* 新增 [TiDB Cloud Terraform Provider](https://registry.terraform.io/providers/tidbcloud/tidbcloud) 的 [文档](/tidb-cloud/terraform-tidbcloud-provider-overview.md)。 - TiDB Cloud Terraform Provider 是一个插件，允许你使用 [Terraform](https://www.terraform.io/) 管理 TiDB Cloud 资源，如集群、备份和恢复。如果你希望以简单方式自动化资源配置和基础设施工作流，可以根据 [文档](/tidb-cloud/terraform-tidbcloud-provider-overview.md) 试用 TiDB Cloud Terraform Provider。 + TiDB Cloud Terraform Provider 是一个插件，允许你使用 [Terraform](https://www.terraform.io/) 管理 TiDB Cloud 资源，如集群、备份和恢复。如果你希望以简单方式自动化资源配置和基础设施工作流，可以参考 [文档](/tidb-cloud/terraform-tidbcloud-provider-overview.md) 试用该 Provider。 ## 2022 年 10 月 11 日 **通用变更** -* 将新建 [Developer Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的默认 TiDB 版本从 [v6.2.0](https://docs-archive.pingcap.com/tidb/v6.2/release-6.2.0) 升级到 [v6.3.0](https://docs-archive.pingcap.com/tidb/v6.3/release-6.3.0)。 +* 将新建 [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的默认 TiDB 版本从 [v6.2.0](https://docs-archive.pingcap.com/tidb/v6.2/release-6.2.0) 升级到 [v6.3.0](https://docs-archive.pingcap.com/tidb/v6.3/release-6.3.0)。 **控制台变更** -* 优化 [账单详情页](/tidb-cloud/tidb-cloud-billing.md#billing-details) 的计费信息： +* 优化 [账单明细页面](/tidb-cloud/tidb-cloud-billing.md#billing-details) 的计费信息： * 在 **Summary By Service** 部分提供更细粒度的节点级计费信息。 - * 新增 **Usage Details** 部分。你还可以将使用详情下载为 CSV 文件。 + * 新增 **Usage Details** 部分，并支持将使用明细下载为 CSV 文件。 ## 2022 年 9 月 27 日 @@ -262,13 +262,13 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * 支持通过邀请加入多个组织。 - 在 TiDB Cloud 控制台，你可以查看已加入的所有组织并在它们之间切换。详情参见 [在组织间切换](/tidb-cloud/manage-user-access.md#view-and-switch-between-organizations)。 + 在 TiDB Cloud 控制台，你可以查看已加入的所有组织并进行切换。详情参见 [组织间切换](/tidb-cloud/manage-user-access.md#view-and-switch-between-organizations)。 * 新增 [慢查询](/tidb-cloud/tune-performance.md#slow-query) 页面用于 SQL 诊断。 在慢查询页面，你可以搜索并查看 TiDB 集群中的所有慢查询，并通过查看其 [执行计划](https://docs.pingcap.com/tidbcloud/explain-overview)、SQL 执行信息等细节，分析每条慢查询的瓶颈。 -* 当你重置账号密码时，TiDB Cloud 会将新密码与你最近 4 次使用的密码进行比对，并提醒你避免使用这些密码。最近 4 次使用过的密码均不可再次使用。 +* 当你重置账号密码时，TiDB Cloud 会校验新密码是否与最近 4 次使用过的密码重复，并提醒你避免使用这些密码。最近 4 次使用过的密码均不可再次使用。 详情参见 [密码认证](/tidb-cloud/tidb-cloud-password-authentication.md)。 @@ -284,7 +284,7 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 **控制台变更** -* 提供全新 Web UI 用于数据导入。新 UI 提供更好的用户体验，使数据导入更高效。 +* 提供全新 Web UI 用于数据导入。新 UI 提升了用户体验，使数据导入更高效。 使用新 UI，你可以预览待导入数据、查看导入进度，并轻松管理所有导入任务。 @@ -292,7 +292,7 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * TiDB Cloud API（Beta）现已对所有用户开放。 - 你可以在 TiDB Cloud 控制台创建 API Key 后开始使用 API。更多信息请参考 [API 文档](/tidb-cloud/api-overview.md)。 + 你可以在 TiDB Cloud 控制台创建 API Key 后开始使用 API。更多信息参见 [API 文档](/tidb-cloud/api-overview.md)。 ## 2022 年 9 月 15 日 @@ -310,7 +310,7 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 新设计中，升级到 Dedicated Tier、集群连接和数据导入的入口更加突出。 -* 为 [Developer Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群引入 Playground。 +* 为 [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群引入 Playground。 Playground 预置了 GitHub events 数据集，让你无需导入数据或连接客户端，即可通过查询快速体验 TiDB Cloud。 @@ -336,13 +336,13 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 **控制台变更** -* 现在你可以通过 TiDB Cloud 控制台右上角的入口 [申请 PoC](/tidb-cloud/tidb-cloud-poc.md)。 +* 现在你可以通过 TiDB Cloud 控制台右上角入口 [申请 PoC](/tidb-cloud/tidb-cloud-poc.md)。 **API 变更** -* 支持通过 [TiDB Cloud API](/tidb-cloud/api-overview.md) 增加 TiKV 或 TiFlash 节点的存储。你可以通过 API 接口的 `storage_size_gib` 字段进行扩容。 +* 支持通过 [TiDB Cloud API](/tidb-cloud/api-overview.md) 扩容 TiKV 或 TiFlash 节点的存储。你可以通过 API 接口的 `storage_size_gib` 字段进行扩容。 - 目前，TiDB Cloud API 仍处于 Beta 阶段，仅可按需申请。 + 目前，TiDB Cloud API 仍处于 Beta 阶段，仅可通过申请获得。 详情参见 [修改 Dedicated Tier 集群](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)。 @@ -352,13 +352,13 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * 支持基于 AWS PrivateLink 的 endpoint 连接，作为 TiDB Cloud [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的新网络访问管理选项。 - endpoint 连接安全且私有，不会将你的数据暴露在公网。此外，endpoint 连接支持 CIDR 重叠，便于网络管理。 + endpoint 连接安全私密，不会将数据暴露在公网。此外，endpoint 连接支持 CIDR 重叠，便于网络管理。 详细信息参见 [设置 Private Endpoint 连接](/tidb-cloud/set-up-private-endpoint-connections.md)。 **控制台变更** -* 在 [Connect](/tidb-cloud/connect-to-tidb-cluster.md) 对话框的 **VPC Peering** 和 **Private Endpoint** 标签页中，为 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群提供 MySQL、MyCLI、JDBC、Python、Go、Node.js 的示例连接字符串。 +* 在 [Connect](/tidb-cloud/connect-to-tidb-cluster.md) 对话框的 **VPC Peering** 和 **Private Endpoint** 标签页，为 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群提供 MySQL、MyCLI、JDBC、Python、Go、Node.js 的示例连接字符串。 你只需复制粘贴连接代码到应用中，即可轻松连接 Dedicated Tier 集群。 @@ -368,13 +368,13 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * 支持暂停或恢复 Dedicated Tier 集群。 - 你可以在 TiDB Cloud [暂停或恢复 Dedicated Tier 集群](/tidb-cloud/pause-or-resume-tidb-cluster.md)。当集群处于暂停状态时，不会收取 Node Compute Cost。 + 你可以在 TiDB Cloud [暂停或恢复 Dedicated Tier 集群](/tidb-cloud/pause-or-resume-tidb-cluster.md)。当集群处于暂停状态时，不会产生 Node Compute Cost。 ## 2022 年 8 月 23 日 **通用变更** -* 将新建 [Developer Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的默认 TiDB 版本从 [v6.1.0](https://docs.pingcap.com/tidb/stable/release-6.1.0) 升级到 [v6.2.0](https://docs-archive.pingcap.com/tidb/v6.2/release-6.2.0)。 +* 将新建 [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的默认 TiDB 版本从 [v6.1.0](https://docs.pingcap.com/tidb/stable/release-6.1.0) 升级到 [v6.2.0](https://docs-archive.pingcap.com/tidb/v6.2/release-6.2.0)。 **API 变更** @@ -382,14 +382,14 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 通过该 API，你可以自动高效地管理 TiDB Cloud 资源（如集群）。更多信息参见 [TiDB Cloud API 文档](https://docs.pingcap.com/tidbcloud/api/v1beta)。 - 目前，TiDB Cloud API 仍处于 Beta 阶段，仅可按需申请。你可以通过提交请求申请 API 访问权限： + 目前，TiDB Cloud API 仍处于 Beta 阶段，仅可通过申请获得。你可以通过提交请求申请 API 访问权限： * 点击 [TiDB Cloud 控制台](https://tidbcloud.com/project/clusters) 右下角的 **Help**。 * 在弹窗的 **Description** 字段填写 "Apply for TiDB Cloud API"，然后点击 **Send**。 ## 2022 年 8 月 16 日 -* 新增 TiDB 和 TiKV 的 `2 vCPU, 8 GiB (Beta)` 节点规格（Beta）。 +* 新增 TiDB 和 TiKV 的 `2 vCPU, 8 GiB (Beta)` 节点规格。 * 每个 `2 vCPU, 8 GiB (Beta)` TiKV 节点的存储规格为 200 GiB 到 500 GiB。 @@ -399,17 +399,17 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * PoC 和预发布环境 * 开发环境 -* 为 PoC 用户引入 [Credits](/tidb-cloud/tidb-cloud-billing.md#credits)（原名 trail points）。 +* 为 PoC 用户引入 [Credits](/tidb-cloud/tidb-cloud-billing.md#credits)（原 trail points）。 - 你现在可以在 **Billing** 页的 **Credits** 标签下查看组织的积分信息，积分可用于支付 TiDB Cloud 费用。你可以 联系我们 获取积分。 + 你现在可以在 **Billing** 页的 **Credits** 标签页查看组织的积分信息，积分可用于支付 TiDB Cloud 费用。你可以 联系我们 获取积分。 ## 2022 年 8 月 9 日 -* 新增 GCP 区域 `Osaka`，支持 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建。 +* 为 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建新增 GCP 区域 `Osaka` 支持。 ## 2022 年 8 月 2 日 -* TiDB 和 TiKV 的 `4 vCPU, 16 GiB` 节点规格现已正式发布（GA）。 +* `4 vCPU, 16 GiB` 规格的 TiDB 和 TiKV 节点现已正式发布（GA）。 * 每个 `4 vCPU, 16 GiB` TiKV 节点的存储规格为 200 GiB 到 2 TiB。 * 建议使用场景： @@ -418,13 +418,13 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * PoC 和预发布环境 * 开发环境 -* 在 [Dedicated Tier 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)的 **Diagnosis** 标签下新增 [监控页面](/tidb-cloud/built-in-monitoring.md)。 +* 在 [Dedicated Tier 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)的 **Diagnosis** 标签页新增 [监控页面](/tidb-cloud/built-in-monitoring.md)。 - 监控页面为整体性能诊断提供系统级入口。根据自顶向下的性能分析方法，监控页面按数据库时间分解组织 TiDB 性能指标，并以不同颜色展示。通过查看颜色，你可以一眼识别系统整体的性能瓶颈，大大缩短性能诊断时间，简化分析流程。 + 监控页面为整体性能诊断提供系统级入口。根据自顶向下的性能分析方法，监控页面按数据库时间分解组织 TiDB 性能指标，并以不同颜色展示。通过颜色区分，你可以一眼识别系统整体的性能瓶颈，大幅缩短性能诊断时间，简化分析流程。 -* 在 **Data Import** 页为 CSV 和 Parquet 源文件新增开关，用于启用或禁用 **Custom Pattern**。 +* 在 **Data Import** 页为 CSV 和 Parquet 源文件新增启用/禁用 **Custom Pattern** 的开关。 - **Custom Pattern** 功能默认关闭。当你需要将文件名符合某一模式的 CSV 或 Parquet 文件导入到同一目标表时，可以启用该功能。 + **Custom Pattern** 功能默认关闭。当你需要将文件名符合某一模式的 CSV 或 Parquet 文件导入到同一目标表时，可手动开启。 详细信息参见 [导入 CSV 文件](/tidb-cloud/import-csv-files.md) 和 [导入 Apache Parquet 文件](/tidb-cloud/import-parquet-files.md)。 @@ -437,23 +437,23 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 ## 2022 年 7 月 28 日 -* 在 **Security Quick Start** 对话框中新增 **Allow Access from Anywhere** 按钮，允许你的集群被任意 IP 地址访问。详情参见 [配置集群安全设置](/tidb-cloud/configure-security-settings.md)。 +* 在 **Security Quick Start** 对话框新增 **Allow Access from Anywhere** 按钮，允许你的集群被任意 IP 地址访问。详细信息参见 [配置集群安全设置](/tidb-cloud/configure-security-settings.md)。 ## 2022 年 7 月 26 日 -* 支持新建 [Developer Tier 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的自动休眠与自动唤醒。 +* 支持新建 [Developer Tier 集群](/tidb-cloud/select-cluster-tier.md#starter) 的自动休眠与恢复。 - Developer Tier 集群在 7 天无操作后不会被删除，你可以在一年免费试用期内随时使用。若 24 小时无操作，Developer Tier 集群会自动休眠。要唤醒集群，只需重新连接或在 TiDB Cloud 控制台点击 **Resume** 按钮。集群将在 50 秒内自动恢复服务。 + Developer Tier 集群在 7 天无活动后不会被删除，你可以在一年免费试用期内随时使用。若 24 小时无活动，集群将自动休眠。要恢复集群，可向集群发起新连接或在 TiDB Cloud 控制台点击 **Resume** 按钮。集群将在 50 秒内自动恢复并重新提供服务。 -* 新建 [Developer Tier 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 增加用户名前缀限制。 +* 为新建 [Developer Tier 集群](/tidb-cloud/select-cluster-tier.md#starter) 增加用户名前缀限制。 - 每当你使用或设置数据库用户名时，必须在用户名中包含集群的前缀。详情参见 [用户名前缀](/tidb-cloud/select-cluster-tier.md#user-name-prefix)。 + 每当你使用或设置数据库用户名时，必须在用户名中包含集群前缀。详细信息参见 [用户名前缀](/tidb-cloud/select-cluster-tier.md#user-name-prefix)。 -* 禁用 [Developer Tier 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的备份与恢复功能。 +* 禁用 [Developer Tier 集群](/tidb-cloud/select-cluster-tier.md#starter) 的备份与恢复功能。 - Developer Tier 集群的备份与恢复功能（包括自动和手动备份）已被禁用。你仍可使用 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview) 导出数据作为备份。 + Developer Tier 集群不支持自动或手动备份与恢复功能。你仍可使用 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview) 导出数据作为备份。 -* 将 [Developer Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的存储规格从 500 MiB 提升至 1 GiB。 +* 将 [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的存储规格从 500 MiB 提升至 1 GiB。 * 在 TiDB Cloud 控制台新增面包屑导航，提升导航体验。 * 支持在导入数据到 TiDB Cloud 时配置多条过滤规则。 * 从 **Project Settings** 移除 **Traffic Filters** 页面，并从 **Connect to TiDB** 对话框移除 **Add Rules from Default Set** 按钮。 @@ -462,19 +462,19 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 * 为 [TiKV 节点规格](/tidb-cloud/size-your-cluster.md#tikv-vcpu-and-ram)新增 `8 vCPU, 32 GiB` 选项。你可以为 8 vCPU TiKV 节点选择 `8 vCPU, 32 GiB` 或 `8 vCPU, 64 GiB`。 * 在 [**Connect to TiDB**](/tidb-cloud/connect-via-standard-connection.md) 对话框的示例代码中支持语法高亮，提升代码可读性。你可以更容易地识别需要替换的参数。 -* 在 [**Data Import Task**](/tidb-cloud/import-sample-data.md) 页面确认导入任务后，支持自动校验 TiDB Cloud 是否能访问你的源数据。 -* 更改 TiDB Cloud 控制台的主题色，使其与 [PingCAP 官网](https://www.pingcap.com/) 保持一致。 +* 在 [**Data Import Task**](/tidb-cloud/import-sample-data.md) 页面，支持自动校验 TiDB Cloud 是否能访问你的源数据。 +* 调整 TiDB Cloud 控制台主题色，使其与 [PingCAP 官网](https://www.pingcap.com/) 保持一致。 ## 2022 年 7 月 12 日 -* 在 [**Data Import Task**](/tidb-cloud/import-sample-data.md) 页为 Amazon S3 新增 **Validate** 按钮，帮助你在数据导入前检测数据访问问题。 -* 在 [**Payment Method**](/tidb-cloud/tidb-cloud-billing.md#payment-method) 标签下新增 **Billing Profile**。在 **Billing Profile** 中填写税号后，部分税费可能会从账单中免除。详情参见 [编辑账单信息](/tidb-cloud/tidb-cloud-billing.md#billing-profile)。 +* 在 [**Data Import Task**](/tidb-cloud/import-sample-data.md) 页面为 Amazon S3 新增 **Validate** 按钮，帮助你在数据导入前检测数据访问问题。 +* 在 [**Payment Method**](/tidb-cloud/tidb-cloud-billing.md#payment-method) 标签下新增 **Billing Profile**。在 **Billing Profile** 中填写税务登记号后，部分税费可能会从发票中免除。详细信息参见 [编辑账单资料信息](/tidb-cloud/tidb-cloud-billing.md#billing-profile)。 ## 2022 年 7 月 5 日 * 列式存储 [TiFlash](/tiflash/tiflash-overview.md) 现已正式发布（GA）。 - - TiFlash 让 TiDB 成为真正的 HTAP（混合事务/分析处理）数据库。你的应用数据首先存储在 TiKV，然后通过 Raft 共识算法实时同步到 TiFlash，因此是行存到列存的实时复制。 + - TiFlash 让 TiDB 成为真正的 HTAP（混合事务/分析处理）数据库。你的应用数据首先存储在 TiKV，然后通过 Raft 共识算法实时同步到 TiFlash，实现行存到列存的实时复制。 - 对于有 TiFlash 副本的表，TiDB 优化器会根据代价估算自动选择使用 TiKV 还是 TiFlash 副本。 体验 TiFlash 带来的优势，请参见 [TiDB Cloud HTAP 快速上手指南](/tidb-cloud/tidb-cloud-htap-quickstart.md)。 @@ -488,37 +488,37 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 ## 2022 年 6 月 23 日 -* 提升 TiDB Cloud 上 [TiKV 存储容量](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)上限。 +* 提升 TiDB Cloud 上 [TiKV 存储容量](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size) 上限。 * 8 vCPU 或 16 vCPU TiKV：支持最大 4 TiB 存储容量。 * 4 vCPU TiKV：支持最大 2 TiB 存储容量。 ## 2022 年 6 月 21 日 -* 新增 GCP 区域 `Taiwan`，支持 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建。 -* 支持在 TiDB Cloud 控制台 [更新用户信息](/tidb-cloud/manage-user-access.md#manage-user-profiles)，包括名、姓、公司名、国家和手机号。 -* 在 [**Connect to TiDB**](/tidb-cloud/connect-via-standard-connection.md) 对话框中提供 MySQL、MyCLI、JDBC、Python、Go、Node.js 的连接字符串，方便你快速连接 TiDB 集群。 -* 在数据导入时自动从 bucket URI 获取 bucket 区域，无需手动填写。 +* 为 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建新增 GCP 区域 `Taiwan` 支持。 +* 支持在 TiDB Cloud 控制台 [更新用户资料](/tidb-cloud/manage-user-access.md#manage-user-profiles)，包括名、姓、公司名、国家和手机号。 +* 在 [**Connect to TiDB**](/tidb-cloud/connect-via-standard-connection.md) 对话框中提供 MySQL、MyCLI、JDBC、Python、Go、Node.js 的连接字符串，便于你快速连接 TiDB 集群。 +* 数据导入时自动从存储桶 URI 获取桶所在区域，无需手动填写。 ## 2022 年 6 月 16 日 * 简化 [集群创建流程](/tidb-cloud/create-tidb-cluster.md)。 - - 创建集群时，TiDB Cloud 会提供默认集群名，你可以直接使用或修改。 + - 创建集群时，TiDB Cloud 会提供默认集群名，你可以直接使用或自定义。 - 创建集群时，无需在 **Create a Cluster** 页面设置密码。 - - 在集群创建过程中或创建后，你可以在 **Security Quick Start** 对话框设置 root 密码和连接集群的 IP 地址。 + - 创建过程中或创建后，你可以在 **Security Quick Start** 对话框设置 root 密码和连接集群的 IP 地址。 ## 2022 年 6 月 14 日 * 将 Developer Tier 升级到 [TiDB v6.1.0](https://docs.pingcap.com/tidb/stable/release-6.1.0)。 -* 优化 **Project Settings** 入口。在 TiDB Cloud 控制台中，你可以选择目标项目并通过点击 **Project Settings** 标签轻松进入设置页面。 +* 优化 **Project Settings** 入口。在 TiDB Cloud 控制台中，你可以选择目标项目并通过 **Project Settings** 标签页轻松进入设置。 * 优化密码过期体验，在 TiDB Cloud 控制台中提供过期提示信息。 ## 2022 年 6 月 7 日 -* 新增 [免费试用](https://tidbcloud.com/free-trial) 注册页面，快速注册 TiDB Cloud。 -* 从套餐选择页面移除 **Proof of Concept plan** 选项。如需申请 14 天免费 PoC 试用，请 联系我们。详情参见 [使用 TiDB Cloud 进行 PoC](/tidb-cloud/tidb-cloud-poc.md)。 -* 通过要求使用邮箱和密码注册 TiDB Cloud 的用户每 90 天重置一次密码，提升系统安全性。详情参见 [密码认证](/tidb-cloud/tidb-cloud-password-authentication.md)。 +* 新增 [免费试用](https://tidbcloud.com/free-trial) 注册页面，便于快速注册 TiDB Cloud。 +* 从套餐选择页面移除 **Proof of Concept plan** 选项。如需申请 14 天免费 PoC 试用，请 联系我们。详细信息参见 [使用 TiDB Cloud 进行 PoC](/tidb-cloud/tidb-cloud-poc.md)。 +* 提升系统安全性，要求使用邮箱和密码注册 TiDB Cloud 的用户每 90 天重置一次密码。详细信息参见 [密码认证](/tidb-cloud/tidb-cloud-password-authentication.md)。 ## 2022 年 5 月 24 日 @@ -526,7 +526,7 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 ## 2022 年 5 月 19 日 -* 新增 AWS 区域 `Frankfurt`，支持 [Developer Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群创建。 +* 为 [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群创建新增 AWS 区域 `Frankfurt` 支持。 ## 2022 年 5 月 18 日 @@ -539,7 +539,7 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 ## 2022 年 5 月 1 日 * 支持在 [创建](/tidb-cloud/create-tidb-cluster.md) 或 [恢复](/tidb-cloud/backup-and-restore.md#restore) [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群时配置 TiDB、TiKV、TiFlash 的 vCPU 规格。 -* 新增 AWS 区域 `Mumbai`，支持集群创建。 +* 新增 AWS 区域 `Mumbai` 支持集群创建。 * 更新 [TiDB Cloud 计费](/tidb-cloud/tidb-cloud-billing.md) 的计算、存储和数据传输费用。 ## 2022 年 4 月 7 日 @@ -548,9 +548,9 @@ summary: 了解 TiDB Cloud 在 2022 年的发布说明。 ## 2022 年 3 月 31 日 -TiDB Cloud 现已正式发布。你可以 [注册](https://tidbcloud.com/signup) 并选择以下任一选项： +TiDB Cloud 现已正式发布。你可以 [注册](https://tidbcloud.com/signup) 并选择以下方式之一： -* 免费体验 [Developer Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)。 +* 免费体验 [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)。 * 联系我们 申请 14 天免费 PoC 试用。 * 通过 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 获得完整访问权限。 @@ -566,19 +566,19 @@ TiDB Cloud 现已正式发布。你可以 [注册](https://tidbcloud.com/signup) 通用变更： -* 不再有固定集群规格的集群类型。你可以轻松自定义 TiDB、TiKV、TiFlash 的 [集群规格](/tidb-cloud/size-your-cluster.md)。 +* 不再有固定集群规格的集群类型。你可以灵活自定义 TiDB、TiKV、TiFlash 的 [集群规格](/tidb-cloud/size-your-cluster.md)。 * 支持为已有无 TiFlash 的集群添加 [TiFlash](/tiflash/tiflash-overview.md) 节点。 -* 支持在 [创建新集群](/tidb-cloud/create-tidb-cluster.md) 时指定存储规格（500 到 2048 GiB）。集群创建后存储规格不可更改。 +* 支持在 [新建集群](/tidb-cloud/create-tidb-cluster.md) 时指定存储规格（500 到 2048 GiB）。集群创建后存储规格不可更改。 * 新增公共区域：`eu-central-1`。 * 废弃 8 vCPU TiFlash，提供 16 vCPU TiFlash。 -* 分别计价 CPU 和存储（均有 30% 公测折扣）。 +* CPU 和存储价格分离（均享 30% 公测折扣）。 * 更新 [计费信息](/tidb-cloud/tidb-cloud-billing.md) 和 [价格表](https://www.pingcap.com/pricing/)。 新功能： -* 支持 [Prometheus 和 Grafana 集成](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)。 +* 支持 [Prometheus 与 Grafana 集成](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)。 - 通过 Prometheus 和 Grafana 集成，你可以配置 [Prometheus](https://prometheus.io/) 服务从 TiDB Cloud endpoint 读取关键指标，并使用 [Grafana](https://grafana.com/) 查看这些指标。 + 通过 Prometheus 与 Grafana 集成，你可以配置 [Prometheus](https://prometheus.io/) 服务从 TiDB Cloud endpoint 读取关键指标，并使用 [Grafana](https://grafana.com/) 查看这些指标。 * 支持根据新集群所选区域分配默认备份时间。 @@ -590,7 +590,7 @@ TiDB Cloud 现已正式发布。你可以 [注册](https://tidbcloud.com/signup) * 支持 [Datadog 集成](/tidb-cloud/monitor-datadog-integration.md)。 - 通过 Datadog 集成，你可以配置 TiDB Cloud 向 [Datadog](https://www.datadoghq.com/) 发送集群的指标数据。之后，你可以直接在 Datadog dashboard 查看这些指标。 + 通过 Datadog 集成，你可以配置 TiDB Cloud 向 [Datadog](https://www.datadoghq.com/) 发送集群的监控数据。之后，你可以直接在 Datadog dashboard 查看这些指标。 ## 2022 年 2 月 15 日 @@ -614,5 +614,5 @@ TiDB Cloud 现已正式发布。你可以 [注册](https://tidbcloud.com/signup) Bug 修复： -* 修复了当密码包含单引号时用户无法创建集群的问题。 +* 修复了当密码包含单引号时无法创建集群的问题。 * 修复了即使组织只有一位 owner，该 owner 也可以被删除或更改为其他角色的问题。 \ No newline at end of file diff --git a/tidb-cloud/release-notes-2023.md b/tidb-cloud/release-notes-2023.md index ac25a62023798..0af58f8d2beab 100644 --- a/tidb-cloud/release-notes-2023.md +++ b/tidb-cloud/release-notes-2023.md @@ -11,13 +11,13 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持恢复失败的 changefeed，无需重新创建，节省你的操作成本。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持恢复失败的 changefeed，无需重新创建，节省操作成本。 详细信息参见 [Changefeed 状态](/tidb-cloud/changefeed-overview.md#changefeed-states)。 **控制台变更** -- 优化 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的连接体验。 +- 优化 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 的连接体验。 优化 **Connect** 对话框界面，为 TiDB Cloud Serverless 用户提供更流畅、高效的连接体验。此外，TiDB Cloud Serverless 新增了更多客户端类型，并允许你选择所需分支进行连接。 @@ -27,19 +27,19 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持从备份中恢复 SQL 绑定。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持从备份中恢复 SQL 绑定。 - 现在，TiDB Cloud Dedicated 集群在从备份恢复时，默认会恢复用户账户和 SQL 绑定。该增强适用于 v6.2.0 及以上版本的集群，简化了数据恢复流程。SQL 绑定的恢复确保了查询相关配置和优化的顺利回归，为你提供更全面、高效的恢复体验。 + 现在，TiDB Cloud Dedicated 在从备份恢复时默认恢复用户账号和 SQL 绑定。该增强适用于 v6.2.0 及以上版本的集群，简化了数据恢复流程。SQL 绑定的恢复确保查询相关配置和优化的顺利回归，为你提供更全面、高效的恢复体验。 - 详细信息参见 [备份与恢复 TiDB Cloud Dedicated 集群数据](/tidb-cloud/backup-and-restore.md)。 + 详细信息参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md)。 **控制台变更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 支持监控 SQL 语句的 RU 消耗。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 支持监控 SQL 语句的 RU 消耗。 现在，TiDB Cloud Serverless 提供每条 SQL 语句的 [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 详细信息。你可以查看每条 SQL 语句的 **Total RU** 和 **Mean RU** 消耗。该功能有助于你识别和分析 RU 消耗，为运营成本优化提供参考。 - 要查看 SQL 语句 RU 详情，请进入 [你的 TiDB Cloud Serverless 集群](https://tidbcloud.com/project/clusters) 的 **Diagnosis** 页面，并点击 **SQL Statement** 标签页。 + 查看 SQL 语句 RU 详情，请前往 [你的 TiDB Cloud Serverless 集群](https://tidbcloud.com/project/clusters)的 **Diagnosis** 页面，并点击 **SQL Statement** 标签。 ## 2023 年 11 月 21 日 @@ -47,7 +47,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - [数据迁移](/tidb-cloud/migrate-from-mysql-using-data-migration.md) 支持 Google Cloud 上部署的 TiDB 集群的高速物理模式。 - 现在，你可以在 AWS 和 Google Cloud 上部署的 TiDB 集群使用物理模式。物理模式的迁移速度可达 110 MiB/s，是逻辑模式的 2.4 倍。该性能提升适用于大规模数据集的快速迁移至 TiDB Cloud。 + 现在，你可以在 AWS 和 Google Cloud 上部署的 TiDB 集群使用物理模式。物理模式的迁移速度可达 110 MiB/s，是逻辑模式的 2.4 倍。该性能提升适合将大规模数据集快速迁移到 TiDB Cloud。 详细信息参见 [迁移现有数据和增量数据](/tidb-cloud/migrate-from-mysql-using-data-migration.md#migrate-existing-data-and-incremental-data)。 @@ -55,13 +55,13 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 从 TiDB Cloud Dedicated 集群恢复数据时，默认行为已由不恢复用户账户改为恢复所有用户账户。 +- 从 TiDB Cloud Dedicated 集群恢复数据时，默认行为由不恢复用户账号改为恢复所有用户账号。 - 详细信息参见 [备份与恢复 TiDB Cloud Dedicated 集群数据](/tidb-cloud/backup-and-restore.md)。 + 详细信息参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md)。 -- 引入 changefeed 事件过滤器。 +- 为 changefeed 引入事件过滤器。 - 该增强支持你直接在 [TiDB Cloud 控制台](https://tidbcloud.com/) 管理 changefeed 的事件过滤器，简化了排除特定事件的流程，并为下游数据同步提供更好的控制能力。 + 该增强支持你直接通过 [TiDB Cloud 控制台](https://tidbcloud.com/) 管理 changefeed 的事件过滤器，简化了排除特定事件的流程，并为下游数据同步提供更好的控制。 详细信息参见 [Changefeed](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)。 @@ -82,7 +82,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 支持在 TiDB Cloud 控制台直接升级为企业支持计划，无需联系销售。 +- 支持在 TiDB Cloud 控制台直接升级到 Enterprise 支持计划，无需联系销售。 详细信息参见 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 @@ -90,15 +90,15 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持 Google Cloud 上的双区域备份（Beta）。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持 Google Cloud 上的双区域备份（beta）。 - 部署在 Google Cloud 上的 TiDB Cloud Dedicated 集群可无缝对接 Google Cloud Storage。与 Google Cloud Storage 的 [Dual-regions](https://cloud.google.com/storage/docs/locations#location-dr) 功能类似，TiDB Cloud Dedicated 集群的双区域需选择同一多区域下的两个区域。例如，东京和大阪同属 `ASIA` 多区域，可共同用于双区域存储。 + 托管于 Google Cloud 的 TiDB Cloud Dedicated 集群可无缝对接 Google Cloud Storage。类似于 Google Cloud Storage 的 [Dual-regions](https://cloud.google.com/storage/docs/locations#location-dr) 功能，TiDB Cloud Dedicated 的双区域需选择同一多区域下的两个区域。例如，东京和大阪同属 `ASIA` 多区域，可共同用于双区域存储。 详细信息参见 [开启双区域备份](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)。 - [将数据变更日志流式写入 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md) 功能现已正式发布（GA）。 - 经过 10 个月的 Beta 试用，TiDB Cloud 到 Apache Kafka 的数据变更日志流式写入功能正式可用。在数据集成场景中，将 TiDB 数据流式写入消息队列是常见需求。你可以通过 Kafka sink 集成其他数据处理系统（如 Snowflake）或支持业务消费。 + 经过 10 个月的 beta 试用，该功能现已正式可用。将 TiDB Cloud 的数据变更日志流式写入 Apache Kafka 是数据集成场景中的常见需求。你可以通过 Kafka sink 集成其他数据处理系统（如 Snowflake）或支持业务消费。 详细信息参见 [Changefeed 概览](/tidb-cloud/changefeed-overview.md)。 @@ -106,15 +106,15 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 支持 [AWS 上部署的 TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 [双区域备份（Beta）](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)。 +- 支持 [AWS 上部署的 TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 [双区域备份（beta）](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)。 你现在可以在云服务商的不同地理区域间复制备份。该功能为数据保护和灾难恢复提供了额外保障。 - 详细信息参见 [备份与恢复 TiDB Cloud Dedicated 集群数据](/tidb-cloud/backup-and-restore.md)。 + 详细信息参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md)。 - 数据迁移现已支持物理模式和逻辑模式迁移现有数据。 - 物理模式下，迁移速度可达 110 MiB/s。相比逻辑模式的 45 MiB/s，迁移性能大幅提升。 + 在物理模式下，迁移速度可达 110 MiB/s。相比逻辑模式的 45 MiB/s，迁移性能大幅提升。 详细信息参见 [迁移现有数据和增量数据](/tidb-cloud/migrate-from-mysql-using-data-migration.md#migrate-existing-data-and-incremental-data)。 @@ -130,7 +130,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **API 变更** -- 新增 TiDB Cloud 账单 API 接口，可获取指定组织某月账单。 +- 新增 TiDB Cloud 账单 API 接口，可获取指定组织某月的账单。 该账单 API 接口已在 TiDB Cloud API v1beta1（最新版本）中发布。详细信息参见 [API 文档 (v1beta1)](https://docs.pingcap.com/tidbcloud/api/v1beta1#tag/Billing)。 @@ -138,39 +138,39 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 移除 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 2 vCPU TiDB 和 TiKV 节点选项。 +- 移除 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中的 2 vCPU TiDB 和 TiKV 节点选项。 2 vCPU 选项已不再出现在 **Create Cluster** 或 **Modify Cluster** 页面。 -- 发布 [TiDB Cloud serverless driver (beta)](/tidb-cloud/serverless-driver.md) for JavaScript。 +- 发布 [JavaScript 版 TiDB Cloud serverless driver（beta）](/tidb-cloud/serverless-driver.md)。 - TiDB Cloud serverless driver for JavaScript 支持通过 HTTPS 连接 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群。该驱动特别适用于 TCP 连接受限的边缘环境，如 [Vercel Edge Function](https://vercel.com/docs/functions/edge-functions) 和 [Cloudflare Workers](https://workers.cloudflare.com/)。 + JavaScript 版 TiDB Cloud serverless driver 支持通过 HTTPS 连接 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群。该驱动特别适用于 TCP 连接受限的边缘环境，如 [Vercel Edge Function](https://vercel.com/docs/functions/edge-functions) 和 [Cloudflare Workers](https://workers.cloudflare.com/)。 - 详细信息参见 [TiDB Cloud serverless driver (beta)](/tidb-cloud/serverless-driver.md)。 + 详细信息参见 [TiDB Cloud serverless driver（beta）](/tidb-cloud/serverless-driver.md)。 **控制台变更** -- 对于 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群，你可以在 **Usage This Month** 面板或设置消费上限时获取费用预估。 +- 对于 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群，你可以在 **Usage This Month** 面板或设置消费上限时获取费用预估。 ## 2023 年 9 月 5 日 **通用变更** -- [数据服务（Beta）](https://tidbcloud.com/project/data-service) 支持为每个 API key 自定义限流，以满足不同场景下的限流需求。 +- [数据服务（beta）](https://tidbcloud.com/project/data-service) 支持为每个 API key 自定义限流，以满足不同场景下的限流需求。 你可以在 [创建](/tidb-cloud/data-service-api-key.md#create-an-api-key) 或 [编辑](/tidb-cloud/data-service-api-key.md#edit-an-api-key) API key 时调整限流。 详细信息参见 [限流](/tidb-cloud/data-service-api-key.md#rate-limiting)。 -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 新增支持 AWS 区域：圣保罗（sa-east-1）。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持新增 AWS 区域：圣保罗（sa-east-1）。 -- 每个 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 IP 访问列表支持最多添加 100 个 IP 地址。 +- 每个 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 IP 访问列表支持最多添加 100 个 IP 地址。 详细信息参见 [配置 IP 访问列表](/tidb-cloud/configure-ip-access-list.md)。 **控制台变更** -- 为 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群引入 **Events** 页面，记录集群主要变更。 +- 为 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群引入 **Events** 页面，记录集群的主要变更。 你可以在该页面查看最近 7 天的事件历史，并追踪触发时间、操作用户等重要信息。 @@ -178,7 +178,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **API 变更** -- 发布多项 TiDB Cloud API 接口，用于管理 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 [AWS PrivateLink](https://aws.amazon.com/privatelink/?privatelink-blogs.sort-by=item.additionalFields.createdDate&privatelink-blogs.sort-order=desc) 或 [Google Cloud Private Service Connect](https://cloud.google.com/vpc/docs/private-service-connect)： +- 发布多项 TiDB Cloud API 接口，用于管理 [AWS PrivateLink](https://aws.amazon.com/privatelink/?privatelink-blogs.sort-by=item.additionalFields.createdDate&privatelink-blogs.sort-order=desc) 或 [Google Cloud Private Service Connect](https://cloud.google.com/vpc/docs/private-service-connect) 相关的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群： - 为集群创建私有端点服务 - 获取集群的私有端点服务信息 @@ -193,9 +193,9 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持 Google Cloud [Private Service Connect](https://cloud.google.com/vpc/docs/private-service-connect)。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持 Google Cloud [Private Service Connect](https://cloud.google.com/vpc/docs/private-service-connect)。 - 你现在可以为部署在 Google Cloud 上的 TiDB Cloud Dedicated 集群创建私有端点并建立安全连接。 + 你现在可以为托管于 Google Cloud 的 TiDB Cloud Dedicated 集群创建私有端点并建立安全连接。 主要优势： @@ -205,19 +205,19 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 详细信息参见 [通过 Google Cloud 私有端点连接](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)。 -- 支持通过 changefeed 将 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的数据流式写入 [Google Cloud Storage (GCS)](https://cloud.google.com/storage)。 +- 支持通过 changefeed 将 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的数据流式写入 [Google Cloud Storage (GCS)](https://cloud.google.com/storage)。 - 你可以使用自己的 GCS 存储桶并精确配置权限，将 TiDB Cloud 的数据流式写入 GCS。数据复制到 GCS 后，你可按需分析数据变更。 + 你可以使用自己的 GCS 存储桶并精确配置权限，将数据从 TiDB Cloud 流式写入 GCS。数据复制到 GCS 后，你可以按需分析数据变更。 - 详细信息参见 [流式写入云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 + 详细信息参见 [流向云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 ## 2023 年 8 月 15 日 **通用变更** -- [数据服务（Beta）](https://tidbcloud.com/project/data-service) 支持 `GET` 请求的分页，提升开发体验。 +- [数据服务（beta）](https://tidbcloud.com/project/data-service) 支持 `GET` 请求的分页，提升开发体验。 - 对于 `GET` 请求，你可以在 **Advance Properties** 启用 **Pagination**，并在调用接口时通过查询参数指定 `page` 和 `page_size`。例如，获取第 2 页且每页 10 条数据： + 对于 `GET` 请求，你可以在 **Advance Properties** 启用 **Pagination**，并在调用接口时通过查询参数指定 `page` 和 `page_size`。例如，获取第 2 页、每页 10 条数据： ```bash curl --digest --user ':' \ @@ -228,7 +228,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 详细信息参见 [调用接口](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)。 -- [数据服务（Beta）](https://tidbcloud.com/project/data-service) 支持为 `GET` 请求的接口响应设置缓存 TTL。 +- [数据服务（beta）](https://tidbcloud.com/project/data-service) 支持为 `GET` 请求的接口响应设置缓存 TTL。 该功能可降低数据库负载，优化接口延迟。 @@ -236,18 +236,18 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 详细信息参见 [高级属性](/tidb-cloud/data-service-manage-endpoint.md#advanced-properties)。 -- 禁用 2023 年 8 月 15 日后在 AWS 上新建的 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的负载均衡优化，包括： +- 对 2023 年 8 月 15 日后在 AWS 上新建的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群，禁用负载均衡改进，包括： - 扩容 AWS 上的 TiDB 节点时，不再自动迁移现有连接到新节点。 - 缩容 AWS 上的 TiDB 节点时，不再自动迁移现有连接到可用节点。 - 此变更避免混合部署时的资源争用，不影响已启用该优化的现有集群。如需为新集群启用负载均衡优化，请联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 + 此变更避免混合部署时的资源争用，不影响已启用该改进的现有集群。如需为新集群启用负载均衡改进，请联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 ## 2023 年 8 月 8 日 **通用变更** -- [数据服务（Beta）](https://tidbcloud.com/project/data-service) 现支持 Basic 认证。 +- [数据服务（beta）](https://tidbcloud.com/project/data-service) 现支持 Basic 认证。 你可以在请求中将公钥作为用户名、私钥作为密码，使用 ['Basic' HTTP 认证](https://datatracker.ietf.org/doc/html/rfc7617)。与 Digest 认证相比，Basic 认证更简单，便于调用数据服务接口。 @@ -261,17 +261,17 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 TiDB Cloud 数据服务为每个 Data App 自动生成 OpenAPI 文档。你可以在文档中查看接口、参数和响应，并直接试用接口。 - 你还可以下载 Data App 及其已部署接口的 OpenAPI 规范（OAS），格式为 YAML 或 JSON。OAS 提供标准化 API 文档、简化集成和便捷代码生成，加快开发和协作。 + 你还可以下载 Data App 及其已部署接口的 OpenAPI 规范（OAS），支持 YAML 或 JSON 格式。OAS 提供标准化 API 文档、简化集成和便捷代码生成，加快开发和协作。 详细信息参见 [使用 OpenAPI 规范](/tidb-cloud/data-service-manage-data-app.md#use-the-openapi-specification) 及 [结合 Next.js 使用 OpenAPI 规范](/tidb-cloud/data-service-oas-with-nextjs.md)。 - 支持在 [Postman](https://www.postman.com/) 中运行 Data App。 - Postman 集成支持你将 Data App 的接口导入为集合到工作区，便于协作和无缝 API 测试，支持 Postman Web 和桌面应用。 + Postman 集成支持你将 Data App 的接口作为集合导入到工作区，便于协作和无缝 API 测试，支持 Postman Web 和桌面应用。 详细信息参见 [在 Postman 中运行 Data App](/tidb-cloud/data-service-postman-integration.md)。 -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 新增 **Pausing** 状态，支持低成本暂停，暂停期间不计费。 +- 为 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群引入新的 **Pausing** 状态，实现低成本暂停，暂停期间不计费。 当你点击 **Pause**，集群会先进入 **Pausing** 状态，暂停完成后状态变为 **Paused**。 @@ -283,20 +283,20 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- TiDB Cloud [数据服务](https://tidbcloud.com/project/data-service) 推出自动生成接口功能。 +- 在 TiDB Cloud [数据服务](https://tidbcloud.com/project/data-service) 中引入自动生成接口的强大功能。 开发者现在可以通过极少的点击和配置，轻松创建 HTTP 接口。无需重复编写样板代码，简化并加速接口创建，减少潜在错误。 详细用法参见 [自动生成接口](/tidb-cloud/data-service-manage-endpoint.md#generate-an-endpoint-automatically)。 -- TiDB Cloud [数据服务](https://tidbcloud.com/project/data-service) 支持接口的 `PUT` 和 `DELETE` 请求方法。 +- TiDB Cloud [数据服务](https://tidbcloud.com/project/data-service) 的接口现支持 `PUT` 和 `DELETE` 请求方法。 - `PUT` 方法用于更新或修改数据，类似于 `UPDATE` 语句。 - `DELETE` 方法用于删除数据，类似于 `DELETE` 语句。 详细信息参见 [配置属性](/tidb-cloud/data-service-manage-endpoint.md#configure-properties)。 -- TiDB Cloud [数据服务](https://tidbcloud.com/project/data-service) 支持 `POST`、`PUT`、`DELETE` 方法的 **批量操作**。 +- TiDB Cloud [数据服务](https://tidbcloud.com/project/data-service) 的 `POST`、`PUT`、`DELETE` 请求方法支持 **批量操作**。 启用 **Batch Operation** 后，你可以在单次请求中操作多行数据。例如，使用单个 `POST` 请求插入多行数据。 @@ -306,11 +306,11 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 新建 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的默认 TiDB 版本由 [v6.5.3](https://docs.pingcap.com/tidb/v6.5/release-6.5.3) 升级至 [v7.1.1](https://docs.pingcap.com/tidb/v7.1/release-7.1.1)。 +- 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v6.5.3](https://docs.pingcap.com/tidb/v6.5/release-6.5.3) 升级至 [v7.1.1](https://docs.pingcap.com/tidb/v7.1/release-7.1.1)。 **控制台变更** -- 优化 TiDB Cloud 用户访问 PingCAP 支持的入口，包括： +- 通过优化支持入口，简化 TiDB Cloud 用户访问 PingCAP 支持的流程。改进包括： - 在左下角 处新增 **Support** 入口。 - 优化 [TiDB Cloud 控制台](https://tidbcloud.com/) 右下角 **?** 图标菜单，使其更直观。 @@ -329,17 +329,17 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 各角色权限详情参见 [用户角色](/tidb-cloud/manage-user-access.md#user-roles)。 -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)（AWS）支持客户自管加密密钥（CMEK）（Beta）。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（AWS 托管）支持客户自管加密密钥（CMEK）（beta）。 - 你可以基于 AWS KMS 创建 CMEK，对存储在 EBS 和 S3 的数据进行加密，操作均可在 TiDB Cloud 控制台完成，确保数据由客户自主管理密钥，提升安全性。 + 你可以基于 AWS KMS 创建 CMEK，对存储在 EBS 和 S3 的数据进行加密，操作均可在 TiDB Cloud 控制台完成，确保数据由客户自管密钥加密，提升安全性。 - 该功能目前有一定限制，仅支持申请开通。如需申请，请联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 + 该功能有一定限制，仅支持申请开通。如需申请，请联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 -- 优化 TiDB Cloud 的导入功能，提升数据导入体验，具体改进如下： +- 优化 TiDB Cloud 的导入功能，提升数据导入体验。改进包括： - - Serverless 集群导入入口统一：本地文件和 Amazon S3 文件导入入口合并，便于切换。 - - 配置流程简化：Amazon S3 文件导入仅需一步配置，节省时间。 - - CSV 配置增强：CSV 配置项移至文件类型选项下，便于快速设置参数。 + - TiDB Cloud Serverless 统一导入入口：整合本地文件和 Amazon S3 文件导入入口，便于切换。 + - 配置简化：从 Amazon S3 导入数据仅需一步，节省时间和精力。 + - CSV 配置增强：CSV 配置项移至文件类型选项下，便于快速配置参数。 - 目标表选择优化：支持通过勾选选择目标表，无需复杂表达式，简化操作。 - 展示信息优化：修复导入过程中的信息不准确问题，并移除预览功能，避免数据不全和误导。 - 源文件映射改进：支持自定义源文件与目标表的映射关系，无需修改源文件名以适配命名要求。 @@ -348,47 +348,47 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 现已正式发布（GA）。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 现已正式发布（GA）。 -- 推出 TiDB Bot（Beta），基于 OpenAI 的智能聊天机器人，支持多语言、7x24 实时响应、集成文档访问。 +- 引入 TiDB Bot（beta），基于 OpenAI 的聊天机器人，支持多语言、7x24 实时响应和文档集成。 TiDB Bot 为你带来以下优势： - 持续支持：随时为你解答问题，提升支持体验。 - - 提高效率：自动回复减少等待时间，提升整体运维效率。 + - 提高效率：自动响应减少等待时间，提升整体运维效率。 - 无缝文档访问：可直接访问 TiDB Cloud 文档，便于信息检索和快速解决问题。 使用方法：在 [TiDB Cloud 控制台](https://tidbcloud.com) 右下角点击 **?**，选择 **Ask TiDB Bot** 开始对话。 -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群支持 [分支功能（Beta）](/tidb-cloud/branch-overview.md)。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群支持 [分支功能（beta）](/tidb-cloud/branch-overview.md)。 - TiDB Cloud 支持为 Serverless 集群创建分支。分支是原集群数据的独立副本，提供隔离环境，便于自由试验而不影响原集群。 + TiDB Cloud 支持为 Serverless 集群创建分支。分支是原集群数据的独立副本，提供隔离环境，便于连接和自由试验，无需担心影响原集群。 你可以通过 [TiDB Cloud 控制台](/tidb-cloud/branch-manage.md) 或 [TiDB Cloud CLI](/tidb-cloud/ticloud-branch-create.md) 为 2023 年 7 月 5 日后创建的 Serverless 集群创建分支。 - 如果你使用 GitHub 进行应用开发，可将分支集成到 CI/CD 流程，实现自动化测试而不影响生产库。详细信息参见 [将 TiDB Cloud Serverless 分支（Beta）集成到 GitHub](/tidb-cloud/branch-github-integration.md)。 + 如果你使用 GitHub 进行应用开发，可将分支集成到 GitHub CI/CD 流水线，实现自动测试 PR，且不影响生产数据库。详细信息参见 [将 TiDB Cloud Serverless 分支（Beta）集成到 GitHub](/tidb-cloud/branch-github-integration.md)。 -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持每周自动备份。详细信息参见 [开启自动备份](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持每周备份。详细信息参见 [开启自动备份](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)。 ## 2023 年 7 月 4 日 **通用变更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群支持时间点恢复（PITR）（Beta）。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群支持时间点恢复（PITR）（beta）。 - 你现在可以将 Serverless 集群恢复到过去 90 天内的任意时间点。该功能提升了 Serverless 集群的数据恢复能力。例如，数据写入出错时可用 PITR 恢复到早期状态。 + 你现在可以将 Serverless 集群恢复到过去 90 天内的任意时间点。该功能提升了数据恢复能力。例如，数据写入出错时可用 PITR 恢复到早期状态。 详细信息参见 [备份与恢复 TiDB Cloud Serverless 数据](/tidb-cloud/backup-and-restore-serverless.md#restore)。 **控制台变更** -- 优化 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群概览页的 **Usage This Month** 面板，提供更清晰的资源使用视图。 +- 优化 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群概览页的 **Usage This Month** 面板，提供更清晰的资源使用视图。 - 优化整体导航体验，具体变更如下： - 将右上角 **Organization** 和 **Account** 合并到左侧导航栏。 - - 将左侧导航栏 **Admin** 合并到 **Project**，并移除左上角 ☰ 悬浮菜单。现在你可以点击 切换项目及修改项目设置。 - - 将所有帮助和支持信息整合到右下角 **?** 图标菜单，包括文档、交互式教程、自学培训和支持入口。 + - 将左侧导航栏 **Admin** 合并到左侧导航栏 **Project**，并移除左上角 ☰ 悬浮菜单。现在你可以点击 切换项目及修改项目设置。 + - 将所有帮助和支持信息整合到右下角 **?** 图标菜单，包括文档、交互式教程、自助培训和支持入口。 - TiDB Cloud 控制台现支持暗黑模式，提供更舒适、护眼的体验。你可在左侧导航栏底部切换明暗模式。 @@ -396,13 +396,13 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 新建 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群不再预置示例数据集。 +- 新建 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群不再预置示例数据集。 ## 2023 年 6 月 20 日 **通用变更** -- 新建 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的默认 TiDB 版本由 [v6.5.2](https://docs.pingcap.com/tidb/v6.5/release-6.5.2) 升级至 [v6.5.3](https://docs.pingcap.com/tidb/v6.5/release-6.5.3)。 +- 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v6.5.2](https://docs.pingcap.com/tidb/v6.5/release-6.5.2) 升级至 [v6.5.3](https://docs.pingcap.com/tidb/v6.5/release-6.5.3)。 ## 2023 年 6 月 13 日 @@ -410,23 +410,23 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - 支持通过 changefeed 将数据流式写入 Amazon S3。 - 该功能实现 TiDB Cloud 与 Amazon S3 的无缝集成，支持将 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的数据实时捕获并复制到 Amazon S3，确保下游应用和分析系统获取最新数据。 + 该功能实现 TiDB Cloud 与 Amazon S3 的无缝集成，支持将 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的数据实时捕获并复制到 Amazon S3，确保下游应用和分析系统获取最新数据。 - 详细信息参见 [流式写入云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 + 详细信息参见 [流向云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 16 vCPU TiKV 节点最大存储由 4 TiB 提升至 6 TiB。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 16 vCPU TiKV 节点最大存储由 4 TiB 提升至 6 TiB。 - 该增强提升了集群的数据存储能力，提高了工作负载扩展效率，满足数据增长需求。 + 该增强提升了集群的数据存储能力，提高了工作负载扩展效率，满足不断增长的数据需求。 详细信息参见 [集群规格选择](/tidb-cloud/size-your-cluster.md)。 -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的 [监控指标保留期](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) 由 3 天延长至 7 天。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群的 [监控指标保留期](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) 由 3 天延长至 7 天。 保留期延长后，你可访问更多历史数据，有助于识别集群趋势和模式，提升决策和故障排查效率。 **控制台变更** -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 [**Key Visualizer**](/tidb-cloud/tune-performance.md#key-visualizer) 页面发布全新原生 Web 架构。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 [**Key Visualizer**](/tidb-cloud/tune-performance.md#key-visualizer) 页面发布全新原生 Web 架构。 新架构让你更便捷地浏览 **Key Visualizer** 页面，获取所需信息，提升 SQL 诊断体验和用户友好性。 @@ -434,24 +434,24 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 引入 Index Insight（Beta），为慢查询提供索引优化建议，提升查询性能。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群引入 Index Insight（beta），为慢查询提供索引推荐，优化查询性能。 - 通过 Index Insight，你可以： + 使用 Index Insight，你可提升数据库操作的整体性能和效率： - - 提升查询性能：识别慢查询并推荐合适索引，加速查询执行，缩短响应时间，提升用户体验。 - - 降低成本：优化查询性能，减少额外计算资源消耗，更高效利用现有基础设施，降低运维成本。 - - 简化优化流程：自动识别并推荐索引，无需手动分析和猜测，节省时间和精力。 - - 提高应用效率：优化数据库性能后，应用可承载更大负载和更多并发用户，提升扩展能力。 + - 查询性能提升：Index Insight 识别慢查询并推荐合适索引，加速查询执行，缩短响应时间，提升用户体验。 + - 成本优化：通过 Index Insight 优化查询性能，减少额外计算资源需求，更高效利用现有基础设施，降低运维成本。 + - 优化流程简化：Index Insight 简化索引优化流程，无需手动分析和猜测，节省时间和精力。 + - 应用效率提升：优化数据库性能后，应用可承载更大负载和更多并发用户，提升扩展效率。 - 使用方法：进入专属集群的 **Diagnosis** 页面，点击 **Index Insight BETA** 标签。 + 使用方法：进入 TiDB Cloud Dedicated 集群的 **Diagnosis** 页面，点击 **Index Insight BETA** 标签。 - 推出 [TiDB Playground](https://play.tidbcloud.com/?utm_source=docs&utm_medium=tidb_cloud_release_notes)，无需注册或安装即可体验 TiDB 全功能的交互式平台。 - TiDB Playground 提供一站式体验，支持扩展性、MySQL 兼容性和实时分析等能力。 + TiDB Playground 提供一站式体验，支持扩展性、MySQL 兼容性和实时分析等功能。 - 你可以在受控环境下实时试用 TiDB 功能，无需复杂配置，便于理解 TiDB 特性。 + 你可在受控环境下实时试用 TiDB 功能，无需复杂配置，便于理解 TiDB 特性。 - 立即体验，请访问 [**TiDB Playground**](https://play.tidbcloud.com/?utm_source=docs&utm_medium=tidb_cloud_release_notes) 页面，选择你想探索的功能，开始体验。 + 立即体验，请访问 [**TiDB Playground**](https://play.tidbcloud.com/?utm_source=docs&utm_medium=tidb_cloud_release_notes) 页面，选择想要探索的功能，开始体验。 ## 2023 年 6 月 5 日 @@ -459,16 +459,16 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - 支持将 [Data App](/tidb-cloud/tidb-cloud-glossary.md#data-app) 连接到 GitHub。 - [连接 Data App 到 GitHub](/tidb-cloud/data-service-manage-github-connection.md) 后，你可以将所有配置作为 [代码文件](/tidb-cloud/data-service-app-config-files.md) 管理，实现与系统架构和 DevOps 流程的无缝集成。 + [连接 Data App 到 GitHub](/tidb-cloud/data-service-manage-github-connection.md) 后，你可将所有配置作为 [代码文件](/tidb-cloud/data-service-app-config-files.md) 管理，实现与系统架构和 DevOps 流程的无缝集成。 该功能提升 Data App 的 CI/CD 体验，支持： - - 通过 GitHub 自动部署 Data App 变更。 - - 在 GitHub 上配置 Data App 的 CI/CD 流程并进行版本控制。 + - 使用 GitHub 自动部署 Data App 变更。 + - 在 GitHub 上配置 Data App 变更的 CI/CD 流程并进行版本控制。 - 断开已连接的 GitHub 仓库。 - 部署前审查接口变更。 - 查看部署历史并在失败时采取措施。 - - 重新部署某个提交以回滚到早期部署。 + - 重新部署 commit 回滚到早期部署。 详细信息参见 [通过 GitHub 自动部署 Data App](/tidb-cloud/data-service-manage-github-connection.md)。 @@ -476,11 +476,11 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 为简化和明晰产品命名，我们更新了产品名称： +- 为简化和明晰，产品名称更新如下： - "TiDB Cloud Serverless Tier" 现称为 "TiDB Cloud Serverless" - - "TiDB Cloud Dedicated Tier" 现称为 "TiDB Cloud Dedicated 集群" - - "TiDB On-Premises" 现称为 "TiDB 自管版" + - "TiDB Cloud Dedicated Tier" 现称为 "TiDB Cloud Dedicated" + - "TiDB On-Premises" 现称为 "TiDB Self-Managed" 名称焕新，性能如一。你的体验始终是我们的首要任务。 @@ -490,11 +490,11 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - 增强 TiDB Cloud 数据迁移功能对增量数据迁移的支持。 - 你现在可以指定 binlog 位置或全局事务标识（GTID），仅复制指定位置之后产生的增量数据到 TiDB Cloud。该增强为你选择和复制所需数据提供更大灵活性，满足特定需求。 + 你现在可以指定 binlog 位置或全局事务标识（GTID），仅复制指定位置之后产生的增量数据到 TiDB Cloud。该增强为你按需选择和复制数据提供更大灵活性。 详情参见 [仅迁移 MySQL 兼容数据库的增量数据到 TiDB Cloud](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)。 -- [**Events**](/tidb-cloud/tidb-cloud-events.md) 页面新增事件类型（`ImportData`）。 +- 在 [**Events**](/tidb-cloud/tidb-cloud-events.md) 页面新增事件类型（`ImportData`）。 - 从 TiDB Cloud 控制台移除 **Playground**。 @@ -504,7 +504,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 上传 CSV 文件到 TiDB 时，列名除英文和数字外，还可使用中文、日文等字符。特殊字符仅支持下划线（`_`）。 +- 上传 CSV 文件到 TiDB 时，除英文和数字外，还可使用中文、日文等字符定义列名。但特殊字符仅支持下划线（`_`）。 详情参见 [导入本地文件到 TiDB Cloud](/tidb-cloud/tidb-cloud-import-local-files.md)。 @@ -512,11 +512,11 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **控制台变更** -- 为专属集群和 Serverless 集群引入按功能分类的左侧导航入口。 +- 为 Dedicated 和 Serverless 集群引入按功能分类的左侧导航入口。 - 新导航更易发现功能入口。可在集群概览页体验新导航。 + 新导航更易发现功能入口，提升操作直观性。可在集群概览页体验新导航。 -- 专属集群 **Diagnosis** 页的以下两个标签页发布全新原生 Web 架构： +- Dedicated 集群 **Diagnosis** 页的以下两个标签页发布全新原生 Web 架构： - [Slow Query](/tidb-cloud/tune-performance.md#slow-query) - [SQL Statement](/tidb-cloud/tune-performance.md#statement-analysis) @@ -529,15 +529,15 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - 支持为 2023 年 4 月 26 日后创建的 GCP 集群变更节点规格。 - 你可以根据需求升级为高性能节点或降级为低成本节点，灵活调整集群容量，优化成本。 + 你可以根据需求升级为高性能节点或降级为低成本节点，实现弹性扩容和成本优化。 详细步骤参见 [变更节点规格](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)。 -- 支持导入压缩文件。你可以导入 `.gzip`、`.gz`、`.zstd`、`.zst`、`.snappy` 格式的 CSV 和 SQL 文件。该功能提升了数据导入效率，降低数据传输成本。 +- 支持导入压缩文件。可导入 `.gzip`、`.gz`、`.zstd`、`.zst`、`.snappy` 格式的 CSV 和 SQL 文件。该功能提升数据导入效率，降低数据传输成本。 - 详细信息参见 [从云存储导入 CSV 文件到 TiDB Cloud Dedicated 集群](/tidb-cloud/import-csv-files.md) 及 [导入示例数据](/tidb-cloud/import-sample-data.md)。 + 详细信息参见 [从云存储导入 CSV 文件到 TiDB Cloud Dedicated](/tidb-cloud/import-csv-files.md) 及 [导入示例数据](/tidb-cloud/import-sample-data.md)。 -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 支持基于 AWS PrivateLink 的私有端点连接，作为新的网络访问管理选项。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群支持基于 AWS PrivateLink 的私有端点连接，作为新的网络访问管理选项。 私有端点连接不会将数据暴露在公网，并支持 CIDR 重叠，便于网络管理。 @@ -545,17 +545,17 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **控制台变更** -- [**Event**](/tidb-cloud/tidb-cloud-events.md) 页面新增事件类型，记录专属集群的备份、恢复和 changefeed 操作。 +- [**Event**](/tidb-cloud/tidb-cloud-events.md) 页面新增事件类型，记录 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的备份、恢复和 changefeed 操作。 事件类型完整列表参见 [已记录事件](/tidb-cloud/tidb-cloud-events.md#logged-events)。 -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的 [**SQL Diagnosis**](/tidb-cloud/tune-performance.md) 页面新增 **SQL Statement** 标签。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的 [**SQL Diagnosis**](/tidb-cloud/tune-performance.md) 页面新增 **SQL Statement** 标签。 **SQL Statement** 标签提供： - - 所有 SQL 语句的全面概览，便于识别和诊断慢查询。 - - 每条 SQL 语句的详细信息，如查询时间、执行计划、数据库响应，助力优化性能。 - - 友好的界面，便于排序、筛选和搜索大量数据，聚焦关键查询。 + - 展示所有 SQL 语句的执行概览，便于识别和诊断慢查询。 + - 展示每条 SQL 语句的详细信息，如查询时间、执行计划、数据库响应等，助力性能优化。 + - 友好的界面，支持排序、筛选和搜索，便于聚焦关键查询。 详细信息参见 [Statement Analysis](/tidb-cloud/tune-performance.md#statement-analysis)。 @@ -563,9 +563,9 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 支持直接访问 TiDB [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 所在区域的 [Data Service endpoint](/tidb-cloud/tidb-cloud-glossary.md#endpoint)。 +- 支持直接访问 TiDB [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群所在区域的 [Data Service endpoint](/tidb-cloud/tidb-cloud-glossary.md#endpoint)。 - 新建 Serverless 集群的 endpoint URL 现包含集群区域信息。通过 `.data.tidbcloud.com` 可直接访问对应区域的 endpoint。 + 新建 Serverless Tier 集群的 endpoint URL 现包含集群区域信息。通过 `.data.tidbcloud.com` 可直接访问对应区域的 endpoint。 你也可以请求全局域名 `data.tidbcloud.com`，此时 TiDB Cloud 会内部重定向到目标区域，但可能增加延迟。如采用此方式，调用接口时请确保 curl 命令加上 `--location-trusted`。 @@ -575,46 +575,46 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 组织下前 5 个 [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 可享受如下免费额度： +- 组织下前五个 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群，每个集群享有如下免费额度： - 行存储：5 GiB - - [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit)：每月 5000 万 RU + - [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit)：每月 5000 万 RUs - 2023 年 5 月 31 日前，Serverless 集群仍免费（100% 折扣）。之后超出免费额度部分将计费。 + 截至 2023 年 5 月 31 日，Serverless Tier 集群仍免费（100% 折扣）。之后超出免费额度部分将计费。 你可在集群 **Overview** 页的 **Usage This Month** 区域 [监控用量或提升额度](/tidb-cloud/manage-serverless-spend-limit.md)。免费额度用尽后，集群读写操作将被限流，直至提升额度或新月重置。 - 各资源（读、写、SQL CPU、网络出口）RU 消耗、定价及限流说明参见 [TiDB Cloud Serverless Tier 价格详情](https://www.pingcap.com/tidb-cloud-serverless-pricing-details)。 + 各资源（读、写、SQL CPU、网络出口）RU 消耗、定价及限流详情参见 [TiDB Cloud Serverless Tier 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details)。 -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 支持备份与恢复。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群支持备份与恢复。 详细信息参见 [备份与恢复 TiDB 集群数据](/tidb-cloud/backup-and-restore-serverless.md)。 -- 新建 [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的默认 TiDB 版本由 [v6.5.1](https://docs.pingcap.com/tidb/v6.5/release-6.5.1) 升级至 [v6.5.2](https://docs.pingcap.com/tidb/v6.5/release-6.5.2)。 +- 新建 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v6.5.1](https://docs.pingcap.com/tidb/v6.5/release-6.5.1) 升级至 [v6.5.2](https://docs.pingcap.com/tidb/v6.5/release-6.5.2)。 -- 提供维护窗口功能，便于你为 [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 计划和管理维护任务。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持维护窗口功能，便于你安排和管理计划性维护。 维护窗口是执行操作系统更新、安全补丁、基础设施升级等计划性维护的指定时间段，保障 TiDB Cloud 服务的可靠性、安全性和性能。 - 维护期间可能出现短暂连接中断或 QPS 波动，但集群保持可用，SQL 操作、数据导入、备份、恢复、迁移、同步等任务可正常运行。维护期间允许和禁止的操作见 [文档](/tidb-cloud/configure-maintenance-window.md#allowed-and-disallowed-operations-during-a-maintenance-window)。 + 维护期间可能出现短暂连接中断或 QPS 波动，但集群保持可用，SQL 操作、数据导入、备份、恢复、迁移和同步任务均可正常运行。维护期间允许和禁止的操作详见 [文档](/tidb-cloud/configure-maintenance-window.md#allowed-and-disallowed-operations-during-a-maintenance-window)。 - 我们将尽量减少维护频率。若有维护计划，默认开始时间为目标周三 03:00（以组织时区为准）。请关注维护计划，合理安排操作。 + 我们将尽量减少维护频率。如有维护计划，默认开始时间为目标周三 03:00（以组织时区为准）。请关注维护计划，合理安排操作。 - - 每次维护窗口，TiDB Cloud 会发送三封邮件通知：维护前、开始时、结束后。 + - TiDB Cloud 会为每次维护窗口发送三封邮件通知：维护前、开始时和结束后。 - 你可在 **Maintenance** 页面修改维护开始时间或延后维护，以减少影响。 详细信息参见 [配置维护窗口](/tidb-cloud/configure-maintenance-window.md)。 -- 优化 AWS 上新建（2023 年 4 月 25 日后）[专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 TiDB 负载均衡，缩放 TiDB 节点时减少连接中断。 +- 优化 AWS 上新建的 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 TiDB 负载均衡，缩容/扩容时减少连接中断。 - 扩容时，支持自动迁移现有连接到新 TiDB 节点。 - 缩容时，支持自动迁移现有连接到可用 TiDB 节点。 - 目前该功能适用于所有 AWS 上的专属集群。 + 目前该功能适用于所有 AWS 托管的 Dedicated Tier 集群。 **控制台变更** -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 [Monitoring](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面发布全新原生 Web 架构。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 [Monitoring](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面发布全新原生 Web 架构。 新架构让你更便捷地浏览 [Monitoring](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面，提升监控体验和用户友好性。 @@ -622,17 +622,17 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持扩缩 [数据迁移任务规格](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration)。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持扩缩 [数据迁移作业规格](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration)。 - 你可以通过扩容提升迁移性能，或缩容降低成本。 + 你可以通过扩容提升迁移性能，或通过缩容降低成本。 详细信息参见 [使用数据迁移迁移 MySQL 兼容数据库到 TiDB Cloud](/tidb-cloud/migrate-from-mysql-using-data-migration.md#scale-a-migration-job-specification)。 **控制台变更** -- 全新设计的 [集群创建](https://tidbcloud.com/clusters/create-cluster) UI，更加友好，支持一键创建和配置集群。 +- 全新 UI 设计优化 [集群创建](https://tidbcloud.com/clusters/create-cluster) 体验，支持更便捷的集群创建和配置。 - 新设计简化界面，减少视觉干扰，指引清晰。点击 **Create** 后将直接跳转到集群概览页，无需等待集群创建完成。 + 新设计简化操作、减少视觉干扰、提供清晰指引。点击 **Create** 后将直接跳转到集群概览页，无需等待集群创建完成。 详细信息参见 [创建集群](/tidb-cloud/create-tidb-cluster.md)。 @@ -644,20 +644,20 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 优化 AWS 上 [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 TiDB 负载均衡，缩放 TiDB 节点时减少连接中断。 +- 优化 AWS 托管 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 TiDB 负载均衡，缩容/扩容时减少连接中断。 - 扩容时，支持自动迁移现有连接到新 TiDB 节点。 - 缩容时，支持自动迁移现有连接到可用 TiDB 节点。 - 目前该功能仅适用于 AWS `Oregon (us-west-2)` 区域的专属集群。 + 目前该功能仅适用于 AWS `Oregon (us-west-2)` 区域的 Dedicated Tier 集群。 -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持 [New Relic](https://newrelic.com/) 集成。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持 [New Relic](https://newrelic.com/) 集成。 - 你可以将 TiDB 集群的监控数据发送到 [New Relic](https://newrelic.com/)，在 New Relic 上同时监控应用和数据库性能，便于快速定位和排查问题。 + 你可以配置 TiDB Cloud 将集群指标数据发送到 [New Relic](https://newrelic.com/)，实现应用与数据库性能的统一监控和分析，便于快速定位和解决问题。 集成步骤及可用指标参见 [集成 New Relic](/tidb-cloud/monitor-new-relic-integration.md)。 -- 为专属集群的 Prometheus 集成新增以下 [changefeed](/tidb-cloud/changefeed-overview.md) 指标： +- 为 Dedicated Tier 集群的 Prometheus 集成新增以下 [changefeed](/tidb-cloud/changefeed-overview.md) 指标： - `tidbcloud_changefeed_latency` - `tidbcloud_changefeed_replica_rows` @@ -666,13 +666,13 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **控制台变更** -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 [Monitoring](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面升级为 [节点级资源指标](/tidb-cloud/built-in-monitoring.md#server)。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 [Monitoring](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面现采用 [节点级资源指标](/tidb-cloud/built-in-monitoring.md#server)。 节点级指标可更准确反映资源消耗，帮助你了解实际服务使用情况。 - 访问方法：进入集群 [Monitoring](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面，点击 **Metrics** 标签下的 **Server** 类别。 + 访问方法：进入集群 [Monitoring](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面，在 **Metrics** 标签下选择 **Server** 类别。 -- 优化 [Billing](/tidb-cloud/tidb-cloud-billing.md#billing-details) 页面，将账单项按 **Summary by Project** 和 **Summary by Service** 分类，信息更清晰。 +- 优化 [Billing](/tidb-cloud/tidb-cloud-billing.md#billing-details) 页面，重组 **Summary by Project** 和 **Summary by Service**，使账单信息更清晰。 ## 2023 年 4 月 4 日 @@ -680,28 +680,28 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - 为防止误报，从 [TiDB Cloud 内置告警](/tidb-cloud/monitor-built-in-alerting.md#tidb-cloud-built-in-alert-conditions) 移除以下两项告警。因为单节点临时离线或 OOM 不会显著影响集群整体健康。 - - 集群中至少有一个 TiDB 节点 OOM - - 一个或多个集群节点离线 + - 集群中至少有一个 TiDB 节点内存耗尽。 + - 一个或多个集群节点离线。 **控制台变更** -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 新增 [Alerts](/tidb-cloud/monitor-built-in-alerting.md) 页面，展示每个集群的活跃和已关闭告警。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群引入 [Alerts](/tidb-cloud/monitor-built-in-alerting.md) 页面，展示每个集群的活跃和已关闭告警。 **Alerts** 页面提供： - - 直观友好的界面。即使未订阅告警邮件，也可在此查看集群告警。 - - 高级筛选，按严重性、状态等属性快速查找和排序，并可查看近 7 天历史，便于追踪。 - - **Edit Rule** 功能。可自定义告警规则，满足集群需求。 + - 直观友好的界面。即使未订阅告警邮件，也可在此页面查看集群告警。 + - 高级筛选，支持按严重性、状态等属性快速查找和排序，并可查看近 7 天历史，便于追踪。 + - **Edit Rule** 功能。你可自定义告警规则，满足集群需求。 详细信息参见 [TiDB Cloud 内置告警](/tidb-cloud/monitor-built-in-alerting.md)。 -- 将 TiDB Cloud 的帮助信息和操作整合到一个入口。 +- 将 TiDB Cloud 的帮助相关信息和操作整合到一个入口。 - 现在，你可在 [TiDB Cloud 控制台](https://tidbcloud.com/) 右下角点击 **?** 获取所有帮助信息及联系支持。 + 现在，你可在 [TiDB Cloud 控制台](https://tidbcloud.com/) 右下角点击 **?** 获取所有帮助信息并联系支持。 -- 推出 [Getting Started](https://tidbcloud.com/getting-started) 页面，帮助你快速了解 TiDB Cloud。 +- 引入 [Getting Started](https://tidbcloud.com/getting-started) 页面，帮助你了解 TiDB Cloud。 - **Getting Started** 页面提供交互式教程、基础指南和实用链接。通过交互式教程，你可用预置行业数据集（Steam Game Dataset、S&P 500 Dataset）体验 TiDB Cloud 功能和 HTAP 能力。 + **Getting Started** 页面提供交互式教程、基础指南和实用链接。通过交互式教程，你可轻松体验 TiDB Cloud 功能和 HTAP 能力，内置行业数据集（Steam Game Dataset 和 S&P 500 Dataset）。 访问方法：在 [TiDB Cloud 控制台](https://tidbcloud.com/) 左侧导航栏点击 **Getting Started**。你可点击 **Query Sample Dataset** 打开交互式教程，或点击其他链接探索 TiDB Cloud。也可在右下角 **?** 菜单点击 **Interactive Tutorials**。 @@ -709,9 +709,9 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [数据服务（Beta）](/tidb-cloud/data-service-overview.md) 支持 Data App 更细粒度的访问控制。 +- [数据服务（beta）](/tidb-cloud/data-service-overview.md) 支持 Data App 更细粒度的访问控制。 - 在 Data App 详情页，你可以关联集群并为每个 API key 指定角色。角色控制 API key 是否可读写关联集群数据，可设为 `ReadOnly` 或 `ReadAndWrite`。该功能实现 Data App 的集群级和权限级访问控制，灵活满足业务需求。 + 在 Data App 详情页，你可关联集群并为每个 API key 指定角色。角色控制 API key 是否可对关联集群读写数据，可设为 `ReadOnly` 或 `ReadAndWrite`。该功能实现 Data App 的集群级和权限级访问控制，灵活满足业务需求。 详细信息参见 [管理关联集群](/tidb-cloud/data-service-manage-data-app.md#manage-linked-data-sources) 和 [管理 API key](/tidb-cloud/data-service-api-key.md)。 @@ -719,7 +719,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [changefeed](/tidb-cloud/changefeed-overview.md) 新增 2 RCUs、4 RCUs、8 RCUs 规格，支持在 [创建 changefeed](/tidb-cloud/changefeed-overview.md#create-a-changefeed) 时选择。 +- [changefeed](/tidb-cloud/changefeed-overview.md) 新增 2 RCUs、4 RCUs、8 RCUs 规格，支持在 [创建 changefeed](/tidb-cloud/changefeed-overview.md#create-a-changefeed) 时选择所需规格。 使用新规格，数据同步成本最高可降低 87.5%（相较于原需 16 RCUs 的场景）。 @@ -729,19 +729,19 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 详细信息参见 [扩缩 changefeed](/tidb-cloud/changefeed-overview.md#scale-a-changefeed)。 -- 支持将 AWS 上 [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的增量数据实时同步到同项目同区域的 [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)。 +- 支持将 AWS 上 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的增量数据实时同步到同项目同区域的 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群。 - 详细信息参见 [流式写入 TiDB Cloud](/tidb-cloud/changefeed-sink-to-tidb-cloud.md)。 + 详细信息参见 [流向 TiDB Cloud](/tidb-cloud/changefeed-sink-to-tidb-cloud.md)。 -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 [数据迁移](/tidb-cloud/migrate-from-mysql-using-data-migration.md) 功能新增支持两个 GCP 区域：`Singapore (asia-southeast1)` 和 `Oregon (us-west1)`。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的数据迁移功能支持两个新的 GCP 区域：`Singapore (asia-southeast1)` 和 `Oregon (us-west1)`。 - 新增区域为数据迁移提供更多选择。若上游数据存储于或靠近这些区域，可获得更快、更可靠的迁移体验。 + 新增区域为数据迁移提供更多选择。若上游数据位于或接近这些区域，可实现更快、更可靠的迁移。 详细信息参见 [使用数据迁移迁移 MySQL 兼容数据库到 TiDB Cloud](/tidb-cloud/migrate-from-mysql-using-data-migration.md)。 **控制台变更** -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的 [Slow Query](/tidb-cloud/tune-performance.md#slow-query) 页面发布全新原生 Web 架构。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的 [Slow Query](/tidb-cloud/tune-performance.md#slow-query) 页面发布全新原生 Web 架构。 新架构让你更便捷地浏览 [Slow Query](/tidb-cloud/tune-performance.md#slow-query) 页面，提升 SQL 诊断体验和用户友好性。 @@ -749,11 +749,11 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 推出 [数据服务（Beta）](https://tidbcloud.com/project/data-service)，支持通过自定义 API endpoint 以 HTTPS 请求访问数据。 +- 为 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群引入 [数据服务（beta）](https://tidbcloud.com/project/data-service)，支持通过自定义 API endpoint 以 HTTPS 请求访问数据。 数据服务可无缝集成 TiDB Cloud 与任何兼容 HTTPS 的应用或服务。常见场景包括： - - 移动或 Web 应用直接访问 TiDB 集群数据库。 + - 直接从移动或 Web 应用访问 TiDB 集群数据库。 - 使用无服务器边缘函数调用接口，避免连接池扩展性问题。 - 通过数据服务作为数据源集成数据可视化项目。 - 在不支持 MySQL 接口的环境中连接数据库。 @@ -766,11 +766,11 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - [数据服务快速入门](/tidb-cloud/data-service-get-started.md) - [Chat2Query API 快速入门](/tidb-cloud/use-chat2query-api.md) -- 支持缩小 TiDB、TiKV、TiFlash 节点规格，对 2022 年 12 月 31 日后在 AWS 上创建的 [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 进行缩容。 +- 支持缩小 TiDB、TiKV、TiFlash 节点规格，对 2022 年 12 月 31 日后 AWS 托管的 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群进行缩容。 你可通过 [TiDB Cloud 控制台](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram) 或 [TiDB Cloud API (beta)](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) 缩小节点规格。 -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 [数据迁移](/tidb-cloud/migrate-from-mysql-using-data-migration.md) 功能新增支持 GCP 区域：`Tokyo (asia-northeast1)`。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的数据迁移功能支持新的 GCP 区域：`Tokyo (asia-northeast1)`。 该功能便于将 GCP 上的 MySQL 兼容数据库迁移到 TiDB 集群。 @@ -778,13 +778,13 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **控制台变更** -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 新增 **Events** 页面，记录集群主要变更。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群引入 **Events** 页面，记录集群主要变更。 - 你可查看最近 7 天的事件历史，追踪触发时间、操作用户等信息。例如，查看集群暂停、规格变更等事件。 + 你可查看最近 7 天的事件历史，追踪触发时间、操作用户等。例如，可查看集群暂停、规格变更等事件。 详细信息参见 [TiDB Cloud 集群事件](/tidb-cloud/tidb-cloud-events.md)。 -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的 **Monitoring** 页面新增 **Database Status** 标签，展示以下数据库级指标： +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的 **Monitoring** 页面新增 **Database Status** 标签，展示以下数据库级指标： - QPS Per DB - Average Query Duration Per DB @@ -792,17 +792,17 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 通过这些指标，你可监控各数据库性能，做出数据驱动决策，提升应用性能。 - 详细信息参见 [Serverless 集群监控指标](/tidb-cloud/built-in-monitoring.md)。 + 详细信息参见 [Serverless Tier 集群监控指标](/tidb-cloud/built-in-monitoring.md)。 ## 2023 年 3 月 14 日 **通用变更** -- 新建 [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的默认 TiDB 版本由 [v6.5.0](https://docs.pingcap.com/tidb/v6.5/release-6.5.0) 升级至 [v6.5.1](https://docs.pingcap.com/tidb/v6.5/release-6.5.1)。 +- 新建 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v6.5.0](https://docs.pingcap.com/tidb/v6.5/release-6.5.0) 升级至 [v6.5.1](https://docs.pingcap.com/tidb/v6.5/release-6.5.1)。 -- 支持在上传带表头的本地 CSV 文件时，修改 TiDB Cloud 自动创建目标表的列名。 +- 支持在上传带表头的本地 CSV 文件时，修改 TiDB Cloud 创建目标表的列名。 - 向 [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 导入带表头的本地 CSV 文件时，若表头列名不符合 TiDB Cloud 命名规范，将在对应列名旁显示警告图标。你可悬停图标，根据提示编辑或输入新列名。 + 向 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群导入带表头的本地 CSV 文件时，若表头列名不符合 TiDB Cloud 命名规范，将在对应列名旁显示警告图标。你可悬停查看提示并按需修改列名。 列命名规范参见 [导入本地文件](/tidb-cloud/tidb-cloud-import-local-files.md#import-local-files)。 @@ -810,17 +810,17 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -- 所有 [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的默认 TiDB 版本由 [v6.4.0](https://docs.pingcap.com/tidb/v6.4/release-6.4.0) 升级至 [v6.6.0](https://docs.pingcap.com/tidb/v6.6/release-6.6.0)。 +- 所有 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的默认 TiDB 版本由 [v6.4.0](https://docs.pingcap.com/tidb/v6.4/release-6.4.0) 升级至 [v6.6.0](https://docs.pingcap.com/tidb/v6.6/release-6.6.0)。 ## 2023 年 2 月 28 日 **通用变更** -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 新增 [SQL Diagnosis](/tidb-cloud/tune-performance.md) 功能。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群新增 [SQL Diagnosis](/tidb-cloud/tune-performance.md) 功能。 - 通过 SQL Diagnosis，你可深入了解 SQL 运行时状态，提升 SQL 性能调优效率。目前 Serverless 集群仅提供慢查询数据。 + 通过 SQL Diagnosis，你可深入了解 SQL 运行时状态，提升 SQL 性能调优效率。目前 Serverless Tier 仅提供慢查询数据。 - 使用方法：在 Serverless 集群页面左侧导航栏点击 **SQL Diagnosis**。 + 使用方法：在集群页面左侧导航栏点击 **SQL Diagnosis**。 **控制台变更** @@ -833,14 +833,14 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **API 变更** -- 发布多项数据导入相关 TiDB Cloud API 接口： +- 发布多项 TiDB Cloud API 接口用于数据导入： - 列出所有导入任务 - 获取导入任务详情 - 创建导入任务 - 更新导入任务 - 上传本地文件 - - 启动导入前预览数据 + - 导入前预览数据 - 获取导入任务角色信息 详细信息参见 [API 文档](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Import)。 @@ -851,7 +851,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - 支持使用 [控制台审计日志](/tidb-cloud/tidb-cloud-console-auditing.md) 跟踪组织成员在 [TiDB Cloud 控制台](https://tidbcloud.com/) 的各类操作。 - 该功能仅对 `Owner` 或 `Audit Admin` 可见，默认关闭。启用方法：在 [TiDB Cloud 控制台](https://tidbcloud.com/) 右上角点击 **Organization** > **Console Audit Logging**。 + 该功能仅对 `Owner` 或 `Audit Admin` 可见，默认关闭。开启方法：在 [TiDB Cloud 控制台](https://tidbcloud.com/) 右上角点击 **Organization** > **Console Audit Logging**。 通过分析审计日志，可识别可疑操作，提升组织资源和数据安全。 @@ -861,26 +861,26 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - [TiDB Cloud CLI](/tidb-cloud/cli-reference.md) 新增 `ticloud cluster connect-info` 命令。 - `ticloud cluster connect-info` 可获取集群连接字符串。需将 [ticloud 升级](/tidb-cloud/ticloud-upgrade.md) 至 v0.3.2 或更高版本。 + `ticloud cluster connect-info` 可获取集群连接字符串。使用前请将 [ticloud 升级](/tidb-cloud/ticloud-upgrade.md) 至 v0.3.2 或更高版本。 ## 2023 年 2 月 21 日 **通用变更** -- 支持使用 IAM 用户的 AWS 访问密钥访问 Amazon S3 存储桶导入数据。 +- 导入数据到 TiDB Cloud 时，支持使用 IAM 用户的 AWS 访问密钥访问 Amazon S3 存储桶。 该方式比使用 Role ARN 更简单。详细信息参见 [配置 Amazon S3 访问](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 -- 监控指标保留期由 2 天延长： +- [监控指标保留期](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) 由 2 天延长： - - 专属集群可查看近 7 天指标数据。 - - Serverless 集群可查看近 3 天指标数据。 + - Dedicated Tier 集群可查看近 7 天指标数据。 + - Serverless Tier 集群可查看近 3 天指标数据。 - 保留期延长后，你可访问更多历史数据，有助于识别趋势和模式，提升决策和故障排查效率。 + 保留期延长后，你可访问更多历史数据，有助于识别集群趋势和模式，提升决策和故障排查效率。 **控制台变更** -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的 Monitoring 页面发布全新原生 Web 架构。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的 Monitoring 页面发布全新原生 Web 架构。 新架构让你更便捷地浏览 Monitoring 页面，提升监控体验和用户友好性。 @@ -890,21 +890,21 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 - [TiDB Cloud CLI](/tidb-cloud/cli-reference.md) 新增 [`ticloud connect`](/tidb-cloud/ticloud-serverless-shell.md) 命令。 - `ticloud connect` 支持你无需安装 SQL 客户端，直接从本地连接 TiDB Cloud 集群并执行 SQL 语句。 + `ticloud connect` 支持你在本地无需安装 SQL 客户端即可连接 TiDB Cloud 集群，并在 CLI 中执行 SQL 语句。 ## 2023 年 2 月 14 日 **通用变更** -- 支持缩减 TiKV 和 TiFlash 节点数量，对 [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 进行缩容。 +- 支持缩减 TiKV 和 TiFlash 节点数量，对 TiDB [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群进行缩容。 你可通过 [TiDB Cloud 控制台](/tidb-cloud/scale-tidb-cluster.md#change-node-number) 或 [TiDB Cloud API (beta)](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) 缩减节点数量。 **控制台变更** -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 新增 **Monitoring** 页面。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群引入 **Monitoring** 页面。 - **Monitoring** 页面提供 SQL 每秒执行数、平均查询时长、失败查询数等多项指标，帮助你全面了解 Serverless 集群 SQL 性能。 + **Monitoring** 页面提供 SQL 每秒执行数、平均查询时长、失败查询数等多项指标，帮助你全面了解集群 SQL 性能。 详细信息参见 [TiDB Cloud 内置监控](/tidb-cloud/built-in-monitoring.md)。 @@ -912,7 +912,7 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **CLI 变更** -- 推出 TiDB Cloud CLI 客户端 [`ticloud`](/tidb-cloud/cli-reference.md)。 +- 发布 TiDB Cloud CLI 客户端 [`ticloud`](/tidb-cloud/cli-reference.md)。 使用 `ticloud`，你可通过命令行或自动化流程轻松管理 TiDB Cloud 资源。针对 GitHub Actions，我们提供了 [`setup-tidbcloud-cli`](https://github.com/marketplace/actions/set-up-tidbcloud-cli) 便捷集成。 @@ -922,29 +922,29 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 **通用变更** -* 支持使用 Microsoft 账户 [注册](https://tidbcloud.com/free-trial) TiDB Cloud。 +* 支持使用 Microsoft 账号 [注册](https://tidbcloud.com/free-trial) TiDB Cloud。 ## 2023 年 1 月 17 日 **通用变更** -- 新建 [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的默认 TiDB 版本由 [v6.1.3](https://docs.pingcap.com/tidb/stable/release-6.1.3) 升级至 [v6.5.0](https://docs.pingcap.com/tidb/stable/release-6.5.0)。 +- 新建 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v6.1.3](https://docs.pingcap.com/tidb/stable/release-6.1.3) 升级至 [v6.5.0](https://docs.pingcap.com/tidb/stable/release-6.5.0)。 -- 新注册用户将自动创建一个免费的 [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)，便于快速开启数据探索之旅。 +- 新注册用户将自动创建一个免费的 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群，便于快速开启数据探索之旅。 -- [专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 新增支持 AWS 区域：`Seoul (ap-northeast-2)`。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持新增 AWS 区域：`Seoul (ap-northeast-2)`。 该区域支持以下功能： - [使用数据迁移迁移 MySQL 兼容数据库到 TiDB Cloud](/tidb-cloud/migrate-from-mysql-using-data-migration.md) - - [通过 changefeed 将 TiDB Cloud 数据流式写入其他服务](/tidb-cloud/changefeed-overview.md) + - [通过 changefeed 将数据流式写入其他服务](/tidb-cloud/changefeed-overview.md) - [备份与恢复 TiDB 集群数据](/tidb-cloud/backup-and-restore.md) ## 2023 年 1 月 10 日 **通用变更** -- 优化本地 CSV 文件导入 TiDB 的体验，提升 [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 用户体验。 +- 优化本地 CSV 文件导入 TiDB 的体验，提升 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的易用性。 - 现在可直接拖拽 CSV 文件到 **Import** 页上传区域。 - 创建导入任务时，若目标数据库或表不存在，可输入名称自动创建。新建目标表时可指定主键或选择多字段组成复合主键。 @@ -958,44 +958,44 @@ summary: 了解 2023 年 TiDB Cloud 的发布说明。 你可通过以下方式请求支持： - - 在项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页，点击集群行的 **...** 并选择 **Get Support**。 + - 在项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击集群行的 **...** 并选择 **Get Support**。 - 在集群概览页右上角点击 **...** 并选择 **Get Support**。 ## 2023 年 1 月 5 日 **控制台变更** -- [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 将 SQL Editor（Beta）重命名为 Chat2Query（Beta），并支持 AI 生成 SQL 查询。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群将 SQL Editor（beta）重命名为 Chat2Query（beta），并支持 AI 生成 SQL 查询。 - 在 Chat2Query 中，你可以让 AI 自动生成 SQL 查询，也可手动编写 SQL 并直接运行，无需终端。 + 在 Chat2Query 中，你可让 AI 自动生成 SQL 查询，也可手动编写 SQL，并直接在数据库上运行，无需终端。 - 访问方法：在项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页点击集群名，再点击左侧导航栏的 **Chat2Query**。 + 访问方法：在项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面点击集群名，再点击左侧导航栏的 **Chat2Query**。 ## 2023 年 1 月 4 日 **通用变更** -- 支持通过增加 **Node Size(vCPU + RAM)** 扩容 AWS 上（2022 年 12 月 31 日后创建）的 TiDB Cloud Dedicated 集群的 TiDB、TiKV、TiFlash 节点。 +- 支持通过增加 **Node Size(vCPU + RAM)** 扩容 AWS 托管的 TiDB Cloud Dedicated 集群的 TiDB、TiKV、TiFlash 节点（2022 年 12 月 31 日后创建）。 你可通过 [TiDB Cloud 控制台](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram) 或 [TiDB Cloud API (beta)](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) 增加节点规格。 - [**Monitoring**](/tidb-cloud/built-in-monitoring.md) 页的指标保留期延长至两天。 - 你现在可访问近两天的指标数据，更灵活地监控集群性能和趋势。 + 你现在可访问近两天的指标数据，更灵活地分析集群性能和趋势。 - 该提升无需额外费用，可在集群 [**Monitoring**](/tidb-cloud/built-in-monitoring.md) 页的 **Diagnosis** 标签访问，有助于更高效地排查性能问题和监控集群健康。 + 该提升无需额外费用，可在集群 [**Monitoring**](/tidb-cloud/built-in-monitoring.md) 页的 **Diagnosis** 标签访问，有助于更高效地定位和监控集群健康。 - 支持为 Prometheus 集成自定义 Grafana dashboard JSON。 - 已集成 Prometheus 的用户可导入预置 Grafana dashboard 并自定义，便于快速监控 TiDB Cloud 集群，及时发现性能问题。 + 已 [集成 Prometheus](/tidb-cloud/monitor-prometheus-and-grafana-integration.md) 的用户可导入预置 Grafana dashboard 并自定义，便于快速监控集群并及时发现性能问题。 详细信息参见 [使用 Grafana GUI dashboard 可视化指标](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#step-3-use-grafana-gui-dashboards-to-visualize-the-metrics)。 -- 所有 [Serverless 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的默认 TiDB 版本由 [v6.3.0](https://docs.pingcap.com/tidb/v6.3/release-6.3.0) 升级至 [v6.4.0](https://docs.pingcap.com/tidb/v6.4/release-6.4.0)。Serverless 集群升级至 v6.4.0 后的冷启动问题已修复。 +- 所有 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter) 集群的默认 TiDB 版本由 [v6.3.0](https://docs.pingcap.com/tidb/v6.3/release-6.3.0) 升级至 [v6.4.0](https://docs.pingcap.com/tidb/v6.4/release-6.4.0)。升级后已解决 Serverless Tier 集群的冷启动问题。 **控制台变更** -- 简化 [**Clusters**](https://tidbcloud.com/project/clusters) 页和集群概览页展示。 +- 简化 [**Clusters**](https://tidbcloud.com/project/clusters) 页面和集群概览页展示。 - - 你可在 [**Clusters**](https://tidbcloud.com/project/clusters) 页点击集群名进入概览页并开始操作。 - - 从概览页移除 **Connection** 和 **Import** 面板。你可在右上角点击 **Connect** 获取连接信息，或在左侧导航栏点击 **Import** 导入数据。 \ No newline at end of file + - 你可在 [**Clusters**](https://tidbcloud.com/project/clusters) 页面点击集群名进入概览页并开始操作。 + - 从概览页移除 **Connection** 和 **Import** 面板。你可点击右上角 **Connect** 获取连接信息，点击左侧导航栏 **Import** 导入数据。 \ No newline at end of file diff --git a/tidb-cloud/release-notes-2024.md b/tidb-cloud/release-notes-2024.md index 95195070068ca..70364ea52fbcb 100644 --- a/tidb-cloud/release-notes-2024.md +++ b/tidb-cloud/release-notes-2024.md @@ -26,11 +26,11 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- 为部署在 AWS 上的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群引入灾备恢复组（beta）功能。 +- 为部署在 AWS 上的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群引入灾备恢复组功能（Beta）。 - 该功能允许你在 TiDB Cloud Dedicated 集群之间复制数据库，确保在区域性灾难发生时能够快速恢复。如果你拥有 Project Owner 角色，可以通过创建新的恢复组并将数据库分配到该组来启用此功能。通过使用恢复组复制数据库，你可以提升灾备能力，满足更严格的可用性 SLA，并实现更激进的恢复点目标（RPO）和恢复时间目标（RTO）。 + 该功能支持你在 TiDB Cloud Dedicated 集群之间复制数据库，确保在区域性灾难发生时能够快速恢复。如果你拥有 Project Owner 角色，可以通过创建新的恢复组并将数据库分配到该组来启用此功能。通过使用恢复组复制数据库，你可以提升灾备能力，满足更严格的可用性 SLA，并实现更激进的恢复点目标（RPO）和恢复时间目标（RTO）。 - 更多信息，参见 [快速开始使用恢复组](/tidb-cloud/recovery-group-get-started.md)。 + 更多信息，参见 [快速开始恢复组](/tidb-cloud/recovery-group-get-started.md)。 ## 2024 年 11 月 26 日 @@ -38,7 +38,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 - 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本从 [v7.5.4](https://docs.pingcap.com/tidb/v7.5/release-7.5.4) 升级到 [v8.1.1](https://docs.pingcap.com/tidb/stable/release-8.1.1)。 -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 针对以下场景的大数据写入成本最多降低 80%： +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 针对以下场景的大数据写入成本最多降低 80%： - 在 [autocommit 模式](/transaction-overview.md#autocommit)下执行大于 16 MiB 的写入操作时。 - 在 [乐观事务模型](/optimistic-transaction.md)下执行大于 16 MiB 的写入操作时。 @@ -50,13 +50,13 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Serverless 分支（beta）](/tidb-cloud/branch-overview.md)为分支管理引入以下改进： +- [TiDB Cloud Serverless 分支（Beta）](/tidb-cloud/branch-overview.md)为分支管理带来以下改进： - **灵活的分支创建**：创建分支时，你可以选择特定集群或分支作为父级，并指定父级的精确时间点，从而精确控制分支中的数据。 - - **分支重置**：你可以将分支重置为与其父级的最新状态同步。 + - **分支重置**：你可以重置分支，使其与父级的最新状态同步。 - - **改进的 GitHub 集成**： [TiDB Cloud Branching](https://github.com/apps/tidb-cloud-branching) GitHub 应用引入了 [`branch.mode`](/tidb-cloud/branch-github-integration.md#branchmode) 参数，用于控制拉取请求同步时的行为。在默认的 `reset` 模式下，应用会将分支重置为与拉取请求中的最新更改保持一致。 + - **改进的 GitHub 集成**： [TiDB Cloud Branching](https://github.com/apps/tidb-cloud-branching) GitHub 应用引入了 [`branch.mode`](/tidb-cloud/branch-github-integration.md#branchmode) 参数，用于控制拉取请求同步时的行为。默认模式 `reset` 下，应用会将分支重置为与拉取请求中的最新更改保持一致。 更多信息，参见 [管理 TiDB Cloud Serverless 分支](/tidb-cloud/branch-manage.md) 和 [将 TiDB Cloud Serverless 分支（Beta）集成到 GitHub](/tidb-cloud/branch-github-integration.md)。 @@ -68,15 +68,15 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 TiDB Cloud Dedicated 现在将最大暂停时长限制为 7 天。如果你未在 7 天内手动恢复集群，TiDB Cloud 将自动恢复该集群。 - 此变更仅适用于 **2024 年 11 月 12 日后创建的组织**。2024 年 11 月 12 日及之前创建的组织将在提前通知后逐步过渡到新的暂停行为。 + 此变更仅适用于 **2024 年 11 月 12 日后创建的组织**。2024 年 11 月 12 日及之前创建的组织将会提前通知后逐步切换到新的暂停行为。 更多信息，参见 [暂停或恢复 TiDB Cloud Dedicated 集群](/tidb-cloud/pause-or-resume-tidb-cluster.md)。 -- [Datadog 集成（beta）](/tidb-cloud/monitor-datadog-integration.md) 新增对 `AP1`（日本）区域的支持。 +- [Datadog 集成（Beta）](/tidb-cloud/monitor-datadog-integration.md) 新增对 `AP1`（日本）区域的支持。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群新增支持 AWS 区域：`Mumbai (ap-south-1)`。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群移除对 AWS `São Paulo (sa-east-1)` 区域的支持。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群移除对 AWS 区域 `São Paulo (sa-east-1)` 的支持。 ## 2024 年 10 月 29 日 @@ -84,7 +84,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 - 新增指标：为 Prometheus 集成添加 `tidbcloud_changefeed_checkpoint_ts`。 - 该指标用于跟踪 changefeed 的检查点时间戳，表示已成功写入下游的最大 TSO（时间戳 Oracle）。更多可用指标信息，参见 [将 TiDB Cloud 集成到 Prometheus 和 Grafana（Beta）](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#metrics-available-to-prometheus)。 + 该指标用于追踪 changefeed 的检查点时间戳，表示已成功写入下游的最大 TSO（Timestamp Oracle）。更多可用指标信息，参见 [将 TiDB Cloud 集成到 Prometheus 和 Grafana（Beta）](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#metrics-available-to-prometheus)。 ## 2024 年 10 月 22 日 @@ -96,7 +96,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **API 变更** -* [MSP](https://docs.pingcap.com/tidbcloud/api/v1beta1/msp) 自 2024 年 10 月 15 日起弃用，未来将被移除。如果你当前在使用 MSP API，请迁移到 [TiDB Cloud Partner](https://partner-console.tidbcloud.com/signin) 中的 Partner Management API。 +* [MSP](https://docs.pingcap.com/tidbcloud/api/v1beta1/msp) 自 2024 年 10 月 15 日起弃用，未来将被移除。如果你当前正在使用 MSP API，请迁移到 [TiDB Cloud Partner](https://partner-console.tidbcloud.com/signin) 中的 Partner Management API。 ## 2024 年 9 月 24 日 @@ -110,10 +110,10 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 TiDB Cloud CLI 提供以下新特性： - - 支持通过 [`ticloud serverless sql-user`](/tidb-cloud/ticloud-serverless-sql-user-create.md) 管理 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的 SQL 用户。 - - 允许在 [`ticloud serverless create`](/tidb-cloud/ticloud-cluster-create.md) 和 [`ticloud serverless update`](/tidb-cloud/ticloud-serverless-update.md) 中禁用 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的公网访问端点。 + - 支持通过 [`ticloud serverless sql-user`](/tidb-cloud/ticloud-serverless-sql-user-create.md) 管理 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群的 SQL 用户。 + - 允许在 [`ticloud serverless create`](/tidb-cloud/ticloud-cluster-create.md) 和 [`ticloud serverless update`](/tidb-cloud/ticloud-serverless-update.md) 中禁用 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群的公共端点。 - 新增 [`ticloud auth whoami`](/tidb-cloud/ticloud-auth-whoami.md) 命令，在使用 OAuth 认证时获取当前用户信息。 - - 在 [`ticloud serverless export create`](/tidb-cloud/ticloud-serverless-export-create.md) 中支持 `--sql`、`--where` 和 `--filter` 参数，灵活选择源表。 + - 在 [`ticloud serverless export create`](/tidb-cloud/ticloud-serverless-export-create.md) 中支持 `--sql`、`--where` 和 `--filter` 标志，灵活选择源表。 - 支持将数据导出为 CSV 和 Parquet 文件。 - 支持使用角色 ARN 作为凭证将数据导出到 Amazon S3，同时支持导出到 Google Cloud Storage 和 Azure Blob Storage。 - 支持从 Amazon S3、Google Cloud Storage 和 Azure Blob Storage 导入数据。 @@ -126,15 +126,15 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 TiDB Cloud CLI 替换或移除了以下功能： - - [`ticloud serverless export create`](/tidb-cloud/ticloud-serverless-export-create.md) 中的 `--s3.bucket-uri` 参数被 `--s3.uri` 替代。 - - [`ticloud serverless export create`](/tidb-cloud/ticloud-serverless-export-create.md) 中移除了 `--database` 和 `--table` 参数。你可以使用 `--sql`、`--where` 和 `--filter` 参数替代。 + - 在 [`ticloud serverless export create`](/tidb-cloud/ticloud-serverless-export-create.md) 中，`--s3.bucket-uri` 标志被 `--s3.uri` 替代。 + - 在 [`ticloud serverless export create`](/tidb-cloud/ticloud-serverless-export-create.md) 中，移除了 `--database` 和 `--table` 标志。你可以使用 `--sql`、`--where` 和 `--filter` 标志替代。 - [`ticloud serverless update`](/tidb-cloud/ticloud-serverless-update.md) 不再支持更新 annotations 字段。 ## 2024 年 9 月 10 日 **通用变更** -- 启动 TiDB Cloud Partner Web 控制台和 Open API，提升 TiDB Cloud 合作伙伴的资源与账单管理能力。 +- 上线 TiDB Cloud Partner Web 控制台和 Open API，提升 TiDB Cloud 合作伙伴的资源与账单管理能力。 通过 AWS Marketplace Channel Partner Private Offer（CPPO）的托管服务提供商（MSP）和经销商现在可以利用 [TiDB Cloud Partner Web 控制台](https://partner-console.tidbcloud.com/) 和 Open API 简化日常运营。 @@ -152,13 +152,13 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 - 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的连接体验。 - - 优化 **Connect** 对话框界面，为 TiDB Cloud Dedicated 用户提供更简洁高效的连接体验。 + - 优化 **Connect** 对话框界面，为 TiDB Cloud Dedicated 用户提供更流畅高效的连接体验。 - 新增集群级 **Networking** 页面，简化集群的网络配置。 - 用新的 **Password Settings** 页面替换 **Security Settings** 页面，并将 IP 访问列表设置迁移到新的 **Networking** 页面。 更多信息，参见 [连接到 TiDB Cloud Dedicated](/tidb-cloud/connect-to-tidb-cluster.md)。 -- 优化 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的数据导入体验： +- 优化 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的数据导入体验： - 优化 **Import** 页面的布局，使其更清晰。 - 统一 TiDB Cloud Serverless 和 TiDB Cloud Dedicated 集群的导入步骤。 @@ -170,7 +170,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **控制台变更** -- 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中新建私有端点连接页面的布局，提升创建新私有端点连接的用户体验。 +- 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中新建私有端点连接页面的布局，提升创建私有端点连接的用户体验。 更多信息，参见 [通过 AWS 私有端点连接到 TiDB Cloud Dedicated 集群](/tidb-cloud/set-up-private-endpoint-connections.md) 和 [通过 Google Cloud Private Service Connect 连接到 TiDB Cloud Dedicated 集群](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)。 @@ -180,7 +180,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 在 AWS 上的负载均衡计费变更。 - 自 2024 年 8 月 1 日起，TiDB Cloud Dedicated 账单将包含 AWS 公网 IPv4 地址的新费用，与 [AWS 自 2024 年 2 月 1 日起生效的定价变更](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/) 保持一致。每个公网 IPv4 地址的费用为 $0.005/小时，每个托管在 AWS 上的 TiDB Cloud Dedicated 集群每月约 $10。 + 自 2024 年 8 月 1 日起，TiDB Cloud Dedicated 账单将包含新的 AWS 公共 IPv4 地址费用，与 [AWS 2024 年 2 月 1 日起生效的定价变更](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/) 保持一致。每个公共 IPv4 地址的费用为 $0.005/小时，每个托管在 AWS 上的 TiDB Cloud Dedicated 集群每月约 $10。 该费用将显示在 [账单明细](/tidb-cloud/tidb-cloud-billing.md#billing-details) 的 **TiDB Cloud Dedicated - Data Transfer - Load Balancing** 服务下。 @@ -196,17 +196,17 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- [数据服务（beta）](https://tidbcloud.com/project/data-service) 支持自动生成向量检索端点。 +- [数据服务（Beta）](https://tidbcloud.com/project/data-service) 支持自动生成向量检索端点。 - 如果你的表包含 [向量数据类型](/vector-search/vector-search-data-types.md)，你可以自动生成一个向量检索端点，并根据所选距离函数计算向量距离。 + 如果你的表包含 [向量数据类型](/vector-search/vector-search-data-types.md)，你可以自动生成一个向量检索端点，根据所选距离函数计算向量距离。 - 该功能可无缝集成到 [Dify](https://docs.dify.ai/guides/tools) 和 [GPTs](https://openai.com/blog/introducing-gpts) 等 AI 平台，为你的应用带来先进的自然语言处理和 AI 能力，助力更复杂的任务和智能解决方案。 + 该功能可无缝集成到 [Dify](https://docs.dify.ai/guides/tools) 和 [GPTs](https://openai.com/blog/introducing-gpts) 等 AI 平台，为你的应用带来更复杂的自然语言处理和 AI 能力，助力智能解决方案。 更多信息，参见 [自动生成端点](/tidb-cloud/data-service-manage-endpoint.md#generate-an-endpoint-automatically) 和 [将数据应用集成到第三方工具](/tidb-cloud/data-service-integrations.md)。 - 引入预算功能，帮助你跟踪实际 TiDB Cloud 成本与计划支出，防止意外费用。 - 你需要拥有组织的 `Organization Owner` 或 `Organization Billing Admin` 角色才能访问该功能。 + 你需要拥有 `Organization Owner` 或 `Organization Billing Admin` 角色才能访问该功能。 更多信息，参见 [管理 TiDB Cloud 预算](/tidb-cloud/tidb-cloud-budget.md)。 @@ -226,7 +226,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- [数据服务（beta）](https://tidbcloud.com/project/data-service) 提供端点库，内置预定义系统端点，可直接添加到你的数据应用中，减少端点开发工作量。 +- [数据服务（Beta）](https://tidbcloud.com/project/data-service) 提供端点库，内置预定义系统端点，可直接添加到你的数据应用，减少端点开发工作量。 当前库中仅包含 `/system/query` 端点，你只需在预定义的 `sql` 参数中传入 SQL 语句，即可执行任意 SQL 查询。该端点便于即时执行 SQL 查询，提升灵活性和效率。 @@ -240,35 +240,35 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 支持向量检索（beta）。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 支持向量检索（Beta）。 - 向量检索（beta）功能为多种数据类型（如文档、图片、音频和视频）提供语义相似性检索的高级解决方案。该功能让开发者可用熟悉的 MySQL 技能轻松构建具备生成式人工智能（AI）能力的可扩展应用。主要特性包括： + 向量检索（Beta）功能为文档、图片、音频和视频等多种数据类型提供语义相似性检索的高级解决方案。该功能让开发者可以用熟悉的 MySQL 技能，轻松构建具备生成式人工智能（AI）能力的可扩展应用。主要特性包括： - - [向量数据类型](/vector-search/vector-search-data-types.md)、[向量索引](/vector-search/vector-search-index.md) 及 [向量函数与操作符](/vector-search/vector-search-functions-and-operators.md)。 + - [向量数据类型](/vector-search/vector-search-data-types.md)、[向量索引](/vector-search/vector-search-index.md) 以及 [向量函数与操作符](/vector-search/vector-search-functions-and-operators.md)。 - 与 [LangChain](/vector-search/vector-search-integrate-with-langchain.md)、[LlamaIndex](/vector-search/vector-search-integrate-with-llamaindex.md) 和 [JinaAI](/vector-search/vector-search-integrate-with-jinaai-embedding.md) 的生态集成。 - Python 语言支持：[SQLAlchemy](/vector-search/vector-search-integrate-with-sqlalchemy.md)、[Peewee](/vector-search/vector-search-integrate-with-peewee.md) 和 [Django ORM](/vector-search/vector-search-integrate-with-django-orm.md)。 - 示例应用与教程：使用 [Python](/vector-search/vector-search-get-started-using-python.md) 或 [SQL](/vector-search/vector-search-get-started-using-sql.md) 进行文档语义检索。 - 更多信息，参见 [向量检索（beta）概览](/vector-search/vector-search-overview.md)。 + 更多信息，参见 [向量检索（Beta）概览](/vector-search/vector-search-overview.md)。 -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 现为组织所有者提供每周邮件报告。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 现为组织所有者提供每周邮件报告。 - 这些报告可洞察集群的性能和活动。通过自动每周更新，你可以及时了解集群状况，并据此做出数据驱动的优化决策。 + 这些报告可帮助你了解集群的性能和活动。通过自动每周更新，你可以及时掌握集群动态，做出数据驱动的优化决策。 - 发布 Chat2Query API v3 端点，并弃用 Chat2Query API v1 端点 `/v1/chat2data`。 通过 Chat2Query API v3 端点，你可以基于会话开启多轮 Chat2Query。 - 更多信息，参见 [快速开始使用 Chat2Query API](/tidb-cloud/use-chat2query-api.md)。 + 更多信息，参见 [快速开始 Chat2Query API](/tidb-cloud/use-chat2query-api.md)。 **控制台变更** -- 将 Chat2Query（beta）重命名为 SQL Editor（beta）。 +- 将 Chat2Query（Beta）重命名为 SQL Editor（Beta）。 - 原 Chat2Query 界面现更名为 SQL Editor。此更名明确区分了手动 SQL 编辑与 AI 辅助查询生成，提升了可用性和整体体验。 + 原 Chat2Query 界面现更名为 SQL Editor。此变更明确区分了手动 SQL 编辑与 AI 辅助查询生成，提升了可用性和整体体验。 - **SQL Editor**：TiDB Cloud 控制台中用于手动编写和执行 SQL 查询的默认界面。 - - **Chat2Query**：AI 辅助的文本转查询功能，允许你用自然语言与数据库交互，生成、重写和优化 SQL 查询。 + - **Chat2Query**：AI 辅助的文本转查询功能，支持你用自然语言与数据库交互，生成、重写和优化 SQL 查询。 更多信息，参见 [使用 AI 辅助 SQL Editor 探索数据](/tidb-cloud/explore-data-with-chat2query.md)。 @@ -276,9 +276,9 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 16 vCPU TiFlash 和 32 vCPU TiFlash 节点最大存储从 2048 GiB 提升至 4096 GiB。 +- 将 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中 16 vCPU TiFlash 和 32 vCPU TiFlash 的最大节点存储从 2048 GiB 提升至 4096 GiB。 - 此增强提升了 TiDB Cloud Dedicated 集群的分析型数据存储能力，提高了工作负载扩展效率，并满足不断增长的数据需求。 + 此优化提升了 TiDB Cloud Dedicated 集群的分析型数据存储能力，提高了工作负载扩展效率，满足不断增长的数据需求。 更多信息，参见 [TiFlash 节点存储](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)。 @@ -288,19 +288,19 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- 为部署在 AWS 上的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群引入灾备恢复组（beta）功能。 +- 为部署在 AWS 上的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群引入灾备恢复组功能（Beta）。 - 该功能允许你在 TiDB Cloud Dedicated 集群之间复制数据库，确保在区域性灾难发生时能够快速恢复。如果你拥有 `Project Owner` 角色，可以通过创建新的恢复组并将数据库分配到该组来启用此功能。通过使用恢复组复制数据库，你可以提升灾备能力，满足更严格的可用性 SLA，并实现更激进的恢复点目标（RPO）和恢复时间目标（RTO）。 + 该功能支持你在 TiDB Cloud Dedicated 集群之间复制数据库，确保在区域性灾难发生时能够快速恢复。如果你拥有 `Project Owner` 角色，可以通过创建新的恢复组并将数据库分配到该组来启用此功能。通过使用恢复组复制数据库，你可以提升灾备能力，满足更严格的可用性 SLA，并实现更激进的恢复点目标（RPO）和恢复时间目标（RTO）。 - 更多信息，参见 [快速开始使用恢复组](/tidb-cloud/recovery-group-get-started.md)。 + 更多信息，参见 [快速开始恢复组](/tidb-cloud/recovery-group-get-started.md)。 -- 为 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 列式存储 [TiFlash](/tiflash/tiflash-overview.md) 引入计费与计量（beta）。 +- 为 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 列式存储 [TiFlash](/tiflash/tiflash-overview.md) 引入计费与计量（Beta）。 截至 2024 年 6 月 30 日，TiDB Cloud Serverless 集群的列式存储仍享受 100% 折扣免费。此日期后，每个 TiDB Cloud Serverless 集群将包含 5 GiB 列式存储免费额度，超出部分将按量计费。 更多信息，参见 [TiDB Cloud Serverless 价格详情](https://www.pingcap.com/tidb-serverless-pricing-details/#storage)。 -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 支持 [生存时间（TTL）](/time-to-live.md)。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 支持 [生存时间（TTL）](/time-to-live.md)。 ## 2024 年 5 月 28 日 @@ -314,13 +314,13 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **API 变更** -- 引入 TiDB Cloud Data Service API，实现以下资源的自动高效管理： +- 引入 TiDB Cloud Data Service API，自动高效地管理以下资源： - * **Data App**：一组端点的集合，可用于访问特定应用的数据。 + * **Data App**：一组端点的集合，你可以用来为特定应用访问数据。 * **Data Source**：与 Data App 关联的集群，用于数据操作与检索。 * **Endpoint**：可自定义执行 SQL 语句的 Web API。 * **Data API Key**：用于安全访问端点。 - * **OpenAPI 规范**：Data Service 支持为每个 Data App 生成 OpenAPI Specification 3.0，便于你以标准格式与端点交互。 + * **OpenAPI 规范**：Data Service 支持为每个 Data App 生成 OpenAPI Specification 3.0，便于你以标准化格式与端点交互。 这些 TiDB Cloud Data Service API 端点已在 TiDB Cloud API v1beta1 中发布，该版本为 TiDB Cloud 的最新 API 版本。 @@ -338,11 +338,11 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 - 扩展 [**Time Zone**](/tidb-cloud/manage-user-access.md#set-the-time-zone-for-your-organization) 区域的时区选择，更好地满足来自不同地区客户的需求。 -- 支持在你的 VPC 与 TiDB Cloud 的 VPC 不同区域时 [创建 VPC peering](/tidb-cloud/set-up-vpc-peering-connections.md)。 +- 支持在你的 VPC 与 TiDB Cloud 的 VPC 不同区域时 [创建 VPC Peering](/tidb-cloud/set-up-vpc-peering-connections.md)。 -- [数据服务（beta）](https://tidbcloud.com/project/data-service) 支持路径参数与查询参数。 +- [数据服务（Beta）](https://tidbcloud.com/project/data-service) 支持路径参数与查询参数。 - 该功能通过结构化 URL 增强资源标识，提升用户体验、搜索引擎优化（SEO）和客户端集成，为开发者提供更大灵活性，更好地契合行业标准。 + 该功能通过结构化 URL 增强资源标识，提升用户体验、搜索引擎优化（SEO）和客户端集成，为开发者带来更高的灵活性和更好地契合行业标准。 更多信息，参见 [基本属性](/tidb-cloud/data-service-manage-endpoint.md#basic-properties)。 @@ -354,8 +354,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 - [从 TiDB Cloud Serverless 集群导出数据](/tidb-cloud/serverless-export.md) - [从本地存储导入数据到 TiDB Cloud Serverless 集群](/tidb-cloud/ticloud-import-start.md) - - [通过 OAuth 认证](/tidb-cloud/ticloud-auth-login.md) - - [通过 TiDB Bot 提问](/tidb-cloud/ticloud-ai.md) + - [支持 OAuth 认证](/tidb-cloud/ticloud-auth-login.md) 升级 TiDB Cloud CLI 前，请注意新 CLI 与旧版本不兼容。例如，CLI 命令中的 `ticloud cluster` 现已更新为 `ticloud serverless`。更多信息，参见 [TiDB Cloud CLI 参考](/tidb-cloud/cli-reference.md)。 @@ -369,13 +368,13 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- 为 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群引入两种服务计划：**Free** 和 **Scalable**。 +- 为 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群引入两种服务计划：**Free** 和 **Scalable**。 为满足不同用户需求，TiDB Cloud Serverless 提供免费和可扩展服务计划。无论你是刚刚起步还是需要应对不断增长的应用需求，这些计划都能为你提供所需的灵活性和能力。 - 更多信息，参见 [集群计划](/tidb-cloud/select-cluster-tier.md#cluster-plans)。 + 更多信息，参见 [集群计划](/tidb-cloud/select-cluster-tier.md)。 -- 修改 TiDB Cloud Serverless 集群达到使用配额后的限流行为。现在，一旦集群达到使用配额，将立即拒绝所有新连接请求，从而确保现有操作的服务不中断。 +- 修改 TiDB Cloud Serverless 集群达到使用配额后的限流行为。现在，一旦集群达到使用配额，将立即拒绝所有新连接请求，从而确保现有操作不中断。 更多信息，参见 [使用配额](/tidb-cloud/serverless-limitations.md#usage-quota)。 @@ -405,7 +404,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 **通用变更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的 TiDB 版本从 [v6.6.0](https://docs.pingcap.com/tidb/v6.6/release-6.6.0) 升级到 [v7.1.3](https://docs.pingcap.com/tidb/v7.1/release-7.1.3)。 +- 将 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群的 TiDB 版本从 [v6.6.0](https://docs.pingcap.com/tidb/v6.6/release-6.6.0) 升级到 [v7.1.3](https://docs.pingcap.com/tidb/v7.1/release-7.1.3)。 ## 2024 年 2 月 20 日 @@ -414,7 +413,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 - 支持在 Google Cloud 上创建更多 TiDB Cloud 节点。 - 通过为 Google Cloud [配置区域 CIDR 大小](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)为 `/19`，你现在可以在项目的任意区域内创建最多 124 个 TiDB Cloud 节点。 - - 如果你希望在项目的任意区域内创建超过 124 个节点，可联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md) 协助自定义 IP 范围大小（/16 到 /18）。 + - 如果你希望在项目的任意区域内创建超过 124 个节点，可以联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md) 协助自定义 `/16` 到 `/18` 的 IP 范围大小。 ## 2024 年 1 月 23 日 @@ -442,13 +441,13 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 更多信息，参见 [为区域设置 CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)。 -- TiDB Cloud Serverless 用户现在可以为集群禁用公网访问端点。 +- TiDB Cloud Serverless 用户现在可以为集群禁用公共端点。 - 更多信息，参见 [禁用公网访问端点](/tidb-cloud/connect-via-standard-connection-serverless.md#disable-a-public-endpoint)。 + 更多信息，参见 [禁用公共端点](/tidb-cloud/connect-via-standard-connection-serverless.md#disable-a-public-endpoint)。 -- [数据服务（beta）](https://tidbcloud.com/project/data-service) 支持为 Data App 配置自定义域名访问端点。 +- [数据服务（Beta）](https://tidbcloud.com/project/data-service) 支持为 Data App 配置自定义域名访问端点。 - 默认情况下，TiDB Cloud Data Service 提供 `.data.tidbcloud.com` 域名访问每个 Data App 的端点。为提升个性化和灵活性，你现在可以为 Data App 配置自定义域名，替代默认域名。该功能支持为数据库服务使用品牌化 URL，并提升安全性。 + 默认情况下，TiDB Cloud Data Service 为每个 Data App 的端点提供 `.data.tidbcloud.com` 域名。为提升个性化和灵活性，你现在可以为 Data App 配置自定义域名，替代默认域名。该功能支持你为数据库服务使用品牌化 URL，并提升安全性。 更多信息，参见 [数据服务中的自定义域名](/tidb-cloud/data-service-custom-domain.md)。 @@ -458,7 +457,7 @@ summary: 了解 2024 年 TiDB Cloud 的发布说明。 - 支持 [组织 SSO](https://tidbcloud.com/org-settings/authentication)，简化企业认证流程。 - 通过该功能，你可以使用 [安全断言标记语言（SAML）](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language) 或 [OpenID Connect（OIDC）](https://openid.net/developers/how-connect-works/) 无缝集成 TiDB Cloud 与任意身份提供商（IdP）。 + 通过该功能，你可以将 TiDB Cloud 与任意身份提供商（IdP）无缝集成，支持 [安全断言标记语言（SAML）](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language) 或 [OpenID Connect（OIDC）](https://openid.net/developers/how-connect-works/)。 更多信息，参见 [组织 SSO 认证](/tidb-cloud/tidb-cloud-org-sso-authentication.md)。 diff --git a/tidb-cloud/scalability-concepts.md b/tidb-cloud/scalability-concepts.md index 8d75c7cafd926..daa82f2924abd 100644 --- a/tidb-cloud/scalability-concepts.md +++ b/tidb-cloud/scalability-concepts.md @@ -1,15 +1,15 @@ --- title: Scalability -summary: 了解 TiDB Cloud 的可扩展性相关概念。 +summary: 了解 TiDB Cloud 的可扩展性概念。 --- # 可扩展性 -TiDB Cloud Dedicated 允许你分别调整其计算和存储资源，以适应数据量或工作负载的变化。TiDB Cloud Dedicated 可以在不中断服务的情况下进行扩容或缩容。这种灵活性使组织能够在保持高性能和高可用性的同时，优化基础设施成本。 +TiDB Cloud 提供多种部署选项，具备灵活的可扩展性，以满足不同工作负载的需求。 -> **Note:** -> -> [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 会根据你的应用工作负载变化自动扩缩容。但你无法手动扩缩 TiDB Cloud Serverless 集群。 +- [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 非常适合原型开发、开发环境和早期阶段的工作负载。它为你提供了一种简化且具性价比的方式来快速开始使用 TiDB Cloud，并内置了自动扩缩容功能。 +- [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 适用于需要更强可扩展性和在流量或数据量增长时依然保持可预测性能的生产级工作负载。 +- TiDB Cloud Dedicated 允许你分别调整计算和存储资源，以适应数据量或工作负载的变化。TiDB Cloud Dedicated 可以在不中断服务的情况下进行扩缩容。这种灵活性使组织能够在保持高性能和高可用性的同时，优化基础设施成本。 > **Tip:** > @@ -19,8 +19,8 @@ TiDB Cloud Dedicated 允许你分别调整其计算和存储资源，以适应 TiDB Cloud Dedicated 支持垂直扩展（scale up）和水平扩展（scale out）。 -- 水平扩展是指向你的专属集群中添加节点，以分担工作负载的过程。 -- 垂直扩展是指为你的专属集群增加 vCPU 和内存的过程。 +- 水平扩展是指向你的专用集群中添加节点，以分担工作负载。 +- 垂直扩展是指增加专用集群的 vCPU 和内存（RAM）。 TiDB Cloud Dedicated 也支持垂直扩展和水平扩展的组合。 @@ -32,12 +32,12 @@ TiDB 仅负责计算，不存储数据。你可以为 TiDB 配置节点数量、 ## TiKV 的可扩展性 -TiKV 负责存储行存数据。你可以为 TiKV 配置节点数量、vCPU、内存和存储空间。TiKV 节点数量至少为 1 组（即 3 个节点，分布在 3 个不同的可用区），并以 3 个节点为单位增加。 +TiKV 负责存储行存数据。你可以为 TiKV 配置节点数量、vCPU、内存和存储。TiKV 节点数量至少为 1 组（即 3 个节点，分布在 3 个不同的可用区），并以 3 个节点为单位进行扩展。 TiDB Cloud 会将 TiKV 节点均匀部署在你选择的区域内的 3 个可用区，以实现数据的持久性和高可用性。在典型的 3 副本部署中，你的数据会在所有可用区的 TiKV 节点之间均匀分布，并持久化到每个 TiKV 节点的磁盘上。虽然 TiKV 主要用于数据存储，但 TiKV 节点的性能也会根据不同的工作负载有所变化。 ## TiFlash 的可扩展性 -TiFlash 负责存储列存数据。TiFlash 会实时从 TiKV 同步数据，并原生支持实时分析型工作负载。你可以为 TiFlash 配置节点数量、vCPU、内存和存储空间。 +TiFlash 负责存储列存数据。TiFlash 会实时从 TiKV 同步数据，并原生支持实时分析型工作负载。你可以为 TiFlash 配置节点数量、vCPU、内存和存储。 TiDB Cloud 会将 TiFlash 节点均匀部署在一个区域内的不同可用区。建议你在每个 TiDB Cloud 集群中至少配置两个 TiFlash 节点，并为生产环境中的数据创建至少两个副本，以实现高可用性。 \ No newline at end of file diff --git a/tidb-cloud/scale-tidb-cluster.md b/tidb-cloud/scale-tidb-cluster.md index 1b9c685385b5a..95d7bf27c040c 100644 --- a/tidb-cloud/scale-tidb-cluster.md +++ b/tidb-cloud/scale-tidb-cluster.md @@ -7,7 +7,7 @@ summary: 了解如何扩容你的 TiDB Cloud 集群。 > **Note:** > -> - [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 会根据你的应用负载变化自动扩缩容。但你无法手动扩容 TiDB Cloud Serverless 集群。 +> - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 会根据你的应用负载变化自动扩缩容。但你无法手动扩容 TiDB Cloud Starter 或 TiDB Cloud Essential 集群。 > - 当集群处于 **MODIFYING** 状态时，你无法对其执行任何新的扩容操作。 你可以从以下维度扩容 TiDB 集群： @@ -16,11 +16,11 @@ summary: 了解如何扩容你的 TiDB Cloud 集群。 - TiDB、TiKV 和 TiFlash 的 vCPU 及内存（RAM） - TiKV 和 TiFlash 的存储 -关于如何确定 TiDB 集群的规格，请参见 [确定你的 TiDB 集群规格](/tidb-cloud/size-your-cluster.md)。 +关于如何确定你的 TiDB 集群规格，请参见 [确定你的 TiDB 集群规格](/tidb-cloud/size-your-cluster.md)。 > **Note:** > -> 如果 TiDB 或 TiKV 的 vCPU 和内存规格设置为 **4 vCPU, 16 GiB**，请注意以下限制。要绕过这些限制，你可以先[提升 vCPU 和内存](#change-vcpu-and-ram)。 +> 如果 TiDB 或 TiKV 的 vCPU 和内存规格设置为 **4 vCPU, 16 GiB**，请注意以下限制。要绕过这些限制，你可以先[调整 vCPU 和内存](#change-vcpu-and-ram)。 > > - TiDB 的节点数量只能设置为 1 或 2，TiKV 的节点数量固定为 3。 > - 4 vCPU 的 TiDB 只能与 4 vCPU 的 TiKV 搭配使用，4 vCPU 的 TiKV 也只能与 4 vCPU 的 TiDB 搭配使用。 @@ -44,7 +44,7 @@ summary: 了解如何扩容你的 TiDB Cloud 集群。 > 你也可以在 **Clusters** 页面点击你想要扩容的集群名称，然后在右上角点击 **...**。 3. 在下拉菜单中点击 **Modify**，进入 **Modify Cluster** 页面。 -4. 在 **Modify Cluster** 页面，更改 TiDB、TiKV 或 TiFlash 的节点数量。 +4. 在 **Modify Cluster** 页面，修改 TiDB、TiKV 或 TiFlash 的节点数量。 5. 在右侧面板确认集群规格，然后点击 **Confirm**。 你也可以通过 TiDB Cloud API，使用 [Modify a TiDB Cloud Dedicated cluster](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) 接口更改 TiDB、TiKV 或 TiFlash 的节点数量。目前，TiDB Cloud API 仍处于 beta 阶段。更多信息请参见 [TiDB Cloud API Documentation](https://docs.pingcap.com/tidbcloud/api/v1beta)。 @@ -55,11 +55,11 @@ summary: 了解如何扩容你的 TiDB Cloud 集群。 > **Note:** > -> - 更改 vCPU 和内存仅适用于以下集群： -> - 部署在 AWS 上且创建时间为 2022/12/31 之后。 -> - 部署在 Google Cloud 上且创建时间为 2023/04/26 之后。 -> - 部署在 Azure 上。 -> - AWS 对 vCPU 和内存的更改有冷却期。如果你的 TiDB 集群部署在 AWS 上，在更改 TiKV 或 TiFlash 的 vCPU 和内存后，必须等待至少 6 小时才能再次更改。 +> - 仅以下集群支持更改 vCPU 和内存： +> - 部署在 AWS 且创建时间为 2022/12/31 之后的集群。 +> - 部署在 Google Cloud 且创建时间为 2023/04/26 之后的集群。 +> - 部署在 Azure 上的集群。 +> - AWS 对 vCPU 和内存的更改有冷却时间。如果你的 TiDB 集群部署在 AWS 上，在更改 TiKV 或 TiFlash 的 vCPU 和内存后，必须等待至少 6 小时才能再次更改。 > - 在减少 vCPU 之前，请确保 TiKV 或 TiFlash 当前节点的存储不超过目标 vCPU 的最大节点存储。详情请参见 [TiKV 节点存储](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size) 和 [TiFlash 节点存储](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)。如果任一组件当前存储超过其限制，则无法减少 vCPU。 要更改 TiDB、TiKV 或 TiFlash 节点的 vCPU 和内存，请按照以下步骤操作： @@ -72,7 +72,7 @@ summary: 了解如何扩容你的 TiDB Cloud 集群。 > 你也可以在 **Clusters** 页面点击你想要扩容的集群名称，然后在右上角点击 **...**。 3. 在下拉菜单中点击 **Modify**，进入 **Modify Cluster** 页面。 -4. 在 **Modify Cluster** 页面，更改 TiDB、TiKV 或 TiFlash 节点的 vCPU 和内存。 +4. 在 **Modify Cluster** 页面，修改 TiDB、TiKV 或 TiFlash 节点的 vCPU 和内存。 5. 在右侧面板确认集群规格，然后点击 **Confirm**。 你也可以通过 TiDB Cloud API，使用 [Modify a TiDB Cloud Dedicated cluster](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) 接口更改 TiDB、TiKV 或 TiFlash 节点的 vCPU 和内存。目前，TiDB Cloud API 仍处于 beta 阶段。更多信息请参见 [TiDB Cloud API Documentation](https://docs.pingcap.com/tidbcloud/api/v1beta)。 @@ -84,7 +84,7 @@ summary: 了解如何扩容你的 TiDB Cloud 集群。 > **Warning:** > > - 对于运行中的集群，AWS、Azure 和 Google Cloud 不支持原地降低存储容量。 -> - AWS 和 Azure 对存储更改有冷却期。如果你的 TiDB 集群部署在 AWS 或 Azure 上，在更改 TiKV 或 TiFlash 的存储或 vCPU 和内存后，必须等待至少 6 小时才能再次更改。 +> - AWS 和 Azure 对存储更改有冷却时间。如果你的 TiDB 集群部署在 AWS 或 Azure 上，在更改 TiKV 或 TiFlash 的存储或 vCPU 和内存后，必须等待至少 6 小时才能再次更改。 要更改 TiKV 或 TiFlash 的存储，请按照以下步骤操作： @@ -96,7 +96,7 @@ summary: 了解如何扩容你的 TiDB Cloud 集群。 > 你也可以在 **Clusters** 页面点击你想要扩容的集群名称，然后在右上角点击 **...**。 3. 在下拉菜单中点击 **Modify**，进入 **Modify Cluster** 页面。 -4. 在 **Modify Cluster** 页面，更改每个 TiKV 或 TiFlash 节点的存储。 +4. 在 **Modify Cluster** 页面，修改每个 TiKV 或 TiFlash 节点的存储。 5. 在右侧面板确认集群规格，然后点击 **Confirm**。 你也可以通过 TiDB Cloud API，使用 [Modify a TiDB Cloud Dedicated cluster](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) 接口更改 TiKV 或 TiFlash 节点的存储。目前，TiDB Cloud API 仍处于 beta 阶段。更多信息请参见 [TiDB Cloud API Documentation](https://docs.pingcap.com/tidbcloud/api/v1beta)。 \ No newline at end of file diff --git a/tidb-cloud/select-cluster-tier.md b/tidb-cloud/select-cluster-tier.md index 2e1c2c47490ed..b1c6cef6bfb87 100644 --- a/tidb-cloud/select-cluster-tier.md +++ b/tidb-cloud/select-cluster-tier.md @@ -8,9 +8,9 @@ aliases: ['/tidbcloud/developer-tier-cluster'] 集群方案决定了你的集群的吞吐量和性能。 -TiDB Cloud 提供以下几种集群方案选项。无论你是刚刚开始使用，还是需要扩展以满足不断增长的应用需求，这些服务方案都能为你提供所需的灵活性和能力。在创建集群之前，你需要考虑哪种选项更适合你的需求。 +TiDB Cloud 提供了以下几种集群方案选项。无论你是刚刚开始使用，还是需要扩展以满足不断增长的应用需求，这些服务方案都能为你提供所需的灵活性和能力。在创建集群之前，你需要考虑哪种选项更适合你的需求。 -- [TiDB Cloud Serverless](#tidb-cloud-serverless)（现称 Starter） +- [TiDB Cloud Starter](#starter) - [TiDB Cloud Essential](#essential) - [TiDB Cloud Dedicated](#tidb-cloud-dedicated) @@ -18,44 +18,44 @@ TiDB Cloud 提供以下几种集群方案选项。无论你是刚刚开始使用 > > 部分 TiDB Cloud 功能在 TiDB Cloud Starter 和 TiDB Cloud Essential 上仅部分支持或不支持。详情请参见 [TiDB Cloud Starter 和 Essential 限制](/tidb-cloud/serverless-limitations.md)。 -## TiDB Cloud Serverless +## TiDB Cloud Starter {#starter} -TiDB Cloud Serverless（现称 Starter）是一款全托管的多租户 TiDB 服务。它提供了一个即时、自动弹性扩缩的 MySQL 兼容数据库，并在超出免费额度后，按消耗计费。 +TiDB Cloud Starter 是一款全托管的多租户 TiDB 服务。它提供了一个即开即用、自动弹性扩缩的 MySQL 兼容数据库，并在超出免费额度后，按用量计费。 免费集群方案非常适合刚开始使用 TiDB Cloud Starter 的用户。它为开发者和小型团队提供以下基础功能： - **免费**：该方案完全免费，无需信用卡即可开始使用。 - **存储**：提供初始 5 GiB 的行存储和 5 GiB 的列存储。 -- **请求单位**：包含 5000 万 [请求单位（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 用于数据库操作。 +- **Request Units**：包含 5000 万 [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 用于数据库操作。 -### 使用配额 +### 使用额度 -对于 TiDB Cloud 中的每个组织，默认最多可以创建 5 个免费的 TiDB Cloud Starter 集群。若需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并指定消费上限。 +对于 TiDB Cloud 中的每个组织，默认最多可以创建 5 个免费的 TiDB Cloud Starter 集群。若需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并设置消费上限。 -对于组织中的前 5 个 TiDB Cloud Starter 集群，无论是免费还是可扩展，TiDB Cloud 都为每个集群提供如下免费使用配额： +对于组织中的前 5 个 TiDB Cloud Starter 集群，无论是免费还是可扩展集群，TiDB Cloud 都为每个集群提供如下免费使用额度： - 行存储：5 GiB - 列存储：5 GiB -- 请求单位（RUs）：每月 5000 万 RUs +- Request Units (RUs)：每月 5000 万 RUs -请求单位（RU）是用于衡量单个数据库请求所消耗资源量的单位。每个请求消耗的 RU 数量取决于多种因素，例如操作类型或检索/修改的数据量。 +Request Unit (RU) 是用于衡量单次数据库请求所消耗资源量的单位。每个请求消耗的 RU 数量取决于多种因素，例如操作类型或检索/修改的数据量。 -一旦集群达到其使用配额，将立即拒绝任何新的连接尝试，直到你 [增加配额](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit) 或在新月开始时重置使用量。已建立的连接在达到配额前会保持活跃，但会受到限流。例如，当免费集群的行存储超过 5 GiB 时，集群会自动限制任何新的连接尝试。 +一旦集群达到其使用额度，将立即拒绝任何新的连接尝试，直到你 [增加额度](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit) 或新月开始时用量被重置。已建立的连接在达到额度前会保持活跃，但会受到限流。例如，当免费集群的行存储超过 5 GiB 时，集群会自动限制任何新的连接尝试。 如需了解不同资源（包括读、写、SQL CPU 和网络出口）的 RU 消耗、定价详情及限流信息，请参见 [TiDB Cloud Starter 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 ## TiDB Cloud Essential {#essential} -对于需要实时扩展以应对不断增长的工作负载的应用，Essential 集群方案提供了灵活性和性能，助力你的业务增长，主要特性包括： +对于工作负载不断增长、需要实时扩展的应用，Essential 集群方案提供了灵活性和性能，助力你的业务持续增长，主要特性包括： - **增强能力**：包含 Starter 方案的所有功能，并具备处理更大、更复杂工作负载的能力，以及高级安全特性。 - **自动扩缩**：自动调整存储和计算资源，高效应对变化的工作负载需求。 - **高可用性**：内置容错和冗余机制，确保你的应用即使在基础设施故障时也能保持可用和弹性。 -- **可预测的定价**：根据存储和计算资源的请求容量单位（RCUs）计费，提供透明、按用量计费的定价模式，随需扩展，你只需为实际使用的资源付费，无额外意外支出。 +- **可预测的定价**：基于存储和计算资源的 Request Capacity Units (RCUs) 计费，提供透明、按用量计费的定价模式，随需扩展，让你只为实际使用的资源付费，无额外意外支出。 -## 用户名前缀 +## User name prefix - + 对于每个 TiDB Cloud Starter 或 TiDB Cloud Essential 集群，TiDB Cloud 会生成一个唯一的前缀，以便与其他集群区分。 @@ -69,7 +69,7 @@ TiDB Cloud Serverless（现称 Starter）是一款全托管的多租户 TiDB 服 > **注意：** > - > TiDB Cloud Starter 和 TiDB Cloud Essential 需要使用 TLS 连接。要查找你系统上的 CA 根证书路径，请参见 [根证书默认路径](/tidb-cloud/secure-connections-to-serverless-clusters.md#root-certificate-default-path)。 + > TiDB Cloud Starter 和 TiDB Cloud Essential 需要使用 TLS 连接。如何在你的系统中查找 CA 根证书路径，请参见 [根证书默认路径](/tidb-cloud/secure-connections-to-serverless-clusters.md#root-certificate-default-path)。 - 创建数据库用户： @@ -77,10 +77,10 @@ TiDB Cloud Serverless（现称 Starter）是一款全托管的多租户 TiDB 服 CREATE USER '3pTAoNNegb47Uc8.jeffrey'; ``` -获取你的集群前缀，请按以下步骤操作： +获取你的集群前缀，请按照以下步骤操作： 1. 进入 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 -2. 点击目标集群名称进入其概览页面，然后点击右上角的 **Connect**。会弹出连接对话框。 +2. 点击目标集群名称进入其概览页面，然后点击右上角的 **Connect**。此时会弹出连接对话框。 3. 在对话框中，从连接字符串中获取前缀。 ## TiDB Cloud Dedicated diff --git a/tidb-cloud/serverless-driver.md b/tidb-cloud/serverless-driver.md index 9b5f37f3ef06a..b31de11dfeb30 100644 --- a/tidb-cloud/serverless-driver.md +++ b/tidb-cloud/serverless-driver.md @@ -1,16 +1,20 @@ --- title: TiDB Cloud Serverless Driver (Beta) -summary: 了解如何从无服务器和边缘环境连接到 TiDB Cloud Serverless。 +summary: 了解如何从 serverless 和边缘环境连接到 TiDB Cloud Starter 或 TiDB Cloud Essential。 aliases: ['/tidbcloud/serverless-driver-config'] --- # TiDB Cloud Serverless Driver (Beta) +> **Note:** +> +> serverless driver 目前为 beta 版本，仅适用于 TiDB Cloud Starter 或 TiDB Cloud Essential 集群。 + ## 为什么要使用 TiDB Cloud Serverless Driver (Beta) -传统的基于 TCP 的 MySQL 驱动程序并不适用于无服务器函数，因为它们期望建立长时间存在的持久 TCP 连接，这与无服务器函数的短暂生命周期相矛盾。此外，在 [Vercel Edge Functions](https://vercel.com/docs/functions/edge-functions) 和 [Cloudflare Workers](https://workers.cloudflare.com/) 等边缘环境中，可能缺乏对完整 TCP 的支持和完整的 Node.js 兼容性，这些驱动程序可能根本无法工作。 +传统的基于 TCP 的 MySQL 驱动并不适合 serverless 函数，因为它们期望建立长连接、持久的 TCP 连接，这与 serverless 函数的短生命周期特性相矛盾。此外，在 [Vercel Edge Functions](https://vercel.com/docs/functions/edge-functions) 和 [Cloudflare Workers](https://workers.cloudflare.com/) 等边缘环境中，可能缺乏完整的 TCP 支持和完整的 Node.js 兼容性，这些驱动甚至可能无法工作。 -[TiDB Cloud serverless driver (Beta)](https://github.com/tidbcloud/serverless-js) 针对 JavaScript，可以通过 HTTP 连接到你的 TiDB Cloud Serverless 集群，而 HTTP 通常被无服务器环境所支持。借助该驱动，现在可以从边缘环境连接到 TiDB Cloud Serverless 集群，并在保持与传统基于 TCP 的 MySQL 驱动类似开发体验的同时，减少 TCP 带来的连接开销。 +[TiDB Cloud serverless driver (Beta)](https://github.com/tidbcloud/serverless-js) 针对 JavaScript，可以让你通过 HTTP 连接到 TiDB Cloud Starter 或 TiDB Cloud Essential 集群，而 HTTP 通常被 serverless 环境所支持。借助该驱动，你可以从边缘环境连接到 TiDB Cloud Starter 或 TiDB Cloud Essential 集群，并在保持与传统基于 TCP 的 MySQL 驱动类似开发体验的同时，减少 TCP 带来的连接开销。 > **Note:** > @@ -26,11 +30,11 @@ npm install @tidbcloud/serverless ## 使用 serverless driver -你可以使用 serverless driver 查询 TiDB Cloud Serverless 集群中的数据或执行交互式事务。 +你可以使用 serverless driver 查询 TiDB Cloud Starter 或 TiDB Cloud Essential 集群的数据，或执行交互式事务。 ### 查询 -要从 TiDB Cloud Serverless 集群查询数据，你需要先创建一个连接。然后可以使用该连接执行原始 SQL 查询。例如： +要从 TiDB Cloud Starter 或 TiDB Cloud Essential 集群查询数据，你需要先创建连接，然后可以使用该连接执行原生 SQL 查询。例如： ```ts import { connect } from '@tidbcloud/serverless' @@ -61,7 +65,7 @@ try { ## 边缘环境示例 -以下是在边缘环境中使用 serverless driver 的一些示例。你也可以尝试这个 [在线演示](https://github.com/tidbcloud/car-sales-insight) 获取完整示例。 +以下是一些在边缘环境中使用 serverless driver 的示例。你也可以尝试这个 [在线演示](https://github.com/tidbcloud/car-sales-insight) 获取完整示例。 @@ -80,7 +84,7 @@ export async function GET(request: NextRequest) { } ``` -了解更多关于 [在 Vercel 中使用 TiDB Cloud serverless driver](/tidb-cloud/integrate-tidbcloud-with-vercel.md)。 +了解更多 [在 Vercel 中使用 TiDB Cloud serverless driver](/tidb-cloud/integrate-tidbcloud-with-vercel.md)。
@@ -100,7 +104,7 @@ export default { }; ``` -了解更多关于 [在 Cloudflare Workers 中使用 TiDB Cloud serverless driver](/tidb-cloud/integrate-tidbcloud-with-cloudflare.md)。 +了解更多 [在 Cloudflare Workers 中使用 TiDB Cloud serverless driver](/tidb-cloud/integrate-tidbcloud-with-cloudflare.md)。
@@ -116,7 +120,7 @@ export default async () => { } ``` -了解更多关于 [在 Netlify 中使用 TiDB Cloud serverless driver](/tidb-cloud/integrate-tidbcloud-with-netlify.md#use-the-edge-function)。 +了解更多 [在 Netlify 中使用 TiDB Cloud serverless driver](/tidb-cloud/integrate-tidbcloud-with-netlify.md#use-the-edge-function)。
@@ -154,15 +158,15 @@ const result = await conn.execute('show tables') | Name | Type | Default value | Description | |--------------|----------|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `username` | string | N/A | TiDB Cloud Serverless 的用户名 | -| `password` | string | N/A | TiDB Cloud Serverless 的密码 | -| `host` | string | N/A | TiDB Cloud Serverless 的主机名 | -| `database` | string | `test` | TiDB Cloud Serverless 的数据库 | -| `url` | string | N/A | 数据库的 URL，格式为 `mysql://[username]:[password]@[host]/[database]`，如果你打算连接到默认数据库，可以省略 `database`。 | -| `fetch` | function | global fetch | 自定义 fetch 函数。例如，你可以在 node.js 中使用 `undici` 的 fetch。 | -| `arrayMode` | bool | `false` | 是否以数组而不是对象的形式返回结果。为了获得更好的性能，可以设置为 `true`。 | -| `fullResult` | bool | `false` | 是否返回完整的结果对象而不仅仅是行数据。为了获得更详细的结果，可以设置为 `true`。 | -| `decoders` | object | `{}` | 一组键值对，允许你为不同的列类型自定义解码过程。在每一对中，你可以指定列类型作为 key，并指定相应的函数作为 value。该函数以 TiDB Cloud serverless driver 返回的原始字符串值为参数，并返回解码后的值。 | +| `username` | string | N/A | 集群的用户名。 | +| `password` | string | N/A | 集群的密码。 | +| `host` | string | N/A | 集群的主机名。 | +| `database` | string | `test` | 集群的数据库。 | +| `url` | string | N/A | 数据库的 URL，格式为 `mysql://[username]:[password]@[host]/[database]`，其中 `database` 可省略（如果你打算连接默认数据库）。 | +| `fetch` | function | global fetch | 自定义 fetch 函数。例如，你可以在 node.js 中使用 `undici` 的 fetch。 | +| `arrayMode` | bool | `false` | 是否以数组而非对象的形式返回结果。为了获得更好的性能，可以设置为 `true`。 | +| `fullResult` | bool | `false` | 是否返回完整的结果对象而不仅仅是行数据。为了获得更详细的结果，可以设置为 `true`。 | +| `decoders` | object | `{}` | 一组键值对，允许你为不同的列类型自定义解码过程。在每对中，你可以指定列类型作为 key，并指定相应的函数作为 value。该函数以 TiDB Cloud serverless driver 返回的原始字符串值为参数，并返回解码后的值。 | **Database URL** @@ -170,7 +174,7 @@ const result = await conn.execute('show tables') > > 如果你的用户名、密码或数据库名包含特殊字符，在通过 URL 传递时必须对这些字符进行 [百分号编码](https://en.wikipedia.org/wiki/Percent-encoding)。例如，密码 `password1@//?` 需要在 URL 中编码为 `password1%40%2F%2F%3F`。 -当配置了 `url` 后，无需单独配置 `host`、`username`、`password` 和 `database`。以下代码是等价的： +当配置了 `url` 后，无需单独配置 `host`、`username`、`password` 和 `database`。以下代码等价： ```ts const config = { @@ -199,14 +203,14 @@ const conn = connect(config) > > SQL 级别选项的优先级高于连接级别配置。 -在 SQL 级别，你可以配置以下选项： +在 SQL 级别，你可以配置如下选项： | Option | Type | Default value | Description | |--------------|--------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `arrayMode` | bool | `false` | 是否以数组而不是对象的形式返回结果。为了获得更好的性能，可以设置为 `true`。 | -| `fullResult` | bool | `false` | 是否返回完整的结果对象而不仅仅是行数据。为了获得更详细的结果，可以设置为 `true`。 | -| `isolation` | string | `REPEATABLE READ` | 事务隔离级别，可以设置为 `READ COMMITTED` 或 `REPEATABLE READ`。 | -| `decoders` | object | `{}` | 一组键值对，允许你为不同的列类型自定义解码过程。在每一对中，你可以指定列类型作为 key，并指定相应的函数作为 value。该函数以 TiDB Cloud serverless driver 返回的原始字符串值为参数，并返回解码后的值。如果你在连接级别和 SQL 级别都配置了 `decoders`，则连接级别中 key 不同的键值对会合并到 SQL 级别生效。如果同一个 key（即列类型）在两个级别都指定了，则以 SQL 级别的 value 为准。 | +| `arrayMode` | bool | `false` | 是否以数组而非对象的形式返回结果。为了获得更好的性能，可以设置为 `true`。 | +| `fullResult` | bool | `false` | 是否返回完整的结果对象而不仅仅是行数据。为了获得更详细的结果，可以设置为 `true`。 | +| `isolation` | string | `REPEATABLE READ` | 事务隔离级别，可设置为 `READ COMMITTED` 或 `REPEATABLE READ`。 | +| `decoders` | object | `{}` | 一组键值对，允许你为不同的列类型自定义解码过程。在每对中，你可以指定列类型作为 key，并指定相应的函数作为 value。该函数以 TiDB Cloud serverless driver 返回的原始字符串值为参数，并返回解码后的值。如果你在连接级别和 SQL 级别都配置了 `decoders`，则连接级别中 key 不同的键值对会合并到 SQL 级别生效；如果同一个 key（即列类型）在两级都配置了，则以 SQL 级别为准。 | **arrayMode 和 fullResult** @@ -239,12 +243,12 @@ const conn = connect({ // 默认情况下，TiDB Cloud serverless driver 会将 BIGINT 类型作为文本值返回。此解码器将 BIGINT 转换为 JavaScript 内置的 BigInt 类型。 [ColumnType.BIGINT]: (rawValue: string) => BigInt(rawValue), - // 默认情况下，TiDB Cloud serverless driver 会将 DATETIME 类型以 'yyyy-MM-dd HH:mm:ss' 格式的文本值返回。此解码器将 DATETIME 文本转换为 JavaScript 原生的 Date 对象。 + // 默认情况下，TiDB Cloud serverless driver 会将 DATETIME 类型以 'yyyy-MM-dd HH:mm:ss' 格式的文本返回。此解码器将 DATETIME 文本转换为 JavaScript 原生的 Date 对象。 [ColumnType.DATETIME]: (rawValue: string) => new Date(rawValue), } }) -// 你也可以在 SQL 级别配置 decoder 选项，以覆盖连接级别中相同 key 的 decoders。 +// 你也可以在 SQL 级别配置 decoder 选项，以覆盖连接级别相同 key 的解码器。 conn.execute(`select ...`, [], { decoders: { // ... @@ -263,13 +267,13 @@ conn.execute(`select ...`, [], { ### 支持的 SQL 语句 -支持 DDL，并支持以下 SQL 语句：`SELECT`、`SHOW`、`EXPLAIN`、`USE`、`INSERT`、`UPDATE`、`DELETE`、`BEGIN`、`COMMIT`、`ROLLBACK` 和 `SET`。 +支持 DDL 以及以下 SQL 语句：`SELECT`、`SHOW`、`EXPLAIN`、`USE`、`INSERT`、`UPDATE`、`DELETE`、`BEGIN`、`COMMIT`、`ROLLBACK` 和 `SET`。 ### 数据类型映射 -TiDB Cloud Serverless 与 Javascript 之间的数据类型映射如下： +TiDB 与 Javascript 之间的数据类型映射如下： -| TiDB Cloud Serverless type | Javascript type | +| TiDB data type | Javascript type | |----------------------|-----------------| | TINYINT | number | | UNSIGNED TINYINT | number | @@ -310,7 +314,7 @@ TiDB Cloud Serverless 与 Javascript 之间的数据类型映射如下： > **Note:** > -> 请确保在 TiDB Cloud Serverless 中使用默认的 `utf8mb4` 字符集进行类型转换为 JavaScript 字符串，因为 TiDB Cloud serverless driver 使用 UTF-8 编码将其解码为字符串。 +> 请确保在 TiDB Cloud 中使用默认的 `utf8mb4` 字符集进行类型转换为 JavaScript 字符串，因为 TiDB Cloud serverless driver 使用 UTF-8 编码将其解码为字符串。 > **Note:** > @@ -327,11 +331,14 @@ TiDB Cloud serverless driver 已集成以下 ORM： ## 计费 -serverless driver 本身是免费的，但使用该驱动访问数据会产生 [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 和存储用量。计费遵循 [TiDB Cloud Serverless 计费](https://www.pingcap.com/tidb-serverless-pricing-details/) 模型。 +serverless driver 本身是免费的，但使用该驱动访问数据会产生 [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 和存储用量。 + +- 对于 TiDB Cloud Starter 集群，计费遵循 [TiDB Cloud Starter 计费](https://www.pingcap.com/tidb-cloud-starter-pricing-details/) 模型。 +- 对于 TiDB Cloud Essential 集群，计费遵循 [TiDB Cloud Essential 计费](/tidb-cloud/tidb-cloud-billing.md#pricing-for-essential) 模型。 ## 限制 -目前，使用 serverless driver 有以下限制： +目前，使用 serverless driver 有如下限制： - 单次查询最多可获取 10,000 行数据。 - 每次只能执行一条 SQL 语句，不支持在一个查询中执行多条 SQL 语句。 diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index b81b71b7b7ec2..01a9d50abffce 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -1,6 +1,6 @@ --- title: "TiDB Cloud Starter 常见问题" -summary: 了解与 TiDB Cloud Starter 相关的最常见问题（FAQ）。 +summary: 了解与 TiDB Cloud Starter 相关的最常见问题（FAQs）。 aliases: ['/tidbcloud/serverless-tier-faqs'] --- @@ -27,9 +27,9 @@ TiDB Cloud Starter 为你和你的组织提供具备完整 HTAP 能力的 TiDB 为了让这个入门层的定位更加清晰，我们将其更名为 Starter，这是使用 TiDB Cloud 构建应用最快捷的方式。你对 Serverless 层的所有认知依然适用： - 全托管的数据库，支持行存和列存，适合混合 OLTP 和 OLAP 工作负载。 -- 自动且按需扩缩容，无需容量规划或手动调优。 +- 自动、按需扩缩容，无需容量规划或手动调优。 - 内置向量检索和全文检索，助力 GenAI 检索、聊天机器人及其他 AI 应用。 -- 每个组织每月可免费创建最多五个集群（每个集群 5 GiB 行存数据 + 5 GiB 列存数据 + 5000 万 [RUs](/tidb-cloud/tidb-cloud-glossary.md#request-unit)）。 +- 每个组织每月可免费使用最多五个集群（每个集群 5 GiB 行存数据 + 5 GiB 列存数据 + 5000 万 [RUs](/tidb-cloud/tidb-cloud-glossary.md#request-unit)）。 ### 如何开始使用 TiDB Cloud Starter？ @@ -37,17 +37,17 @@ TiDB Cloud Starter 为你和你的组织提供具备完整 HTAP 能力的 TiDB ### 在 TiDB Cloud 中，我最多可以创建多少个 TiDB Cloud Starter 集群？ -在 TiDB Cloud 中，每个组织默认最多可以创建五个 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群。如需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并为用量设置 [消费上限](/tidb-cloud/manage-serverless-spend-limit.md)。 +在 TiDB Cloud 中，每个组织默认最多可以创建五个 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群。如需创建更多 TiDB Cloud Starter 集群，需要添加信用卡并设置 [消费限额](/tidb-cloud/manage-serverless-spend-limit.md)。 -### TiDB Cloud Starter 是否支持所有 TiDB Cloud 功能？ +### TiDB Cloud Starter 是否完全支持所有 TiDB Cloud 功能？ -部分 TiDB Cloud 功能在 TiDB Cloud Starter 上仅部分支持或暂不支持。详细信息请参见 [TiDB Cloud Starter 限制与配额](/tidb-cloud/serverless-limitations.md)。 +部分 TiDB Cloud 功能在 TiDB Cloud Starter 上仅部分支持或不支持。详细信息请参见 [TiDB Cloud Starter 限制与配额](/tidb-cloud/serverless-limitations.md)。 ### TiDB Cloud Starter 何时会支持除 AWS 以外的云平台，如 Google Cloud 或 Azure？ -我们正在积极推进 TiDB Cloud Starter 向 Google Cloud、Azure 等其他云平台的扩展。但目前尚无具体时间表，因为我们当前专注于补齐功能差距并确保各环境下的无缝体验。请放心，我们会持续努力让 TiDB Cloud Starter 支持更多云平台，并在进展时及时向社区通报。 +我们正在积极推进 TiDB Cloud Starter 向 Google Cloud、Azure 等其他云平台的扩展。但目前尚无确切时间表，因为我们当前专注于补齐功能差距并确保所有环境下的无缝体验。请放心，我们会持续努力让 TiDB Cloud Starter 支持更多云平台，并在进展过程中及时向社区通报。 -### 在 TiDB Cloud Starter 推出前我创建了 Developer Tier 集群，还能继续使用吗？ +### 在 TiDB Cloud Starter 推出前，我创建了 Developer Tier 集群，还能继续使用吗？ 可以，你的 Developer Tier 集群已自动迁移为 TiDB Cloud Starter 集群，带来更好的用户体验，且不会影响你之前的使用。 @@ -55,23 +55,23 @@ TiDB Cloud Starter 为你和你的组织提供具备完整 HTAP 能力的 TiDB TiDB Cloud Starter 的列存储作为行存储的额外副本，确保强一致性。与传统的行存储（按行存储数据）不同，列存储按列组织数据，更适合数据分析任务。 -列存储是 TiDB 实现 HTAP（混合事务与分析处理）能力的关键特性之一，实现事务与分析负载的无缝融合。 +列存储是 TiDB 实现 HTAP（混合事务与分析处理）能力的关键特性，实现事务与分析负载的无缝融合。 为高效管理列存储数据，TiDB Cloud Starter 使用独立的弹性 TiFlash 引擎。在查询执行时，优化器会自动引导集群决定从行存还是列存读取数据。 ### 在哪些场景下应使用 TiDB Cloud Starter 的列存储？ -在以下场景下建议使用 TiDB Cloud Starter 的列存储： +在以下场景建议使用 TiDB Cloud Starter 的列存储： - 你的工作负载包含需要高效数据扫描和聚合的分析任务。 - 你优先考虑分析型负载的性能提升。 -- 你希望将分析处理与事务处理隔离，避免对 TP（事务处理）负载产生性能影响。独立的列存储有助于优化不同类型的负载模式。 +- 你希望将分析处理与事务处理隔离，避免对 TP（事务处理）负载产生性能影响。独立的列存储有助于优化不同的负载模式。 -在这些场景下，列存储可以显著提升查询性能，为系统中的混合负载带来流畅体验。 +在这些场景下，列存储能显著提升查询性能，为系统中的混合负载带来流畅体验。 ### 如何在 TiDB Cloud Starter 中使用列存储？ -在 TiDB Cloud Starter 中使用列存储的方式与 TiFlash 类似。你可以在表级或数据库级启用列存储： +在 TiDB Cloud Starter 中使用列存储与 TiFlash 的用法类似。你可以在表级或数据库级启用列存储： - 表级：为某个表分配 TiFlash 副本，为该表启用列存储。 - 数据库级：为数据库内所有表配置 TiFlash 副本，实现整个数据库的列存储。 @@ -84,61 +84,61 @@ TiDB Cloud Starter 的列存储作为行存储的额外副本，确保强一致 当你通过 Public Endpoint 连接时，连接会经过多个网络服务商和中间设备。这些设备可能有较短的空闲超时时间，导致连接被提前中断。详细信息请参见 [连接限制](/tidb-cloud/serverless-limitations.md#connection)。 -## 计费与用量常见问题 +## 计费与计量常见问题 ### 什么是 Request Units？ -TiDB Cloud Starter 采用按需付费模式，你只需为存储空间和集群用量付费。在该模式下，所有集群活动（如 SQL 查询、批量操作、后台任务）都以 [Request Units（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 计量。RU 是衡量集群请求规模和复杂度的抽象单位。详细信息请参见 [TiDB Cloud Starter 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 +TiDB Cloud Starter 采用按需付费模式，你只需为存储空间和集群使用量付费。在该模式下，所有集群活动（如 SQL 查询、批量操作、后台任务）都以 [Request Units（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit) 计量。RU 是对集群请求规模和复杂度的抽象度量。详细信息请参见 [TiDB Cloud Starter 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 ### TiDB Cloud Starter 是否有免费计划？ -对于每个组织的前五个 TiDB Cloud Starter 集群，TiDB Cloud 为每个集群提供如下免费用量额度： +对于你所在组织的前五个 TiDB Cloud Starter 集群，TiDB Cloud 为每个集群提供如下免费额度： - 行存储：5 GiB - 列存储：5 GiB - [Request Units（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit)：每月 5000 万 RUs -如果为 TiDB Cloud Starter 集群设置了每月消费上限，超出免费额度的用量将会计费。对于免费集群，达到免费额度后，该集群的读写操作会被限流，直到你设置每月消费上限或新月开始时用量重置。 +如果为 TiDB Cloud Starter 集群设置了每月消费限额，超出免费额度的部分将会计费。对于免费集群，达到免费额度后，该集群的读写操作会被限流，直到你设置每月消费限额或新月开始时用量重置。 -详细信息请参见 [TiDB Cloud Starter 用量额度](/tidb-cloud/select-cluster-tier.md#usage-quota)。 +详细信息请参见 [TiDB Cloud Starter 使用额度](/tidb-cloud/select-cluster-tier.md#usage-quota)。 ### 免费计划有哪些限制？ -在免费计划下，集群性能受限于不可扩展的资源。每个查询的内存分配上限为 256 MiB，并可能出现每秒 RUs（Request Units）受限的瓶颈。为最大化集群性能并避免这些限制，你可以为 TiDB Cloud Starter 集群 [设置每月消费上限](/tidb-cloud/manage-serverless-spend-limit.md)。 +在免费计划下，集群性能受限于不可扩展的资源。每个查询的内存分配被限制为 256 MiB，并可能出现每秒 Request Units（RUs）受限的性能瓶颈。为最大化集群性能并避免这些限制，你可以为 TiDB Cloud Starter 集群 [设置每月消费限额](/tidb-cloud/manage-serverless-spend-limit.md)。 -### 如何评估我的工作负载所需的 RUs 数量并规划每月预算？ +### 如何评估我的工作负载所需的 RU 数量并规划每月预算？ -要获取单条 SQL 语句的 RU 消耗，可以使用 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md#ru-request-unit-consumption) SQL 语句。但需要注意，`EXPLAIN ANALYZE` 返回的 RUs 用量不包含出口（egress）RUs，因为出口用量在网关单独计量，TiDB 服务器无法获知。 +要获取单条 SQL 语句的 RU 消耗，可以使用 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md#ru-request-unit-consumption) SQL 语句。但需要注意，`EXPLAIN ANALYZE` 返回的 RUs 用量不包含出口 RUs，因为出口用量在网关单独计量，TiDB 服务器无法获知。 -要查看集群的 RUs 和存储用量，请在集群概览页面查看 **Usage this month** 面板。结合历史和实时资源用量数据，你可以跟踪集群资源消耗并合理预估消费上限。如果免费额度无法满足需求，可以编辑消费上限以获取更多资源。详细信息请参见 [TiDB Cloud Starter 用量额度](/tidb-cloud/select-cluster-tier.md#usage-quota)。 +要查看集群的 RUs 和存储用量，请在集群概览页查看 **Usage this month** 面板。结合历史和实时资源用量数据，你可以跟踪集群资源消耗并合理预估消费限额。如果免费额度无法满足需求，可以编辑消费限额以获取更多资源。详细信息请参见 [TiDB Cloud Starter 使用额度](/tidb-cloud/select-cluster-tier.md#usage-quota)。 -### 如何优化我的工作负载以减少 RUs 消耗？ +### 如何优化我的工作负载以减少 RU 消耗？ -请确保你的查询已根据 [SQL 性能优化](/develop/dev-guide-optimize-sql-overview.md) 指南进行优化。要识别消耗 RUs 最多的 SQL 语句，可前往集群的 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页面，查看 **SQL Statements** 标签页，按 **Total RU** 或 **Mean RU** 排序，分析 SQL 执行情况。详细信息请参见 [语句分析](/tidb-cloud/tune-performance.md#statement-analysis)。此外，减少出口流量同样有助于降低 RUs 消耗。建议查询时仅返回必要的列和行，从而减少网络出口流量。通过精确选择和过滤返回的列与行，可以优化网络利用率。 +请按照 [SQL 性能优化](/develop/dev-guide-optimize-sql-overview.md) 指南，确保查询已充分优化以获得最佳性能。要识别消耗 RUs 最多的 SQL 语句，可进入集群的 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页面，查看 **SQL Statements** 标签页，按 **Total RU** 或 **Mean RU** 排序，分析 SQL 执行情况。详细信息请参见 [语句分析](/tidb-cloud/tune-performance.md#statement-analysis)。此外，减少出口流量对降低 RUs 消耗也很重要。建议查询时仅返回必要的列和行，从而减少网络出口流量。通过精确选择和过滤返回的列与行，可以优化网络利用率。 ### TiDB Cloud Starter 的存储如何计量？ -存储用量按 TiDB Cloud Starter 集群中存储的数据量（以 GiB/月计）计量。计算方式为：所有表和索引的总大小（不含数据压缩或副本）乘以该数据在当月存储的小时数。 +存储计量基于 TiDB Cloud Starter 集群中存储的数据量，以 GiB/月为单位。计算方式为：所有表和索引的总大小（不含数据压缩或副本）乘以该月内数据存储的小时数。 -### 为什么删除表或数据库后存储用量没有立即减少？ +### 为什么在立即删除表或数据库后，存储用量没有变化？ -这是因为 TiDB 会在一段时间内保留已删除的表和数据库。该保留期确保依赖这些表的事务可以继续执行。此外，保留期也使 [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md)/[`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md) 功能成为可能，便于你在误删时恢复表或数据库。 +这是因为 TiDB 会在一段时间内保留已删除的表和数据库。该保留期确保依赖这些表的事务可以继续执行。此外，保留期也使 [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md)/[`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md) 功能成为可能，便于你在误删时恢复表和数据库。 -### 为什么在没有主动运行查询时仍有 RU 消耗？ +### 为什么在没有主动运行查询时也会有 RU 消耗？ -RU 消耗可能出现在多种场景。常见场景包括后台查询，如在 TiDB 实例间同步模式变更、执行 DDL 任务、刷新权限、刷新 SQL 绑定、刷新全局变量等。另一个场景是某些 Web 控制台功能会生成查询（如加载 schema）。这些过程即使没有用户主动触发，也会消耗 RUs。 +RU 消耗可能出现在多种场景。常见场景包括后台查询，如同步 TiDB 实例间的 schema 变更、执行 DDL 任务、刷新权限、刷新 SQL 绑定、刷新全局变量等。另一个场景是某些 Web 控制台功能会生成查询（如加载 schema）。这些过程即使没有用户主动触发，也会消耗 RUs。 ### 为什么在工作负载稳定时会出现 RU 用量突增？ RU 用量突增可能由 TiDB 的必要后台任务引起。这些任务（如自动分析表、重建统计信息）是生成优化查询计划所必需的。 -### 当集群用尽免费额度或超出消费上限时会发生什么？ +### 当集群用尽免费额度或超出消费限额时会发生什么？ -一旦集群达到免费额度或消费上限，系统会立即拒绝所有新的连接请求，直到额度提升或新月开始时用量重置。已建立的连接在达到额度前会继续保持，但会受到限流。详细信息请参见 [TiDB Cloud Starter 限制与配额](/tidb-cloud/serverless-limitations.md#usage-quota)。 +一旦集群达到免费额度或消费限额，系统会立即拒绝所有新的连接请求，直到额度提升或新月开始时用量重置。已建立的连接在达到额度前会保持活跃，但会被限流。详细信息请参见 [TiDB Cloud Starter 限制与配额](/tidb-cloud/serverless-limitations.md#usage-quota)。 -### 为什么导入数据时 RU 用量会出现突增？ +### 为什么导入数据时会出现 RU 用量突增？ -在 TiDB Cloud Starter 集群的数据导入过程中，只有数据成功导入时才会消耗 RUs，因此会出现 RU 用量的突增。 +在 TiDB Cloud Starter 集群的数据导入过程中，只有数据成功导入时才会消耗 RU，因此会出现 RU 用量的突增。 ### 在 TiDB Cloud Starter 中使用列存储会产生哪些费用？ @@ -150,7 +150,7 @@ TiDB Cloud Starter 的列存储计费方式与行存储类似。使用列存储 TiDB Cloud Starter 的列存储由于额外副本，会产生更多存储和数据同步资源的费用。但在运行分析型查询时，列存储更具性价比。 -根据 TPC-H 基准测试，使用列存储运行分析型查询的成本约为行存储的三分之一。 +根据 TPC-H 基准测试，在列存储上运行分析型查询的成本约为行存储的三分之一。 因此，虽然初期因副本增加会有额外成本，但分析场景下的计算成本大幅降低，使其在特定用例下更具成本优势。尤其对于有分析需求的用户，列存储可显著降低成本，带来可观的节省空间。 @@ -158,7 +158,7 @@ TiDB Cloud Starter 的列存储由于额外副本，会产生更多存储和数 ### 我的 TiDB Cloud Starter 是共享还是专用的？ -Serverless 技术为多租户设计，所有集群的资源是共享的。如需获得基础设施和资源隔离的托管 TiDB 服务，可以升级为 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)。 +Serverless 技术为多租户设计，所有集群使用的资源是共享的。如需获得基础设施和资源隔离的托管 TiDB 服务，可以升级为 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)。 ### TiDB Cloud Starter 如何保障安全？ @@ -167,6 +167,6 @@ Serverless 技术为多租户设计，所有集群的资源是共享的。如需 ## 运维常见问题 -### 我可以升级集群所运行的 TiDB 版本吗？ +### 我可以升级集群运行的 TiDB 版本吗？ -不可以。TiDB Cloud Starter 集群会随着 TiDB Cloud 推出新版本自动升级。你可以在 [TiDB Cloud 控制台](https://tidbcloud.com/project/clusters) 或最新的 [发布说明](https://docs.pingcap.com/tidbcloud/tidb-cloud-release-notes) 查看集群当前的 TiDB 版本。你也可以连接到集群，使用 `SELECT version()` 或 `SELECT tidb_version()` 查询 TiDB 版本。 \ No newline at end of file +不可以。TiDB Cloud Starter 集群会随着 TiDB Cloud 推出新版本自动升级。你可以在 [TiDB Cloud 控制台](https://tidbcloud.com/project/clusters) 或最新的 [发布说明](https://docs.pingcap.com/tidbcloud/tidb-cloud-release-notes) 查看集群当前运行的 TiDB 版本。你也可以连接到集群，使用 `SELECT version()` 或 `SELECT tidb_version()` 查询 TiDB 版本。 \ No newline at end of file diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index e573261dfc174..2a5113bb6552d 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -8,9 +8,9 @@ aliases: ['/tidbcloud/serverless-tier-limitations'] -TiDB Cloud Starter 和 Essential 支持几乎所有 TiDB 支持的工作负载，但与 TiDB 自建版或 TiDB Cloud Dedicated 集群相比，存在一些功能差异。本文档介绍了 TiDB Cloud Starter 和 TiDB Cloud Essential 的限制。 +TiDB Cloud Starter 和 Essential 支持几乎所有 TiDB 支持的工作负载，但与 TiDB 自建版或 TiDB Cloud 专属集群相比，存在一些功能差异。本文档介绍了 TiDB Cloud Starter 和 TiDB Cloud Essential 的限制。 -我们正在不断缩小 TiDB Cloud Starter/Essential 与 TiDB Cloud Dedicated 集群之间的功能差距。如果你需要这些尚未支持的功能或能力，请使用 [TiDB Cloud Dedicated 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 或 [联系我们](https://www.pingcap.com/contact-us/?from=en) 提交功能需求。 +我们正在不断缩小 TiDB Cloud Starter/Essential 与 TiDB Cloud 专属集群之间的功能差距。如果你需要这些尚未支持的功能或能力，请使用 [TiDB Cloud 专属集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 或 [联系我们](https://www.pingcap.com/contact-us/?from=en) 提交功能需求。 ## 限制 @@ -29,7 +29,7 @@ TiDB Cloud Starter 和 Essential 支持几乎所有 TiDB 支持的工作负载 ### 加密 -- 你在 TiDB Cloud Starter 或 TiDB Cloud Essential 集群中持久化的数据，使用由管理你集群的云服务商提供的加密工具进行加密。对于 TiDB Cloud Starter（消费额度 > 0）和 TiDB Cloud Essential 集群，在集群创建过程中可选启用第二层加密，为默认的静态加密提供额外的安全保障。 +- 你在 TiDB Cloud Starter 或 TiDB Cloud Essential 集群中持久化的数据，使用由管理你集群的云服务商提供的加密工具进行加密。对于 TiDB Cloud Starter（消费限额 > 0）和 TiDB Cloud Essential 集群，在集群创建过程中可选启用第二层加密，相较于默认的静态加密，提供了额外的安全保障。 - 目前不支持使用 [客户自管加密密钥（CMEK）](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)。 ### 维护窗口 @@ -44,7 +44,7 @@ TiDB Cloud Starter 和 Essential 支持几乎所有 TiDB 支持的工作负载 ### 自助升级 -- TiDB Cloud Starter 和 TiDB Cloud Essential 是 TiDB 的全托管部署。TiDB Cloud Starter 和 TiDB Cloud Essential 的主版本和小版本升级由 TiDB Cloud 统一管理，用户无法自行发起升级。 +- TiDB Cloud Starter 和 TiDB Cloud Essential 是完全托管的 TiDB 部署。TiDB Cloud Starter 和 TiDB Cloud Essential 的主版本和小版本升级由 TiDB Cloud 统一管理，用户无法自行发起升级。 ### 流式数据 @@ -58,11 +58,11 @@ TiDB Cloud Starter 和 Essential 支持几乎所有 TiDB 支持的工作负载 ### 其他 - 事务持续时间不能超过 30 分钟。 -- 有关 SQL 限制的更多细节，请参阅 [Limited SQL Features](/tidb-cloud/limited-sql-features.md)。 +- 有关 SQL 限制的更多细节，请参阅 [受限 SQL 功能](/tidb-cloud/limited-sql-features.md)。 ## 使用配额 -在 TiDB Cloud 的每个组织中，默认最多可以创建 5 个 [免费 TiDB Cloud Starter 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)。如需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并为使用量 [设置每月消费额度](/tidb-cloud/manage-serverless-spend-limit.md)。 +在 TiDB Cloud 的每个组织中，默认最多可以创建 5 个 [免费 TiDB Cloud Starter 集群](/tidb-cloud/select-cluster-tier.md#starter)。如需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并为使用量 [设置每月消费限额](/tidb-cloud/manage-serverless-spend-limit.md)。 对于你组织中的前 5 个 TiDB Cloud Starter 集群，TiDB Cloud 为每个集群提供如下免费使用配额： @@ -70,12 +70,12 @@ TiDB Cloud Starter 和 Essential 支持几乎所有 TiDB 支持的工作负载 - 列存储：5 GiB - [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit)：每月 5000 万 RU -Request Unit（RU）是用于衡量查询或事务资源消耗的单位。它是一种指标，可以帮助你估算处理特定数据库请求所需的计算资源。Request Unit 也是 TiDB Cloud Starter 服务的计费单位。 +Request Unit（RU）是用于衡量查询或事务资源消耗的单位。它是一种指标，可以帮助你估算处理特定请求所需的计算资源。Request Unit 也是 TiDB Cloud Starter 服务的计费单位。 -一旦集群达到其使用配额，将立即拒绝所有新的连接尝试，直到你 [增加配额](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit) 或新月开始时用量被重置。已在达到配额前建立的连接会保持活跃，但会受到限流影响。 +一旦集群达到其使用配额，将立即拒绝所有新的连接尝试，直到你 [增加配额](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit) 或在新月开始时重置使用量。已在达到配额前建立的连接会保持活跃，但会受到限流影响。 -如需了解不同资源（包括读、写、SQL CPU 和网络出口）的 RU 消耗、定价详情及限流信息，请参阅 [TiDB Cloud Starter Pricing Details](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 +如需了解不同资源（包括读、写、SQL CPU 和网络出口）的 RU 消耗、定价详情及限流信息，请参阅 [TiDB Cloud Starter 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 -如果你希望创建配额更高的 TiDB Cloud Starter 集群，可以在集群创建页面设置每月消费额度。更多信息请参阅 [创建 TiDB Cloud Starter 集群](/tidb-cloud/create-tidb-cluster-serverless.md)。 +如果你希望为 TiDB Cloud Starter 集群设置额外配额，可以在集群创建页面设置每月消费限额。更多信息请参阅 [创建 TiDB Cloud Starter 集群](/tidb-cloud/create-tidb-cluster-serverless.md)。 -集群创建后，你仍然可以在集群概览页面查看和编辑消费额度。更多信息请参阅 [管理 TiDB Cloud Starter 集群的消费额度](/tidb-cloud/manage-serverless-spend-limit.md)。 \ No newline at end of file +创建 TiDB Cloud Starter 集群后，你仍然可以在集群概览页面查看和编辑消费限额。更多信息请参阅 [管理 TiDB Cloud Starter 集群的消费限额](/tidb-cloud/manage-serverless-spend-limit.md)。 \ No newline at end of file diff --git a/tidb-cloud/set-up-sink-private-endpoint.md b/tidb-cloud/set-up-sink-private-endpoint.md new file mode 100644 index 0000000000000..35a6147c2d667 --- /dev/null +++ b/tidb-cloud/set-up-sink-private-endpoint.md @@ -0,0 +1,127 @@ +--- +title: 为 Changefeed 设置私有端点 +summary: 了解如何为 changefeed 设置私有端点。 +--- + +# 为 Changefeed 设置私有端点 + +本文档介绍如何在你的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中创建 changefeed 的私有端点，使你能够通过私有连接安全地将数据流式传输到自托管的 Kafka 或 MySQL。 + +## 限制 + +在同一个 VPC 内，AWS 的每个 Private Endpoint Service、Google Cloud 的 Service Attachment 或 Azure 的 Private Link Service 最多可以有 5 个私有端点。如果超过此限制，请在创建新端点前移除未使用的私有端点。 + +## 前提条件 + +- 检查私有端点创建权限 +- 配置你的网络连接 + +### 权限 + +只有在你的组织中拥有以下任一角色的用户才能为 changefeed 创建私有端点： + +- `Organization Owner` +- `Project Owner` +- `Project Data Access Read-Write` + +关于 TiDB Cloud 中的角色详情，请参见 [用户角色](/tidb-cloud/manage-user-access.md#user-roles)。 + +### 网络 + +私有端点利用云服务商的 **Private Link** 或 **Private Service Connect** 技术，使你 VPC 内的资源能够通过私有 IP 地址连接到其他 VPC 的服务，就像这些服务直接托管在你的 VPC 内一样。 + + +
+ +如果你的 changefeed 下游服务托管在 AWS 上，请收集以下信息： + +- 下游服务的 Private Endpoint Service 名称 +- 下游服务部署的可用区（AZs） + +如果下游服务没有可用的 Private Endpoint Service，请按照 [步骤 2. 将 Kafka 集群暴露为 Private Link Service](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service) 设置负载均衡器和 Private Link Service。 + +
+ +
+ +如果你的 changefeed 下游服务托管在 Google Cloud 上，请收集下游服务的 Service Attachment 信息。 + +如果下游服务没有可用的 Service Attachment，请按照 [步骤 2. 将 Kafka-proxy 暴露为 Private Service Connect Service](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md#step-2-expose-kafka-proxy-as-private-service-connect-service) 获取 Service Attachment 信息。 + +
+ +
+ +如果你的 changefeed 下游服务托管在 Azure 上，请收集下游服务的 Private Link Service 别名。 + +如果下游服务没有可用的 Private Endpoint Service，请按照 [步骤 2. 将 Kafka 集群暴露为 Private Link Service](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service) 设置负载均衡器和 Private Link Service。 + +
+ + +## 步骤 1. 打开集群的 Networking 页面 + +1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)。 + +2. 在 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群名称进入其概览页面。 + + > **Tip:** + > + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 + +3. 在左侧导航栏，点击 **Settings** > **Networking**。 + +## 步骤 2. 配置 changefeed 的私有端点 + +根据你的集群部署的云服务商，配置步骤有所不同。 + + +
+ +1. 在 **Networking** 页面，点击 **AWS Private Endpoint for Changefeed** 区域的 **Create Private Endpoint**。 +2. 在 **Create Private Endpoint for Changefeed** 对话框中，输入私有端点的名称。 +3. 按照提示授权 TiDB Cloud 的 [AWS Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-accounts) 创建端点。 +4. 输入你在 [Network](#network) 部分收集的 **Endpoint Service Name**。 +5. 选择 **Number of AZs**。确保 AZ 数量和 AZ ID 与你的 Kafka 部署一致。 +6. 如果该私有端点用于 Apache Kafka，请启用 **Advertised Listener for Kafka** 选项。 +7. 使用 **TiDB Managed** 域名或 **Custom** 域名配置 Kafka 的 advertised listener。 + + - 若使用 **TiDB Managed** 域名作为 advertised listener，在 **Domain Pattern** 字段输入唯一字符串，然后点击 **Generate**。TiDB 会为每个可用区生成带有子域名的 broker 地址。 + - 若使用你自己的 **Custom** 域名作为 advertised listener，将域名类型切换为 **Custom**，在 **Custom Domain** 字段输入根域名，点击 **Check**，然后为每个可用区指定 broker 子域名。 + +8. 点击 **Create** 验证配置并创建私有端点。 + +
+ +
+ +1. 在 **Networking** 页面，点击 **Google Cloud Private Endpoint for Changefeed** 区域的 **Create Private Endpoint**。 +2. 在 **Create Private Endpoint for Changefeed** 对话框中，输入私有端点的名称。 +3. 按照提示授权 TiDB Cloud 的 [Google Cloud project](https://cloud.google.com/resource-manager/docs/creating-managing-projects) 预先批准端点创建，或在收到端点连接请求时手动批准。 +4. 输入你在 [Network](#network) 部分收集的 **Service Attachment**。 +5. 如果该私有端点用于 Apache Kafka，请启用 **Advertised Listener for Kafka** 选项。 +6. 使用 **TiDB Managed** 域名或 **Custom** 域名配置 Kafka 的 advertised listener。 + + - 若使用 **TiDB Managed** 域名作为 advertised listener，在 **Domain Pattern** 字段输入唯一字符串，然后点击 **Generate**。TiDB 会为每个可用区生成带有子域名的 broker 地址。 + - 若使用你自己的 **Custom** 域名作为 advertised listener，将域名类型切换为 **Custom**，在 **Custom Domain** 字段输入根域名，点击 **Check**，然后为每个可用区指定 broker 子域名。 + +7. 点击 **Create** 验证配置并创建私有端点。 + +
+ +
+ +1. 在 **Networking** 页面，点击 **Azure Private Endpoint for Changefeed** 区域的 **Create Private Endpoint**。 +2. 在 **Create Private Endpoint for Changefeed** 对话框中，输入私有端点的名称。 +3. 按照提示授权 TiDB Cloud 的 Azure 订阅，或在创建 changefeed 前允许任何拥有你别名的人访问你的 Private Link 服务。关于 Private Link 服务可见性的更多信息，请参见 Azure 文档中的 [Control service exposure](https://learn.microsoft.com/en-us/azure/private-link/private-link-service-overview#control-service-exposure)。 +4. 输入你在 [Network](#network) 部分收集的 **Alias of Private Link Service**。 +5. 如果该私有端点用于 Apache Kafka，请启用 **Advertised Listener for Kafka** 选项。 +6. 使用 **TiDB Managed** 域名或 **Custom** 域名配置 Kafka 的 advertised listener。 + + - 若使用 **TiDB Managed** 域名作为 advertised listener，在 **Domain Pattern** 字段输入唯一字符串，然后点击 **Generate**。TiDB 会为每个可用区生成带有子域名的 broker 地址。 + - 若使用你自己的 **Custom** 域名作为 advertised listener，将域名类型切换为 **Custom**，在 **Custom Domain** 字段输入根域名，点击 **Check**，然后为每个可用区指定 broker 子域名。 + +7. 点击 **Create** 验证配置并创建私有端点。 + +
+ \ No newline at end of file diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource.md b/tidb-cloud/terraform-use-serverless-cluster-resource.md index 2bbf372538cc2..26669b2f2a476 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource.md @@ -5,7 +5,7 @@ summary: 了解如何使用 `tidbcloud_serverless_cluster` 资源来创建和修 # 使用 `tidbcloud_serverless_cluster` 资源 -本文档介绍如何使用 `tidbcloud_serverless_cluster` 资源管理 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群。 +本文档介绍了如何使用 `tidbcloud_serverless_cluster` 资源管理 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群。 你还将学习如何通过 `tidbcloud_projects` 数据源获取所需的信息。 @@ -24,7 +24,7 @@ summary: 了解如何使用 `tidbcloud_serverless_cluster` 资源来创建和修 每个 TiDB 集群都属于一个项目。在创建 TiDB Cloud Starter 集群之前，你需要获取要创建集群的项目 ID。如果未指定 `project_id`，则会使用默认项目。 -要检索所有可用项目的信息，可以按如下方式使用 `tidbcloud_projects` 数据源： +要获取所有可用项目的信息，可以按如下方式使用 `tidbcloud_projects` 数据源： 1. 在你 [获取 TiDB Cloud Terraform Provider](/tidb-cloud/terraform-get-tidbcloud-provider.md) 时创建的 `main.tf` 文件中，添加如下的 `data` 和 `output` 块： @@ -54,19 +54,19 @@ summary: 了解如何使用 `tidbcloud_serverless_cluster` 资源来创建和修 - 使用 `data` 块定义 TiDB Cloud 的数据源，包括数据源类型和数据源名称。 - - 若要使用项目数据源，将数据源类型设置为 `tidbcloud_projects`。 + - 若要使用项目数据源，需将数据源类型设置为 `tidbcloud_projects`。 - 数据源名称可以根据需要自定义，例如 `"example_project"`。 - - 对于 `tidbcloud_projects` 数据源，可以使用 `page` 和 `page_size` 属性来限制你想要查看的最大项目数。 + - 对于 `tidbcloud_projects` 数据源，可以通过 `page` 和 `page_size` 属性限制你想要查看的最大项目数量。 - 使用 `output` 块定义要在输出中显示的数据源信息，并将信息暴露给其他 Terraform 配置使用。 - `output` 块的作用类似于编程语言中的返回值。更多详情可参考 [Terraform 官方文档](https://www.terraform.io/language/values/outputs)。 + `output` 块的作用类似于编程语言中的返回值。详见 [Terraform 官方文档](https://www.terraform.io/language/values/outputs)。 - 若要获取所有资源和数据源的可用配置，请参见 [Terraform provider 配置文档](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)。 + 若要获取所有资源和数据源的可用配置，参见 [Terraform provider 配置文档](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)。 2. 运行 `terraform apply` 命令以应用配置。你需要在确认提示时输入 `yes` 以继续。 - 若要跳过提示，可以使用 `terraform apply --auto-approve`： + 若要跳过确认提示，可以使用 `terraform apply --auto-approve`： ```shell $ terraform apply --auto-approve @@ -157,7 +157,7 @@ summary: 了解如何使用 `tidbcloud_serverless_cluster` 资源来创建和修 使用 `resource` 块定义 TiDB Cloud 的资源，包括资源类型、资源名称和资源详情。 - - 若要使用 `tidbcloud_serverless_cluster` 资源，将资源类型设置为 `tidbcloud_serverless_cluster`。 + - 若要使用 `tidbcloud_serverless_cluster` 资源，需将资源类型设置为 `tidbcloud_serverless_cluster`。 - 资源名称可以根据需要自定义，例如 `example`。 - 资源详情可根据项目 ID 及 [`tidbcloud_serverless_cluster` 规范](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/serverless_cluster) 进行配置。 @@ -211,9 +211,9 @@ summary: 了解如何使用 `tidbcloud_serverless_cluster` 资源来创建和修 - 你可以检查配置与当前状态之间的差异。 - 你还可以看到本次 `apply` 的结果。它将新增一个资源，不会有资源被更改或销毁。 - - `known after apply` 表示在 `apply` 之后你将获得对应的值。 + - `known after apply` 表示你将在 `apply` 后获得对应的值。 -4. 如果你的计划没有问题，输入 `yes` 继续： +4. 如果计划中的内容没有问题，输入 `yes` 继续： ```shell Do you want to perform these actions? @@ -423,7 +423,7 @@ resource "tidbcloud_serverless_cluster" "example" { 1. 为新的 `tidbcloud_serverless_cluster` 资源添加 import 块。 - 在你的 `.tf` 文件中添加如下 import 块，将 `example` 替换为你期望的资源名称，将 `${id}` 替换为集群 ID： + 在你的 `.tf` 文件中添加如下 import 块，将 `example` 替换为你想要的资源名称，将 `${id}` 替换为集群 ID： ``` import { @@ -446,7 +446,7 @@ resource "tidbcloud_serverless_cluster" "example" { 审查生成的配置文件，确保其符合你的需求。你也可以选择将该文件内容移动到你喜欢的位置。 - 然后，运行 `terraform apply` 导入你的基础设施。应用后，示例输出如下： + 然后运行 `terraform apply` 导入你的基础设施。应用后，示例输出如下： ```shell tidbcloud_serverless_cluster.example: Importing... diff --git a/tidb-cloud/third-party-monitoring-integrations.md b/tidb-cloud/third-party-monitoring-integrations.md index d9f382bf7fe9b..b08adc313c9ee 100644 --- a/tidb-cloud/third-party-monitoring-integrations.md +++ b/tidb-cloud/third-party-monitoring-integrations.md @@ -5,26 +5,26 @@ summary: 了解如何使用第三方指标集成。 # 第三方指标集成 -你可以将 TiDB Cloud 与以下第三方指标服务集成，在这些服务中接收 TiDB Cloud 警报并查看 TiDB 集群的性能指标： +你可以将 TiDB Cloud 与以下第三方指标服务集成，在这些服务中接收 TiDB Cloud 的告警并查看 TiDB 集群的性能指标： - [Datadog 集成](#datadog-集成) -- [Prometheus 和 Grafana 集成（Beta）](#prometheus-和-grafana-集成-beta) +- [Prometheus 和 Grafana 集成](#prometheus-和-grafana-集成) - [New Relic 集成](#new-relic-集成) ## Datadog 集成 -通过 Datadog 集成，你可以配置 TiDB Cloud，将关于 TiDB 集群的指标数据发送到 [Datadog](https://www.datadoghq.com/)，并在你的 Datadog 仪表盘中查看这些指标。 +通过 Datadog 集成，你可以配置 TiDB Cloud，将关于 TiDB 集群的指标数据发送到 [Datadog](https://www.datadoghq.com/)，并在 Datadog 的仪表盘中查看这些指标。 有关详细的集成步骤以及 Datadog 跟踪的指标列表，请参考 [Integrate TiDB Cloud with Datadog](/tidb-cloud/monitor-datadog-integration.md)。 -## Prometheus 和 Grafana 集成（Beta） +## Prometheus 和 Grafana 集成 -通过 Prometheus 和 Grafana 集成，你可以从 TiDB Cloud 获取一个用于 Prometheus 的 `scrape_config` 文件，并使用该文件中的内容来配置 Prometheus。你可以在你的 Grafana 仪表盘中查看这些指标。 +通过 Prometheus 和 Grafana 集成，你可以从 TiDB Cloud 获取一个用于 Prometheus 的 `scrape_config` 文件，并使用该文件中的内容来配置 Prometheus。你可以在 Grafana 的仪表盘中查看这些指标。 有关详细的集成步骤以及 Prometheus 跟踪的指标列表，请参见 [Integrate TiDB Cloud with Prometheus and Grafana](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)。 ## New Relic 集成 -通过 New Relic 集成，你可以配置 TiDB Cloud，将关于 TiDB 集群的指标数据发送到 [New Relic](https://newrelic.com/)，并在你的 New Relic 仪表盘中查看这些指标。 +通过 New Relic 集成，你可以配置 TiDB Cloud，将关于 TiDB 集群的指标数据发送到 [New Relic](https://newrelic.com/)，并在 New Relic 的仪表盘中查看这些指标。 有关详细的集成步骤以及 New Relic 跟踪的指标列表，请参见 [Integrate TiDB Cloud with New Relic](/tidb-cloud/monitor-new-relic-integration.md)。 \ No newline at end of file diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index bbc00bb2d2b10..a80e6726927dd 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -13,57 +13,57 @@ aliases: ['/tidbcloud/glossary'] ACID 指的是事务的四个关键特性：原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。每个特性如下所述。 -- **Atomicity** 表示一个操作的所有更改要么全部执行，要么全部不执行。TiDB 通过保证存储主键的 [TiDB Region](#region) 的原子性来实现事务的原子性。 +- **原子性** 意味着一个操作的所有更改要么全部执行，要么全部不执行。TiDB 通过保证存储主键的 [TiDB Region](#region) 的原子性来实现事务的原子性。 -- **Consistency** 表示事务总是将数据库从一个一致的状态转变为另一个一致的状态。在 TiDB 中，数据在写入内存前会确保一致性。 +- **一致性** 意味着事务总是将数据库从一个一致的状态转变为另一个一致的状态。在 TiDB 中，数据在写入内存前会确保一致性。 -- **Isolation** 表示正在进行的事务对其他事务是不可见的，直到其完成。这允许并发事务在不牺牲一致性的情况下读写数据。TiDB 目前支持 `REPEATABLE READ` 隔离级别。 +- **隔离性** 意味着正在进行的事务在完成之前对其他事务是不可见的。这允许并发事务在不牺牲一致性的情况下读写数据。TiDB 目前支持 `REPEATABLE READ` 隔离级别。 -- **Durability** 表示一旦事务提交，即使系统发生故障也会保持已提交状态。TiKV 通过持久化存储来保证持久性。 +- **持久性** 意味着一旦事务提交，即使系统发生故障也会保持提交状态。TiKV 使用持久化存储来保证持久性。 ## C ### Chat2Query -Chat2Query 是集成在 SQL Editor 中的 AI 驱动功能，能够帮助用户通过自然语言指令生成、调试或重写 SQL 查询。更多信息，参见 [使用 AI 辅助 SQL Editor 探索数据](/tidb-cloud/explore-data-with-chat2query.md)。 +Chat2Query 是集成在 SQL 编辑器中的一项 AI 驱动功能，能够帮助用户通过自然语言指令生成、调试或重写 SQL 查询。更多信息，参见 [使用 AI 辅助 SQL 编辑器探索数据](/tidb-cloud/explore-data-with-chat2query.md)。 -此外，TiDB Cloud 为托管在 AWS 上的 TiDB Cloud Starter 集群提供 Chat2Query API。启用后，TiDB Cloud 会自动创建一个名为 **Chat2Query** 的系统 Data App，并在 Data Service 中创建一个 Chat2Data endpoint。你可以调用该 endpoint，通过指令让 AI 生成并执行 SQL 语句。更多信息，参见 [开始使用 Chat2Query API](/tidb-cloud/use-chat2query-api.md)。 +此外，TiDB Cloud 为托管在 AWS 上的 TiDB Cloud Starter 集群提供了 Chat2Query API。启用后，TiDB Cloud 会自动创建一个名为 **Chat2Query** 的系统 Data App，并在 Data Service 中创建一个 Chat2Data 端点。你可以调用该端点，通过提供指令让 AI 生成并执行 SQL 语句。更多信息，参见 [开始使用 Chat2Query API](/tidb-cloud/use-chat2query-api.md)。 ### Credit -TiDB Cloud 为概念验证（PoC）用户提供一定数量的 credit。一个 credit 等同于一美元。你可以在 credit 过期前使用它们支付 TiDB 集群费用。 +TiDB Cloud 为概念验证（PoC）用户提供一定数量的 Credit。一个 Credit 等同于一美元。你可以在 Credit 过期前使用它们支付 TiDB 集群费用。 ## D ### Data App -[Data Service (beta)](#data-service) 中的 Data App 是一组 endpoint 的集合，你可以用它来访问特定应用的数据。你可以通过 API key 配置授权设置，限制对 Data App 中 endpoint 的访问。 +[Data Service (beta)](#data-service) 中的 Data App 是一组端点的集合，你可以用来访问特定应用的数据。你可以通过 API 密钥配置授权设置，以限制对 Data App 中端点的访问。 更多信息，参见 [管理 Data App](/tidb-cloud/data-service-manage-data-app.md)。 ### Data Service -Data Service (beta) 允许你通过自定义 API [endpoint](#endpoint) 以 HTTPS 请求方式访问 TiDB Cloud 数据。该功能采用无服务器架构，自动处理计算资源和弹性扩缩容，因此你可以专注于 endpoint 的查询逻辑，无需担心基础设施或运维成本。 +Data Service (beta) 允许你通过自定义 API [端点](#endpoint) 以 HTTPS 请求方式访问 TiDB Cloud 数据。该功能采用无服务器架构来处理计算资源和弹性扩缩容，因此你可以专注于端点中的查询逻辑，而无需担心基础设施或运维成本。 更多信息，参见 [Data Service 概览](/tidb-cloud/data-service-overview.md)。 ### Direct Customer -Direct customer 指直接从 PingCAP 购买 TiDB Cloud 并直接支付账单的最终客户。与 [MSP customer](#msp-customer) 区分。 +Direct Customer（直接客户）指的是直接从 PingCAP 购买 TiDB Cloud 并直接支付账单的最终客户。这与 [MSP 客户](#msp-customer) 区别开来。 ## E ### Endpoint -Data Service 中的 endpoint 是你可以自定义以执行 SQL 语句的 Web API。你可以为 SQL 语句指定参数，例如 `WHERE` 子句中使用的值。当客户端调用 endpoint 并在请求 URL 中提供参数值时，endpoint 会使用这些参数执行相应的 SQL 语句，并将结果作为 HTTP 响应的一部分返回。 +Data Service 中的端点是你可以自定义以执行 SQL 语句的 Web API。你可以为 SQL 语句指定参数，例如 `WHERE` 子句中使用的值。当客户端调用端点并在请求 URL 中提供参数值时，端点会使用这些参数执行相应的 SQL 语句，并将结果作为 HTTP 响应的一部分返回。 -更多信息，参见 [管理 endpoint](/tidb-cloud/data-service-manage-endpoint.md)。 +更多信息，参见 [管理端点](/tidb-cloud/data-service-manage-endpoint.md)。 ## F -### Full-text search +### 全文检索（Full-text search） -与关注语义相似度的 [Vector Search](/vector-search/vector-search-overview.md) 不同，全文检索允许你根据精确关键字检索文档。在 RAG（Retrieval-Augmented Generation）场景下，你可以将全文检索与向量检索结合使用，以提升检索质量。 +与关注语义相似度的 [向量检索](/vector-search/vector-search-overview.md) 不同，全文检索允许你根据精确关键词检索文档。在 RAG（Retrieval-Augmented Generation，检索增强生成）场景中，你可以将全文检索与向量检索结合使用，以提升检索质量。 更多信息，参见 [使用 SQL 进行全文检索](/tidb-cloud/vector-search-full-text-search-sql.md) 和 [使用 Python 进行全文检索](/tidb-cloud/vector-search-full-text-search-python.md)。 @@ -75,15 +75,15 @@ Data Service 中的 endpoint 是你可以自定义以执行 SQL 语句的 Web AP ### MPP -自 v5.0 起，TiDB 通过 TiFlash 节点引入了大规模并行处理（Massively Parallel Processing, MPP）架构，将大型 Join 查询的执行负载分摊到多个 TiFlash 节点。当启用 MPP 模式时，TiDB 会根据成本判断是否使用 MPP 框架进行计算。在 MPP 模式下，Join 键在计算过程中通过 Exchange 操作重新分布，将计算压力分散到每个 TiFlash 节点，从而加速计算。更多信息，参见 [使用 TiFlash MPP 模式](/tiflash/use-tiflash-mpp-mode.md)。 +从 v5.0 开始，TiDB 通过 TiFlash 节点引入了大规模并行处理（Massively Parallel Processing，MPP）架构，将大型 Join 查询的执行负载分摊到多个 TiFlash 节点。当启用 MPP 模式时，TiDB 会根据成本判断是否使用 MPP 框架进行计算。在 MPP 模式下，Join 键会在计算过程中通过 Exchange 操作重新分布，将计算压力分散到每个 TiFlash 节点，从而加速计算。更多信息，参见 [使用 TiFlash MPP 模式](/tiflash/use-tiflash-mpp-mode.md)。 ### MSP Customer -MSP customer（托管服务提供商客户）指通过 MSP 渠道购买 TiDB Cloud 并通过 MSP 支付账单的最终客户。与 [direct customer](#direct-customer) 区分。 +MSP 客户（Managed Service Provider Customer）指的是通过 MSP 渠道购买 TiDB Cloud 并通过 MSP 支付账单的最终客户。这与 [直接客户](#direct-customer) 区别开来。 ### Managed Service Provider (MSP) -托管服务提供商（MSP）是指转售 TiDB Cloud 并提供增值服务（包括但不限于 TiDB Cloud 组织管理、计费服务和技术支持）的合作伙伴。 +MSP（托管服务提供商）是指转售 TiDB Cloud 并提供增值服务的合作伙伴，包括但不限于 TiDB Cloud 组织管理、计费服务和技术支持。 ## N @@ -117,15 +117,15 @@ MSP customer（托管服务提供商客户）指通过 MSP 渠道购买 TiDB Clo ## R -### Recycle Bin +### 回收站（Recycle Bin） -用于存放已删除集群且有有效备份的数据的地方。一旦已备份的 TiDB Cloud 专属集群被删除，该集群现有的备份文件会被移动到回收站。对于自动备份产生的备份文件，回收站会保留指定时间。你可以在 **Backup Setting** 中配置备份保留时间，默认是 7 天。对于手动备份产生的备份文件，则没有过期时间。为避免数据丢失，请及时将数据恢复到新集群。注意，如果集群 **没有备份**，则删除的集群不会显示在此处。 +用于存放已删除集群且有有效备份的数据。当已备份的 TiDB Cloud 专属集群被删除后，该集群现有的备份文件会被移动到回收站。对于自动备份产生的备份文件，回收站会保留指定时间。你可以在 **备份设置** 中配置备份保留时间，默认是 7 天。对于手动备份产生的备份文件，则没有过期时间。为避免数据丢失，请及时将数据恢复到新集群。注意，如果集群 **没有备份**，则删除的集群不会在此处显示。 ### region - TiDB Cloud region - 部署 TiDB Cloud 集群的地理区域。一个 TiDB Cloud region 至少包含 3 个可用区，集群会跨这些可用区部署。 + TiDB Cloud 集群部署的地理区域。一个 TiDB Cloud region 至少包含 3 个可用区，集群会跨这些可用区部署。 - TiDB Region @@ -133,31 +133,31 @@ MSP customer（托管服务提供商客户）指通过 MSP 渠道购买 TiDB Clo ### replica -可以位于同一区域或不同区域的独立数据库，包含相同的数据。replica 通常用于灾备或提升性能。 +可以位于同一区域或不同区域的独立数据库，包含相同的数据。副本通常用于灾备或提升性能。 -### Replication Capacity Unit +### Replication Capacity Unit (RCU) -变更数据流（changefeed）的复制按计算资源计费，即 TiCDC 复制能力单元。 +TiDB Cloud 以 TiCDC 复制容量单位（Replication Capacity Unit，RCU）来衡量 [changefeed](/tidb-cloud/changefeed-overview.md) 的容量。为集群创建 changefeed 时，你可以选择合适的规格。RCU 越高，复制性能越好。你需要为这些 TiCDC changefeed RCU 支付费用。更多信息，参见 [Changefeed Cost](https://www.pingcap.com/tidb-dedicated-pricing-details/#changefeed-cost)。 -### Request Capacity Unit +### Request Capacity Unit (RCU) -Request Capacity Unit（RCU）是用于表示为 TiDB Cloud Essential 集群预置的计算能力的计量单位。一个 RCU 提供固定数量的计算资源，可每秒处理一定数量的 RU。你预置的 RCU 数量决定了集群的基线性能和吞吐能力。更多信息，参见 [TiDB Cloud Essential 计费详情](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)。 +Request Capacity Unit（RCU）是用于表示为 TiDB Cloud Essential 集群预配的计算能力的度量单位。一个 RCU 提供固定数量的计算资源，可每秒处理一定数量的 RU。你预配的 RCU 数量决定了集群的基线性能和吞吐能力。更多信息，参见 [TiDB Cloud Essential 价格详情](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)。 ### Request Unit -Request Unit（RU）是用于表示单个数据库请求消耗的资源量的计量单位。一个请求消耗的 RU 数量取决于多种因素，如操作类型或检索/修改的数据量。更多信息，参见 [TiDB Cloud Starter 计费详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 +Request Unit（RU）是用于表示单个数据库请求消耗的资源量的度量单位。一个请求消耗的 RU 数量取决于多种因素，如操作类型或检索/修改的数据量。更多信息，参见 [TiDB Cloud Starter 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 ## S ### Spending limit -[Spending limit](/tidb-cloud/manage-serverless-spend-limit.md) 指你愿意在某个工作负载上每月花费的最大金额。它是一种成本控制机制，使你可以为 TiDB Cloud Starter 集群设置预算。如果 spending limit 设置为 0，集群将保持免费。如果 spending limit 大于 0，则需要添加信用卡。 +[Spending limit](/tidb-cloud/manage-serverless-spend-limit.md) 指的是你愿意在某个工作负载上每月花费的最大金额。它是一种成本控制机制，使你可以为 TiDB Cloud Starter 集群设置预算。如果支出上限设置为 0，集群将保持免费。如果支出上限大于 0，则需要添加信用卡。 ## T ### TiDB cluster -由 [TiDB](https://docs.pingcap.com/tidb/stable/tidb-computing)、[TiKV](https://docs.pingcap.com/tidb/stable/tidb-storage)、[the Placement Driver](https://docs.pingcap.com/tidb/stable/tidb-scheduling)（PD）和 [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview) 节点组成的功能性数据库集群。 +由 [TiDB](https://docs.pingcap.com/tidb/stable/tidb-computing)、[TiKV](https://docs.pingcap.com/tidb/stable/tidb-storage)、[Placement Driver](https://docs.pingcap.com/tidb/stable/tidb-scheduling)（PD）和 [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview) 节点组成的功能性数据库集群。 ### TiDB node @@ -165,11 +165,11 @@ Request Unit（RU）是用于表示单个数据库请求消耗的资源量的计 ### TiFlash node -实时从 TiKV 复制数据并支持实时分析型负载的分析型存储节点。 +实时从 TiKV 复制数据并支持实时分析型工作负载的分析型存储节点。 ### TiKV node -存储联机事务处理（OLTP）数据的存储节点。以 3 的倍数（如 3、6、9）进行扩容以实现高可用，其中两个节点作为副本。增加 TiKV 节点数量可以提升总吞吐量。 +存储在线事务处理（OLTP）数据的存储节点。以 3 的倍数（如 3、6、9）进行扩容以实现高可用，其中两个节点作为副本。增加 TiKV 节点数量可以提升总吞吐量。 ### traffic filter @@ -177,13 +177,13 @@ Request Unit（RU）是用于表示单个数据库请求消耗的资源量的计 ## V -### Vector search +### 向量检索（Vector search） -[Vector search](/vector-search/vector-search-overview.md) 是一种以数据语义为核心、提供相关性结果的检索方式。与依赖精确关键字匹配和词频的传统全文检索不同，向量检索会将多种数据类型（如文本、图片或音频）转换为高维向量，并基于这些向量之间的相似度进行查询。这种检索方式能够捕捉数据的语义和上下文信息，更准确地理解用户意图。即使检索词与数据库内容不完全匹配，向量检索也能通过分析数据语义，返回符合用户意图的结果。 +[向量检索](/vector-search/vector-search-overview.md) 是一种以数据语义为核心、提供相关性结果的检索方式。与依赖精确关键词匹配和词频的传统全文检索不同，向量检索会将多种数据类型（如文本、图片或音频）转换为高维向量，并基于这些向量之间的相似度进行查询。这种检索方式能够捕捉数据的语义含义和上下文信息，更准确地理解用户意图。即使检索词与数据库内容不完全匹配，向量检索也能通过分析数据语义，返回符合用户意图的结果。 ### Virtual Private Cloud -为你的资源提供托管网络服务的逻辑隔离虚拟网络分区。 +逻辑隔离的虚拟网络分区，为你的资源提供托管的网络服务。 ### VPC diff --git a/tidb-cloud/tidb-cloud-intro.md b/tidb-cloud/tidb-cloud-intro.md index 7139b3f902407..89f78fd0d7d25 100644 --- a/tidb-cloud/tidb-cloud-intro.md +++ b/tidb-cloud/tidb-cloud-intro.md @@ -6,15 +6,15 @@ category: intro # 什么是 TiDB Cloud -[TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 是一款全托管的数据库即服务（DBaaS），将 [TiDB](https://docs.pingcap.com/tidb/stable/overview) —— 一个开源的 HTAP（混合事务与分析处理）数据库 —— 带到你的云端。TiDB Cloud 提供了一种简单的方式来部署和管理数据库，让你专注于应用开发，而无需关注数据库的复杂性。你可以在 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和阿里云上创建 TiDB Cloud 集群，快速构建关键业务应用。You can create TiDB Cloud clusters to quickly build mission-critical applications on Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. +[TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 是一款全托管的数据库即服务（DBaaS），将 [TiDB](https://docs.pingcap.com/tidb/stable/overview) —— 一个开源的 HTAP（混合事务与分析处理）数据库 —— 带到你的云端。TiDB Cloud 提供了一种简单的方式来部署和管理数据库，让你专注于应用程序本身，而无需关注数据库的复杂性。你可以在 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和阿里云上创建 TiDB Cloud 集群，快速构建关键业务应用。You can create TiDB Cloud clusters to quickly build mission-critical applications on Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. -![TiDB Cloud Overview](/media/tidb-cloud/tidb-cloud-overview.png) +![TiDB Cloud 概览](/media/tidb-cloud/tidb-cloud-overview.png) ## 为什么选择 TiDB Cloud TiDB Cloud 让你几乎无需培训即可轻松处理如基础设施管理和集群部署等复杂任务。 -- 开发者和数据库管理员（DBA）可以轻松应对大量在线流量，并快速分析跨多个数据集的大规模数据。 +- 开发者和数据库管理员（DBA）可以轻松应对大量在线流量，并能快速分析跨多个数据集的大规模数据。 - 各类规模的企业都可以轻松部署和管理 TiDB Cloud，无需预付费用，灵活应对业务增长。 @@ -26,7 +26,7 @@ TiDB Cloud 让你几乎无需培训即可轻松处理如基础设施管理和集 - **Fast and Customized Scaling** - 弹性且透明地扩展到数百个节点以应对关键业务负载，同时保持 ACID 事务。无需进行分片操作。你还可以根据业务需求分别扩展计算节点和存储节点。 + 弹性且透明地扩展至数百个节点以应对关键负载，同时保持 ACID 事务。无需进行分片操作。你还可以根据业务需求分别扩展计算节点和存储节点。 - **MySQL Compatibility** @@ -64,7 +64,7 @@ TiDB Cloud 让你几乎无需培训即可轻松处理如基础设施管理和集 - **Simple Pricing Plans** - 只为实际使用量付费，价格透明，无隐藏费用。 + 只为实际使用的资源付费，价格透明，无隐藏费用。 - **World-Class Support** @@ -74,7 +74,7 @@ TiDB Cloud 让你几乎无需培训即可轻松处理如基础设施管理和集 TiDB Cloud 提供以下部署选项： -- TiDB Cloud Serverless（现已更名为 Starter） +- TiDB Cloud Starter TiDB Cloud Starter 是一款全托管的多租户 TiDB 服务。它提供即时、自动扩缩容的 MySQL 兼容数据库，并在超出免费额度后按用量计费。 @@ -110,13 +110,13 @@ TiDB Cloud 提供以下部署选项： ## 架构 -![TiDB Cloud architecture](/media/tidb-cloud/tidb-cloud-architecture.png) +![TiDB Cloud 架构](/media/tidb-cloud/tidb-cloud-architecture.png) - TiDB VPC（虚拟私有云） - 对于每个 TiDB Cloud 集群，所有 TiDB 节点及辅助节点（包括 TiDB Operator 节点和日志节点）都部署在同一个 VPC 中。 + 对于每个 TiDB Cloud 集群，所有 TiDB 节点及辅助节点（包括 TiDB Operator 节点和日志节点）都部署在同一个 VPC 内。 -- TiDB Cloud Central Services +- TiDB Cloud 中央服务 中央服务（包括计费、告警、元数据存储、Dashboard UI 等）独立部署。你可以通过互联网访问 Dashboard UI 来操作 TiDB 集群。 diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md index d4eb9064e7754..5fba856d44e87 100644 --- a/tidb-cloud/tidb-cloud-poc.md +++ b/tidb-cloud/tidb-cloud-poc.md @@ -5,15 +5,15 @@ summary: 了解如何使用 TiDB Cloud 进行概念验证（PoC）。 # 使用 TiDB Cloud 进行概念验证（PoC） -TiDB Cloud 是一款数据库即服务（DBaaS）产品，将 TiDB 的所有优势以全托管云数据库的形式交付。它帮助你专注于应用程序开发，而无需关注数据库的复杂性。TiDB Cloud 目前可在 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和阿里云上使用。TiDB Cloud is currently available on Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. +TiDB Cloud 是一款数据库即服务（DBaaS）产品，将 TiDB 的所有优势以全托管云数据库的形式交付。它帮助你专注于应用程序开发，而无需关注数据库的复杂性。TiDB Cloud 目前支持 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和阿里云。TiDB Cloud is currently available on Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. -发起概念验证（PoC）是判断 TiDB Cloud 是否适合你业务需求的最佳方式。通过 PoC，你还可以在短时间内熟悉 TiDB Cloud 的关键特性。通过运行性能测试，你可以评估你的业务负载是否能高效运行在 TiDB Cloud 上，同时也能评估数据迁移和配置适配所需的工作量。 +发起概念验证（PoC）是判断 TiDB Cloud 是否适合你业务需求的最佳方式。通过 PoC，你还可以在短时间内熟悉 TiDB Cloud 的关键特性。通过运行性能测试，你可以评估你的业务负载在 TiDB Cloud 上的运行效率，并评估数据迁移和配置适配所需的工作量。 本文档介绍了典型的 PoC 流程，旨在帮助你快速完成 TiDB Cloud 的 PoC。这是经过 TiDB 专家和大量客户验证的最佳实践。 -如果你有意进行 PoC，欢迎在开始前联系 PingCAP。支持团队可以帮助你制定测试计划，并顺利引导你完成 PoC 流程。 +如果你有意进行 PoC，欢迎在开始前联系 PingCAP。支持团队可以帮助你制定测试计划，并协助你顺利完成 PoC 流程。 -你也可以[创建 TiDB Cloud Starter](/tidb-cloud/tidb-cloud-quickstart.md#step-1-create-a-tidb-cluster) 快速体验 TiDB Cloud 进行初步评估。请注意，TiDB Cloud Starter 有一些[特殊条款和条件](/tidb-cloud/serverless-limitations.md)。 +你也可以[创建 TiDB Cloud Starter](/tidb-cloud/tidb-cloud-quickstart.md#step-1-create-a-tidb-cluster) 以快速体验和评估 TiDB Cloud。请注意，TiDB Cloud Starter 有一些[特殊条款和条件](/tidb-cloud/serverless-limitations.md)。 ## PoC 流程概览 @@ -38,8 +38,8 @@ PoC 的目的是测试 TiDB Cloud 是否满足你的业务需求。一个典型 - 你的业务负载场景是什么？ - 你的业务数据集规模或负载是多少？增长速度如何？ -- 性能需求是什么，包括关键业务的吞吐量或延迟要求？ -- 可用性和稳定性需求是什么，包括可接受的计划内或计划外停机时间的最小值？ +- 性能要求是什么，包括关键业务的吞吐量或延迟要求？ +- 可用性和稳定性要求是什么，包括可接受的计划内或计划外停机时间？ - 运营效率需要关注哪些指标？你如何衡量这些指标？ - 你的业务负载有哪些安全和合规性要求？ @@ -47,7 +47,7 @@ PoC 的目的是测试 TiDB Cloud 是否满足你的业务需求。一个典型 ## 第 2 步：明确你的业务负载特性 -TiDB Cloud 适用于需要高可用性、强一致性和大数据量的多种场景。[TiDB 简介](https://docs.pingcap.com/tidb/stable/overview) 列出了关键特性和应用场景。你可以检查这些特性是否适用于你的业务场景： +TiDB Cloud 适用于需要高可用性、强一致性和大数据量的多种场景。[TiDB 简介](https://docs.pingcap.com/tidb/stable/overview) 列出了关键特性和适用场景。你可以检查这些特性是否适用于你的业务场景： - 水平扩展和缩容 - 金融级高可用性 @@ -62,14 +62,14 @@ TiDB Cloud 适用于需要高可用性、强一致性和大数据量的多种场 1. 通过以下任一方式填写 PoC 申请表： - - 在 PingCAP 官网，访问 [申请 PoC](https://pingcap.com/apply-for-poc/) 页面填写申请表。 - - 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，点击右下角的 **?**，选择 **Contact Sales**，然后选择 **Apply for PoC** 填写申请表。 + - 在 PingCAP 官网，访问 [申请 PoC](https://pingcap.com/apply-for-poc/) 页面并填写申请表。 + - 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，点击右下角的 **?**，选择 **Contact Sales**，然后选择 **Apply for PoC** 并填写申请表。 - 提交表单后，TiDB Cloud 支持团队会审核你的申请，与你联系，并在申请通过后将额度发放到你的账户。你也可以联系 PingCAP 支持工程师协助你的 PoC 流程，确保 PoC 顺利进行。 + 提交申请后，TiDB Cloud 支持团队会审核你的申请，与你联系，并在申请通过后将额度发放到你的账户。你也可以联系 PingCAP 支持工程师协助你的 PoC 流程，确保 PoC 顺利进行。 2. 参考 [创建 TiDB Cloud Dedicated 集群](/tidb-cloud/create-tidb-cluster.md) 为 PoC 创建 TiDB Cloud Dedicated 集群。 - > **Note:** + > **注意：** > > 在创建 TiDB Cloud Dedicated 集群前，你必须添加以下任一付款方式： > - 按照集群创建页面的指引添加信用卡。 @@ -78,7 +78,7 @@ TiDB Cloud 适用于需要高可用性、强一致性和大数据量的多种场 > > 你的 PoC 额度会自动用于抵扣 PoC 期间产生的合规费用。 -在创建集群前，建议进行容量规划以确定集群规模。你可以根据预估的 TiDB、TiKV 或 TiFlash 节点数量起步，后续根据性能需求进行扩容。你可以参考以下文档或咨询我们的支持团队获取更多细节。 +在创建集群前，建议进行容量规划。你可以根据预估的 TiDB、TiKV 或 TiFlash 节点数量起步，后续根据性能需求进行扩容。你可以参考以下文档或咨询我们的支持团队获取更多细节。 - 有关容量预估的最佳实践，参见 [Size Your TiDB](/tidb-cloud/size-your-cluster.md)。 - 有关 TiDB Cloud Dedicated 集群的配置，参见 [创建 TiDB Cloud Dedicated 集群](/tidb-cloud/create-tidb-cluster.md)。分别为 TiDB、TiKV 和 TiFlash（可选）配置集群规模。 @@ -87,7 +87,7 @@ TiDB Cloud 适用于需要高可用性、强一致性和大数据量的多种场 当专用 PoC 集群创建完成后，你就可以加载数据并进行一系列测试。关于如何连接 TiDB 集群，参见 [连接 TiDB Cloud Dedicated 集群](/tidb-cloud/connect-to-tidb-cluster.md)。 -对于新创建的集群，请注意以下配置： +对于新建集群，请注意以下配置： - 默认时区（Dashboard 上的 **Create Time** 列）为 UTC。你可以按照 [设置本地时区](/tidb-cloud/manage-user-access.md#set-the-time-zone-for-your-organization) 将其更改为本地时区。 - 新集群的默认备份设置为每日全库备份。你可以指定首选备份时间或手动备份数据。关于默认备份时间及更多细节，参见 [备份与恢复 TiDB 集群数据](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)。 @@ -96,7 +96,7 @@ TiDB Cloud 适用于需要高可用性、强一致性和大数据量的多种场 接下来，你可以将数据库结构（包括表和索引）加载到 TiDB 集群。 -由于 PoC 额度有限，为了最大化额度价值，建议你创建一个 [TiDB Cloud Starter 集群](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 用于兼容性测试和初步分析。 +由于 PoC 额度有限，为了最大化额度价值，建议你创建 [TiDB Cloud Starter 集群](/tidb-cloud/select-cluster-tier.md#starter) 进行兼容性测试和初步分析。 TiDB Cloud 高度兼容 MySQL 8.0。如果你的数据源兼容 MySQL 或可以适配为兼容 MySQL，可以直接导入数据到 TiDB。 @@ -109,10 +109,10 @@ TiDB Cloud 高度兼容 MySQL 8.0。如果你的数据源兼容 MySQL 或可以 以下是一些最佳实践： -- 检查数据库结构设计是否存在低效之处。 +- 检查结构设计中是否存在低效问题。 - 移除不必要的索引。 - 规划分区策略，实现有效分区。 -- 避免由于右侧索引增长（如时间戳索引）导致的[热点问题](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#identify-hotspot-issues)。 +- 避免因右侧索引增长（如基于时间戳的索引）导致的[热点问题](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#identify-hotspot-issues)。 - 通过使用 [SHARD_ROW_ID_BITS](https://docs.pingcap.com/tidb/stable/shard-row-id-bits) 和 [AUTO_RANDOM](https://docs.pingcap.com/tidb/stable/auto-random) 避免[热点问题](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#identify-hotspot-issues)。 对于 SQL 语句，你可能需要根据数据源与 TiDB 的兼容性程度进行适配。 @@ -121,7 +121,7 @@ TiDB Cloud 高度兼容 MySQL 8.0。如果你的数据源兼容 MySQL 或可以 ## 第 5 步：导入数据 -你可以导入小数据集以快速测试可行性，也可以导入大数据集以测试 TiDB 数据迁移工具的吞吐能力。虽然 TiDB 提供了示例数据，但强烈建议你使用真实业务负载进行测试。 +你可以导入小规模数据集以快速测试可行性，也可以导入大规模数据集以测试 TiDB 数据迁移工具的吞吐能力。虽然 TiDB 提供了示例数据，但强烈建议你使用真实业务负载进行测试。 你可以将多种格式的数据导入 TiDB Cloud： @@ -131,19 +131,19 @@ TiDB Cloud 高度兼容 MySQL 8.0。如果你的数据源兼容 MySQL 或可以 - [从云存储导入 CSV 文件](/tidb-cloud/import-csv-files.md) - [导入 Apache Parquet 文件](/tidb-cloud/import-parquet-files.md) -> **Note:** +> **注意：** > -> 在 **Import** 页面导入数据不会产生额外的计费费用。 +> 在 **Import** 页面进行数据导入不会产生额外计费费用。 ## 第 6 步：运行业务负载并评估结果 -现在你已经创建了环境、适配了数据库结构并导入了数据，是时候测试你的业务负载了。 +现在你已经创建好环境，适配了结构并导入了数据，可以开始测试你的业务负载。 -在测试业务负载前，建议先手动备份一次，这样在需要时可以将数据库恢复到初始状态。更多信息参见 [备份与恢复 TiDB 集群数据](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)。 +在测试负载前，建议先进行一次手动备份，以便在需要时可以将数据库恢复到初始状态。更多信息参见 [备份与恢复 TiDB 集群数据](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)。 启动业务负载后，你可以通过以下方式观察系统： -- 集群常用指标可在集群概览页面查看，包括 Total QPS、Latency、Connections、TiFlash Request QPS、TiFlash Request Duration、TiFlash Storage Size、TiKV Storage Size、TiDB CPU、TiKV CPU、TiKV IO Read 和 TiKV IO Write。参见 [监控 TiDB 集群](/tidb-cloud/monitor-tidb-cluster.md)。 +- 集群概览页面展示了常用指标，包括 Total QPS、Latency、Connections、TiFlash Request QPS、TiFlash Request Duration、TiFlash Storage Size、TiKV Storage Size、TiDB CPU、TiKV CPU、TiKV IO Read 和 TiKV IO Write。参见 [监控 TiDB 集群](/tidb-cloud/monitor-tidb-cluster.md)。 - 进入集群的 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页面，查看 **SQL Statement** 标签页，可以观察 SQL 执行情况，无需查询系统表即可定位性能问题。参见 [SQL 语句分析](/tidb-cloud/tune-performance.md#statement-analysis)。 - 进入集群的 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页面，查看 **Key Visualizer** 标签页，可以查看 TiDB 的数据访问模式和数据热点。参见 [Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer)。 - 你还可以将这些指标集成到自己的 Datadog 和 Prometheus。参见 [第三方监控集成](/tidb-cloud/third-party-monitoring-integrations.md)。 @@ -158,25 +158,25 @@ TiDB Cloud 高度兼容 MySQL 8.0。如果你的数据源兼容 MySQL 或可以 - 排查并优化 SQL 性能。 - 监控并[解决热点问题](https://docs.pingcap.com/tidb/dev/troubleshoot-hot-spot-issues#troubleshoot-hotspot-issues)。 -- 评估存储容量和 CPU 使用率，并据此扩容或缩容 TiDB 集群。扩容细节参见 [FAQ](#faq) 部分。 +- 评估存储容量和 CPU 使用率，并据此扩容或缩容 TiDB 集群。扩容细节可参考 [FAQ](#faq) 部分。 以下是性能调优建议： -- 提高写入性能 +- 提升写入性能 - 通过扩容 TiDB 集群提升写入吞吐量（参见 [扩容 TiDB 集群](/tidb-cloud/scale-tidb-cluster.md)）。 - 通过使用 [乐观事务模型](https://docs.pingcap.com/tidb/stable/optimistic-transaction#tidb-optimistic-transaction-model) 减少锁冲突。 -- 提高查询性能 +- 提升查询性能 - - 在 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页的 [**SQL Statement**](/tidb-cloud/tune-performance.md#statement-analysis) 标签查看 SQL 执行计划。 - - 在 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页的 [**Key Visualizer**](/tidb-cloud/tune-performance.md#key-visualizer) 标签查看热点问题。 + - 在 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页的 [**SQL Statement**](/tidb-cloud/tune-performance.md#statement-analysis) 标签页检查 SQL 执行计划。 + - 在 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页的 [**Key Visualizer**](/tidb-cloud/tune-performance.md#key-visualizer) 标签页检查热点问题。 - 在 [**Metrics**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面监控 TiDB 集群是否容量不足。 - 使用 TiFlash 功能优化分析型处理。参见 [使用 HTAP 集群](/tiflash/tiflash-overview.md)。 ## 第 7 步：探索更多功能 -现在业务负载测试已完成，你可以探索更多功能，例如升级和备份。 +完成业务负载测试后，你可以探索更多功能，例如升级和备份。 - 升级 @@ -184,7 +184,7 @@ TiDB Cloud 高度兼容 MySQL 8.0。如果你的数据源兼容 MySQL 或可以 - 备份 - 为避免厂商锁定，你可以使用每日全量备份将数据迁移到新集群，并使用 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview) 导出数据。更多信息参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup) 及 [备份与恢复 TiDB Cloud Starter 或 Essential 数据](/tidb-cloud/backup-and-restore-serverless.md)。 + 为避免厂商锁定，你可以使用每日全量备份将数据迁移到新集群，并使用 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview) 导出数据。更多信息参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup) 和 [备份与恢复 TiDB Cloud Starter 或 Essential 数据](/tidb-cloud/backup-and-restore-serverless.md)。 ## 第 8 步：清理环境并完成 PoC @@ -210,27 +210,27 @@ TiDB Cloud 提供两种数据库备份方式：自动备份和手动备份。两 ### 2. 什么时候需要扩容和缩容？ -关于扩容和缩容，有以下几点建议： +关于扩容，有以下几点建议： -- 在高峰时段或数据导入期间，如果你观察到 Dashboard 上的容量指标已达到上限（参见 [监控 TiDB 集群](/tidb-cloud/monitor-tidb-cluster.md)），你可能需要扩容集群。 -- 如果你观察到资源使用率持续较低，例如 CPU 使用率仅为 10%-20%，可以缩容集群以节省资源。 +- 在业务高峰期或数据导入时，如果你发现 Dashboard 上的容量指标已接近上限（参见 [监控 TiDB 集群](/tidb-cloud/monitor-tidb-cluster.md)），你可能需要扩容集群。 +- 如果你发现资源使用率持续较低，例如 CPU 使用率仅为 10%-20%，可以缩容集群以节省资源。 -你可以在控制台自行扩容集群。如果需要缩容集群，则需要联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md) 协助。关于扩容的更多信息，参见 [扩容 TiDB 集群](/tidb-cloud/scale-tidb-cluster.md)。你可以与支持团队保持联系，跟踪具体进度。扩容操作完成前请勿开始测试，因为数据重平衡会影响性能。 +你可以在控制台自行扩容集群。如果需要缩容集群，则需要联系 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md) 协助。关于扩容的更多信息，参见 [扩容 TiDB 集群](/tidb-cloud/scale-tidb-cluster.md)。你可以与支持团队保持沟通，跟踪具体进度。扩容操作会涉及数据重平衡，需等待扩容完成后再开始测试，以免影响性能。 ### 3. 如何最大化利用 PoC 额度？ PoC 申请通过后，你的账户会获得额度。一般来说，这些额度足以支持 14 天的 PoC。额度按节点类型和节点数量按小时计费。更多信息参见 [TiDB Cloud 计费](/tidb-cloud/tidb-cloud-billing.md#credits)。 -要查看 PoC 的总额度、可用额度和当前额度使用情况，请在 TiDB Cloud 控制台左上角通过下拉框切换到目标组织，点击左侧导航栏的 **Billing**，然后点击 **Credits** 标签页。 +要查看 PoC 的总额度、可用额度和当前额度使用情况，可在 TiDB Cloud 控制台左上角切换到目标组织，点击左侧导航栏的 **Billing**，然后点击 **Credits** 标签页。 -为节省额度，请移除不再使用的集群。目前无法停止集群。你需要确保备份已更新后再移除集群，这样在需要恢复 PoC 时可以还原集群。 +为节省额度，请移除不再使用的集群。目前无法停止集群。你需要确保备份已更新后再移除集群，以便后续恢复 PoC。 如果 PoC 结束后仍有未用完的额度，只要额度未过期，你可以继续用这些额度支付 TiDB 集群费用。 ### 4. PoC 可以超过 2 周吗？ -如果你希望延长 PoC 试用期或额度即将用尽，请[联系 PingCAP](https://www.pingcap.com/contact-us/) 获取帮助。 +如果你希望延长 PoC 试用期或额度即将用尽，[联系 PingCAP](https://www.pingcap.com/contact-us/) 获取帮助。 ### 5. 如果遇到技术问题，如何获得 PoC 支持？ -你可以随时[联系 TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md) 获取帮助。 \ No newline at end of file +你可以随时 [联系 TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md) 获取帮助。 \ No newline at end of file diff --git a/tidb-cloud/tidb-cloud-quickstart.md b/tidb-cloud/tidb-cloud-quickstart.md index 4e5c68f019cb9..f909f7efe416a 100644 --- a/tidb-cloud/tidb-cloud-quickstart.md +++ b/tidb-cloud/tidb-cloud-quickstart.md @@ -14,11 +14,11 @@ category: quick start ## 第 1 步：创建 TiDB 集群 -[TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless)（现称为 Starter）是体验 TiDB Cloud 的最佳方式。要创建 TiDB Cloud Starter 集群，请按照以下步骤操作： +[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 是体验 TiDB Cloud 的最佳方式。要创建 TiDB Cloud Starter 集群，请按照以下步骤操作： 1. 如果你还没有 TiDB Cloud 账号，请点击[这里](https://tidbcloud.com/free-trial)注册。 - 你可以使用邮箱和密码注册并由 TiDB Cloud 管理密码，或者选择使用 Google、GitHub 或 Microsoft 账号进行单点登录（SSO）到 TiDB Cloud。 + 你可以使用邮箱和密码注册，并通过 TiDB Cloud 管理你的密码，或者选择使用 Google、GitHub 或 Microsoft 账号进行单点登录（SSO）到 TiDB Cloud。 2. [登录](https://tidbcloud.com/)你的 TiDB Cloud 账号。 @@ -26,11 +26,11 @@ category: quick start 3. 对于新注册用户，TiDB Cloud 会自动为你创建一个名为 `Cluster0` 的默认 TiDB Cloud Starter 集群。 - - 如果你想立即使用该默认集群体验 TiDB Cloud 的功能，请继续查看 [第 2 步：体验 AI 辅助 SQL 编辑器](#step-2-try-ai-assisted-sql-editor)。 + - 如果你想立即使用该默认集群体验 TiDB Cloud 的功能，请继续阅读 [第 2 步：体验 AI 辅助 SQL 编辑器](#step-2-try-ai-assisted-sql-editor)。 - 如果你想自行创建新的 TiDB Cloud Starter 集群，请按照以下步骤操作： 1. 点击 **Create Cluster**。 - 2. 在 **Create Cluster** 页面，**Starter** 会被默认选中。选择你的集群的云服务商和目标区域，如有需要可修改默认集群名称，然后点击 **Create**。你的 TiDB Cloud Starter 集群将在大约 30 秒内创建完成。 + 2. 在 **Create Cluster** 页面，**Starter** 会被默认选中。选择你的云服务商和目标区域，如有需要可修改默认集群名称，然后点击 **Create**。你的 TiDB Cloud Starter 集群将在大约 30 秒内创建完成。 @@ -50,15 +50,15 @@ category: quick start ## 第 2 步：体验 AI 辅助 SQL 编辑器 -对于托管在 AWS 上的 TiDB Cloud Starter 集群，你可以在 TiDB Cloud 控制台中使用内置的 AI 辅助 SQL 编辑器，最大化数据价值。你无需本地 SQL 客户端即可对数据库运行 SQL 查询，并可直观地在表格或图表中查看查询结果，轻松查看查询日志。 +对于托管在 AWS 上的 TiDB Cloud Starter 集群，你可以在 TiDB Cloud 控制台中使用内置的 AI 辅助 SQL 编辑器，最大化数据价值。你无需本地 SQL 客户端即可对数据库运行 SQL 查询，并可直观地以表格或图表形式查看查询结果，轻松查看查询日志。 1. 在 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击某个集群名称进入其概览页面，然后在左侧导航栏点击 **SQL Editor**。 2. 若要体验 TiDB Cloud 的 AI 能力，请按照屏幕提示允许 PingCAP 和 AWS Bedrock 使用你的代码片段进行研究和服务改进，然后点击 **Save and Get Started**。 -3. 在 SQL Editor 中，按下 ⌘ + I（macOS）或 Control + I（Windows 或 Linux），即可指示 [Chat2Query (beta)](/tidb-cloud/tidb-cloud-glossary.md#chat2query) 自动生成 SQL 查询。 +3. 在 SQL Editor 中，按下 macOS 的 ⌘ + I（或 Windows/Linux 的 Control + I），即可指示 [Chat2Query (beta)](/tidb-cloud/tidb-cloud-glossary.md#chat2query) 自动生成 SQL 查询。 - 例如，若要创建一个包含两列（`id` 和 `name`）的新表 `test.t`，你可以输入 `use test;` 指定数据库，按下 ⌘ + I，输入 `create a new table t with id and name` 作为指令，然后按 **Enter**，让 AI 自动生成相应的 SQL 语句。 + 例如，若要创建一个包含两列（`id` 和 `name`）的新表 `test.t`，你可以输入 `use test;` 指定数据库，按下 ⌘ + I，输入指令 `create a new table t with id and name`，然后按 **Enter**，让 AI 自动生成相应的 SQL 语句。 对于生成的语句，你可以点击 **Accept** 接受并根据需要进一步编辑，或点击 **Discard** 拒绝。 @@ -75,7 +75,7 @@ category: quick start - 如果编辑器中只有一个查询，按下 **⌘ + Enter** 或点击 **Run** 执行。 - - 如果编辑器中有多个查询，使用光标选中目标查询的行，然后按 **⌘ + Enter** 或点击 **Run** 顺序执行它们。 + - 如果编辑器中有多个查询，使用光标选中目标查询的行，然后按 **⌘ + Enter** 或点击 **Run** 顺序执行。 - 若要顺序执行编辑器中的所有查询，按 **⇧ + ⌘ + Enter**，或用光标选中所有查询的行后点击 **Run**。 @@ -87,7 +87,7 @@ category: quick start - 如果编辑器中只有一个查询，按下 **Ctrl + Enter** 或点击 **Run** 执行。 - - 如果编辑器中有多个查询，使用光标选中目标查询的行，然后按 **Ctrl + Enter** 或点击 **Run** 顺序执行它们。 + - 如果编辑器中有多个查询，使用光标选中目标查询的行，然后按 **Ctrl + Enter** 或点击 **Run** 顺序执行。 - 若要顺序执行编辑器中的所有查询，按 **Shift + Ctrl + Enter**，或用光标选中所有查询的行后点击 **Run**。 @@ -126,12 +126,12 @@ FROM TiDB Cloud 提供了交互式教程和精心设计的示例数据集，帮助你快速上手 TiDB Cloud。对于托管在 AWS 上的 TiDB Cloud Starter 集群，你可以通过该教程学习如何使用 TiDB Cloud 进行高性能数据分析。 1. 点击控制台右下角的 **?** 图标，选择 **Guided tour of SQL Editor**。 -2. 选择你想用于体验的 TiDB Cloud Starter 集群，点击 **Import Dataset**。导入过程大约需要 1 分钟。 +2. 选择你想用于教程的 TiDB Cloud Starter 集群，点击 **Import Dataset**。导入过程大约需要 1 分钟。 3. 示例数据导入完成后，按照屏幕提示完成教程。 ## 后续操作 -- 了解如何通过不同方式连接到你的集群，请参见 [连接到 TiDB Cloud Starter 或 Essential 集群](/tidb-cloud/connect-to-tidb-cluster-serverless.md)。 -- 获取更多关于如何使用 SQL Editor 和 Chat2Query 探索数据的信息，请参见 [使用 AI 辅助 SQL 编辑器探索数据](/tidb-cloud/explore-data-with-chat2query.md)。 -- 了解 TiDB SQL 的用法，请参见 [使用 TiDB 探索 SQL](/basic-sql-operations.md)。 -- 若需生产环境使用，享受跨可用区高可用、水平扩展和 [HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing) 等优势，请参见 [创建 TiDB Cloud Dedicated 集群](/tidb-cloud/create-tidb-cluster.md)。 \ No newline at end of file +- 了解如何通过不同方式连接你的集群，请参见 [Connect to a TiDB Cloud Starter or Essential cluster](/tidb-cloud/connect-to-tidb-cluster-serverless.md)。 +- 了解如何使用 SQL Editor 和 Chat2Query 探索你的数据，请参见 [Explore your data with AI-assisted SQL Editor](/tidb-cloud/explore-data-with-chat2query.md)。 +- 了解 TiDB SQL 的用法，请参见 [Explore SQL with TiDB](/basic-sql-operations.md)。 +- 若需生产环境使用，享受跨可用区高可用、水平扩展和 [HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing) 等优势，请参见 [Create a TiDB Cloud Dedicated cluster](/tidb-cloud/create-tidb-cluster.md)。 \ No newline at end of file diff --git a/tidb-cloud/tidb-cloud-release-notes.md b/tidb-cloud/tidb-cloud-release-notes.md index fda955acb32c8..3111419111679 100644 --- a/tidb-cloud/tidb-cloud-release-notes.md +++ b/tidb-cloud/tidb-cloud-release-notes.md @@ -8,88 +8,108 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] 本页面列出了 [TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 在 2025 年的发布说明。 +## 2025 年 10 月 21 日 + +**通用变更** + +- **TiDB Cloud 专属版** + + - [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 增强了 [Changefeeds](/tidb-cloud/changefeed-overview.md) 的私有端点功能，简化配置、提升安全性，并为数据下游提供更大的灵活性。 + + - **简化配置**：私有端点的创建现已与 changefeed 创建解耦，同一项目下的多个 changefeed 可共享同一个私有端点，从而减少冗余配置。 + - **MySQL 的私有链路下游**：为数据下沉到 MySQL 提供了更安全的方式，并且现在也支持通过私有链路直接下沉到另一个 TiDB Cloud 专属版集群。 + - **自定义域名支持**：在使用自建 Kafka 服务时，可以为数据下游配置自定义域名，以增强安全性，并使 advertised listener 的更新更加灵活，无需重启服务器。 + + 了解更多信息，请参见 [为 Changefeeds 设置私有端点](/tidb-cloud/set-up-sink-private-endpoint.md)。 + + - [Prometheus 集成（预览版）](/tidb-cloud/monitor-prometheus-and-grafana-integration.md) 现已适用于 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 + + TiDB Cloud 现在在集群级别管理 Prometheus 集成，提供更细粒度的控制和配置。该功能使你能够无缝地将 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的监控指标发送到 Prometheus，从而在统一平台上实现高级告警。 + + 了解更多信息，请参见 [将 TiDB Cloud 集成到 Prometheus 和 Grafana](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)。 + ## 2025 年 10 月 14 日 **通用变更** - **TiDB Cloud Starter** - - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 不再支持数据库审计日志。 + - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 不再支持数据库审计日志。 - 目前，只有 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 和 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持数据库审计日志。当前正在使用数据库审计日志的现有 TiDB Cloud Starter 集群不受影响。 + 目前，只有 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 和 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持数据库审计日志。当前正在使用数据库审计日志的现有 TiDB Cloud Starter 集群不受影响。 - - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 移除了原地恢复功能，这意味着你无法再将备份直接恢复到同一个集群。此更改有助于防止误覆盖活跃生产数据和潜在数据丢失。 + - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 移除了原地恢复功能，这意味着你无法再将备份直接恢复到同一个集群。此更改有助于防止误覆盖活跃生产数据和潜在数据丢失。 - 若需恢复数据，你可以[将备份恢复到新集群](/tidb-cloud/backup-and-restore-serverless.md#perform-the-restore)。在验证恢复的数据后，将你的应用切换到新集群。已在现有集群中恢复的数据保持不变，除非你执行新的恢复，否则无需操作。 + 若需恢复数据，你可以[将备份恢复到新集群](/tidb-cloud/backup-and-restore-serverless.md#perform-the-restore)。在验证恢复数据后，将应用切换到新集群。已在现有集群中恢复的数据不会受影响，除非你执行新的恢复操作，否则无需任何操作。 若需更安全、可控且灵活的恢复和迁移流程，建议使用 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)。 - - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 的 [**Metrics**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面新增以下指标，便于更快诊断和容量规划： + - [**Metrics**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面为 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 新增以下指标，便于更快诊断和容量规划： - `Lock-wait (P95/P99)`：监控锁等待时间分位数，定位争用热点。 - - `Idle Connection Duration (P99 incl. not/in txn)`：识别长时间空闲连接（包括事务内和非事务内），以便调整连接池限制和超时设置。 + - `Idle Connection Duration (P99 incl. not/in txn)`：识别长时间空闲连接（包括事务内和非事务内），以便调整连接池限制和超时时间。 - **TiDB Cloud Essential** - - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 在 AWS 和阿里云 上公测。 + - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 在 AWS 和阿里云 进入公测。 - 对于负载持续增长、需要实时扩展的应用，TiDB Cloud Essential 提供了灵活性和性能，助力业务增长。 + 对于业务负载持续增长、需要实时扩展的应用，TiDB Cloud Essential 提供了灵活性和性能，助力业务发展。 - 详情参见 [TiDB Cloud Essential 现已在 AWS 和阿里云公测](https://www.pingcap.com/blog/tidb-cloud-essential-now-available-public-preview-aws-alibaba-cloud/)。 + 了解更多信息，请参见 [TiDB Cloud Essential 现已在 AWS 和阿里云公测上线](https://www.pingcap.com/blog/tidb-cloud-essential-now-available-public-preview-aws-alibaba-cloud/)。 - - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 现已在 [TiDB Cloud 控制台](https://tidbcloud.com) 支持数据库审计日志，并支持自定义轮转设置。 + - 数据库审计日志现已在 [TiDB Cloud 控制台](https://tidbcloud.com) 上线，适用于 TiDB Cloud Essential，并支持自定义轮转设置。 你可以将数据库审计日志存储在 TiDB Cloud、Amazon S3、Google Cloud Storage、Azure Blob Storage 或阿里云 OSS。 - 目前该功能为 Beta 版。详情参见 [TiDB Cloud Essential 数据库审计日志](/tidb-cloud/essential-database-audit-logging.md)。 + 目前该功能为 beta 版。了解更多信息，请参见 [TiDB Cloud Essential 的数据库审计日志](/tidb-cloud/essential-database-audit-logging.md)。 - TiDB Cloud Essential 新增事件 `ResourceLimitation`，当集群的 Request Capacity Units（RCUs）消耗在一小时内多次达到配置上限时会通知你。 - 超出限制的用量可能会被限流。为避免服务影响，建议提升最大 RCU。 + 超出限制的用量可能会被限流。为避免服务受影响，建议提升最大 RCU。 - 事件详情参见 [TiDB Cloud 集群事件](/tidb-cloud/tidb-cloud-events.md)。 + 了解更多事件信息，请参见 [TiDB Cloud 集群事件](/tidb-cloud/tidb-cloud-events.md)。 - - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 的 [**Metrics**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面新增以下指标，便于更快诊断和容量规划： + - [**Metrics**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) 页面为 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 新增以下指标，便于更快诊断和容量规划： - `Capacity vs Usage (RU/s)`：可视化已配置的 Request Unit（RU）容量与实际 RU 消耗，便于发现冗余空间并优化自动扩缩容。 - `Lock-wait (P95/P99)`：监控锁等待时间分位数，定位争用热点。 - - `Idle Connection Duration (P99 incl. not/in txn)`：识别长时间空闲连接（包括事务内和非事务内），以便调整连接池限制和超时设置。 + - `Idle Connection Duration (P99 incl. not/in txn)`：识别长时间空闲连接（包括事务内和非事务内），以便调整连接池限制和超时时间。 - 详情参见 [TiDB Cloud 内置监控指标](/tidb-cloud/built-in-monitoring.md)。 + 了解更多信息，请参见 [TiDB Cloud 内置监控指标](/tidb-cloud/built-in-monitoring.md)。 ## 2025 年 9 月 30 日 **通用变更** -- **TiDB Cloud Dedicated** +- **TiDB Cloud 专属版** - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群现已正式（GA）支持 Datadog 和 New Relic 集成。 + - Datadog 和 New Relic 集成现已正式发布（GA），适用于 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 - TiDB Cloud 现以集群为粒度管理 Datadog 和 New Relic 集成，提供更细致的控制和配置。该功能可让你将 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的监控指标无缝发送到 Datadog 或 New Relic，实现统一平台下的高级告警。 + TiDB Cloud 现在在集群级别管理 Datadog 和 New Relic 集成，提供更细粒度的控制和配置。该功能使你能够无缝地将 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的监控指标发送到 Datadog 或 New Relic，从而在统一平台上实现高级告警。 - 集成步骤参见 [集成 TiDB Cloud 与 Datadog](/tidb-cloud/monitor-datadog-integration.md) 和 [集成 TiDB Cloud 与 New Relic](/tidb-cloud/monitor-new-relic-integration.md)。 + 集成步骤请参见 [将 TiDB Cloud 集成到 Datadog](/tidb-cloud/monitor-datadog-integration.md) 和 [将 TiDB Cloud 集成到 New Relic](/tidb-cloud/monitor-new-relic-integration.md)。 - 若需将现有 Datadog 和 New Relic 集成迁移到集群级别，参见 [迁移 Datadog 和 New Relic 集成](/tidb-cloud/migrate-metrics-integrations.md)。 + 若需将现有 Datadog 和 New Relic 集成迁移到集群级别，请参见 [迁移 Datadog 和 New Relic 集成](/tidb-cloud/migrate-metrics-integrations.md)。 ## 2025 年 9 月 23 日 **通用变更** -- **TiDB Cloud Dedicated** +- **TiDB Cloud 专属版** - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) changefeed 支持用户自定义 `UPDATE` 事件拆分。 + - 支持在 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) changefeed 中由用户控制 `UPDATE` 事件的拆分。 - 在 TiDB Cloud Dedicated 集群中，你可以配置是否将 `UPDATE` 事件保留为原始事件，或拆分为单独的 `DELETE` 和 `INSERT` 事件。该功能为高级同步场景提供更大灵活性。 + 在 TiDB Cloud 专属版集群中，你可以配置是否将 `UPDATE` 事件保留为原始事件，或拆分为单独的 `DELETE` 和 `INSERT` 事件。该功能为高级同步场景提供了更大的灵活性。 - 该功能仅支持非 SQL 目的地，如 Apache Kafka 和 Amazon S3。详情参见 [同步到 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md)、[同步到 Apache Pulsar](/tidb-cloud/changefeed-sink-to-apache-pulsar.md) 和 [同步到云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 + 该功能仅支持非 SQL 下游，如 Apache Kafka 和 Amazon S3。了解更多信息，请参见 [下沉到 Apache Kafka](/tidb-cloud/changefeed-sink-to-apache-kafka.md)、[下沉到 Apache Pulsar](/tidb-cloud/changefeed-sink-to-apache-pulsar.md) 和 [下沉到云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 - 拆分行为详情参见 [为非 MySQL sink 拆分主键或唯一键 `UPDATE` 事件](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 + 关于拆分行为的更多信息，请参见 [为非 MySQL 下游拆分主键或唯一键 `UPDATE` 事件](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（Google Cloud 托管）新增节点规格：`32 vCPU, 64 GiB`。 + - 为托管在 Google Cloud 上的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群提供新的节点规格：`32 vCPU, 64 GiB`。 该节点规格适用于 TiDB 节点。 @@ -97,23 +117,23 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] **通用变更** -- **TiDB Cloud Dedicated** +- **TiDB Cloud 专属版** - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（Azure 托管）支持使用客户自管加密密钥（CMEK）进行静态加密。 + - 支持在 Azure 上托管的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群使用客户自管加密密钥（CMEK）进行静态加密。 - 该功能允许你使用自有加密密钥保护静态数据。CMEK 带来以下优势： + 该功能允许你使用自主管理的加密密钥保护静态数据。CMEK 带来以下优势： - 数据安全：你拥有并管理加密密钥，确保数据受保护且可控。 - 合规性：使用 CMEK 有助于满足数据加密的合规和监管要求。 - - 灵活性：你可在创建项目时启用 CMEK，并在创建集群前完成配置。 + - 灵活性：你可以在创建项目时启用 CMEK，并在创建集群前完成 CMEK 配置。 - 启用步骤如下： + 启用该功能的步骤如下： - 1. 在 [TiDB Cloud 控制台](https://tidbcloud.com) 创建支持 CMEK 的项目。 + 1. 在 [TiDB Cloud 控制台](https://tidbcloud.com) 创建启用 CMEK 的项目。 2. 完成该项目的 CMEK 配置。 - 3. 在与 CMEK 配置相同区域创建 Azure 托管的 TiDB Cloud Dedicated 集群。 + 3. 在与 CMEK 配置相同的区域创建托管在 Azure 上的 TiDB Cloud 专属版集群。 - 详情参见 [在 Azure 上使用客户自管加密密钥进行静态加密](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md)。 + 了解更多信息，请参见 [在 Azure 上使用客户自管加密密钥进行静态加密](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md)。 ## 2025 年 9 月 9 日 @@ -121,16 +141,16 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] - **TiDB Cloud Starter** - - 新建的 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群仅启用可用区级高可用，且不可配置。 - - 2025 年 9 月 9 日前已启用区域级高可用的现有 TiDB Cloud Starter 集群，区域级高可用继续受支持，不受影响。 + - 新创建的 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群仅启用可用区级高可用性，且不可配置。 + - 2025 年 9 月 9 日前已启用区域级高可用性的现有 TiDB Cloud Starter 集群，区域级高可用性仍然受支持且不受影响。 - **TiDB Cloud Essential** - - 新建的 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群默认启用区域级高可用，你可在创建集群时根据需要切换为可用区级高可用。 + - 新创建的 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群默认启用区域级高可用性，你可以在集群创建时根据需要切换为可用区级高可用性。 - 详情参见 [TiDB Cloud Starter 和 Essential 的高可用性](/tidb-cloud/serverless-high-availability.md)。 + 了解更多信息，请参见 [TiDB Cloud Starter 和 Essential 的高可用性](/tidb-cloud/serverless-high-availability.md)。 @@ -142,19 +162,19 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] - **TiDB Cloud Essential** - - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群新增支持 3 个阿里云区域：`Jakarta (ap-southeast-5)`、`Mexico (na-south-1)` 和 `Tokyo (ap-northeast-1)`。 + - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群新增支持三个阿里云区域：`Jakarta (ap-southeast-5)`、`Mexico (na-south-1)` 和 `Tokyo (ap-northeast-1)`。 -- **TiDB Cloud Dedicated** +- **TiDB Cloud 专属版** - - 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v8.5.2](https://docs.pingcap.com/tidb/v8.5/release-8.5.2/) 升级为 [v8.5.3](https://docs.pingcap.com/tidb/v8.5/release-8.5.3/)。 + - 新建 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本从 [v8.5.2](https://docs.pingcap.com/tidb/v8.5/release-8.5.2/) 升级为 [v8.5.3](https://docs.pingcap.com/tidb/v8.5/release-8.5.3/)。 -- **TiDB Cloud Dedicated** +- **TiDB Cloud 专属版** - - 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v8.5.2](https://docs.pingcap.com/tidb/v8.5/release-8.5.2/) 升级为 [v8.5.3](https://docs.pingcap.com/tidb/v8.5/release-8.5.3/)。 + - 新建 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本从 [v8.5.2](https://docs.pingcap.com/tidb/v8.5/release-8.5.2/) 升级为 [v8.5.3](https://docs.pingcap.com/tidb/v8.5/release-8.5.3/)。 @@ -164,25 +184,25 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] - **TiDB Cloud Starter** - - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 引入 Auto Embedding（Beta），可轻松将文本转为向量，无需额外配置。该功能让你能更快在 TiDB Cloud 上开发语义搜索、RAG、重排序和分类等场景，减少集成成本。 + - 在 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 引入 Auto Embedding（Beta），让你无需额外配置即可轻松将文本转换为向量。该功能可加速在 TiDB Cloud 中开发语义搜索、RAG、重排序和分类等场景，减少集成成本。 - - **支持主流 LLM 提供商的 Auto Embedding**：Amazon Titan、OpenAI、Cohere、Gemini、Jina AI、Hugging Face 和 NVIDIA NIM。 - - **原生集成 AWS Bedrock**：托管嵌入模型并提供免费额度，包括 AWS Bedrock 的 Amazon Titan 和 Cohere 文本嵌入模型。 - - **支持 SQL 和 Python**，并提供创建、存储和查询嵌入的代码示例。 + - **与主流 LLM 提供商的 Auto Embedding**：Amazon Titan、OpenAI、Cohere、Gemini、Jina AI、Hugging Face 和 NVIDIA NIM。 + - **与 AWS Bedrock 的原生集成**：托管的 embedding 模型并提供免费额度，包括 AWS Bedrock 的 Amazon Titan 和 Cohere 文本 embedding 模型。 + - **支持 SQL 和 Python**，并提供创建、存储和查询 embedding 的代码示例。 - 详情参见 [Auto Embedding](https://docs.pingcap.com/tidbcloud/vector-search-auto-embedding-overview/?plan=starter)。 + 了解更多信息，请参见 [Auto Embedding](https://docs.pingcap.com/tidbcloud/vector-search-auto-embedding-overview/?plan=starter)。 -- **TiDB Cloud Dedicated** +- **TiDB Cloud 专属版** - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 不再支持 Index Insight（Beta）功能。 + - [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 不再支持 Index Insight（beta）功能。 推荐使用 [Index Advisor](/index-advisor.md)，适用于 TiDB v8.5.0 及以上版本。Index Advisor 引入了 `RECOMMEND INDEX` SQL 语句，帮助你通过推荐索引优化查询性能。 - - 你现在可以在启用每周备份的 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群上手动关闭时间点恢复（Point-in-time Restore）功能。 + - 你现在可以在启用每周备份的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群上手动禁用时间点恢复（Point-in-time Restore）功能。 - 该优化有助于降低不需要高 RPO 保护的集群的成本。 + 该增强有助于降低不需要高 RPO 保护的集群的成本。 - 详情参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md)。 + 了解更多信息，请参见 [备份与恢复 TiDB Cloud 专属版数据](/tidb-cloud/backup-and-restore.md)。 ## 2025 年 8 月 12 日 @@ -194,39 +214,39 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] - 将 “TiDB Cloud Serverless” 重命名为 “TiDB Cloud Starter”。 - 自动扩缩容入门方案现称为 “TiDB Cloud Starter”，更好地体现其为新用户提供的角色。所有功能、价格和免费额度保持不变。 + 自动扩缩容入门方案现更名为 “TiDB Cloud Starter”，更好地体现其为新用户提供的角色。所有功能、定价和免费额度保持不变。 - 自 2025 年 8 月 12 日（PDT）起，你现有的 Serverless 集群将在 [TiDB Cloud 控制台](https://tidbcloud.com) 中显示为 Starter。你的连接字符串、端点和数据均保持不变，无需修改代码或安排停机。 + 自 2025 年 8 月 12 日（PDT）起，你现有的 Serverless 集群将在 [TiDB Cloud 控制台](https://tidbcloud.com) 中显示为 Starter。你的连接字符串、端点和数据均保持不变，无需更改代码或安排停机。 - - TiDB Cloud Starter 在阿里云公测。 + - TiDB Cloud Starter 在阿里云进入预览。 - **TiDB Cloud Essential** - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 在阿里云公测。 + [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 在阿里云进入预览。 - TiDB Cloud Essential 在阿里云自 2025 年 5 月起已小范围公测。本次是 Essential 首次正式纳入发布说明。目前，Essential 在阿里云提供与 Starter 一致的功能集，支持阿里云新加坡区域。 + TiDB Cloud Essential 在阿里云自 2025 年 5 月起已进行有限公测。本次是 Essential 首次正式纳入发布说明。目前，Essential 在阿里云新加坡区域提供，与 Starter 保持一致的功能集。 - 体验方式： + 试用方法： - 在 [TiDB Cloud 控制台](https://tidbcloud.com/) 创建集群时选择阿里云作为云服务商，即可看到 Essential 选项。 - - 你也可以通过 [阿里云 Marketplace 上的 Essential 列表](https://www.alibabacloud.com/en/marketplace/tidb?_p_lc=1) 访问。 + - 你也可以通过 [阿里云 Marketplace 上的 Essential 产品页](https://www.alibabacloud.com/en/marketplace/tidb?_p_lc=1) 访问 Essential。 - 后续计划将扩展阿里云区域覆盖，并增加 AWS 支持。 + 接下来，我们计划扩展阿里云的区域覆盖，并增加对 AWS 的支持。 - 若你在公测期间体验 Essential on 阿里云，可通过 Web 控制台反馈，或加入 [Slack 社区](https://tidbcommunity.slack.com/archives/CH7TTLL7P) 或 [Discord 社区](https://discord.gg/ukhXbn69Nx) 交流。 + 如果你在预览期间试用 Essential on 阿里云，欢迎通过 Web 控制台反馈，或加入我们的 [Slack 社区](https://tidbcommunity.slack.com/archives/CH7TTLL7P) 或 [Discord 社区](https://discord.gg/ukhXbn69Nx)。 -- **TiDB Cloud Dedicated** +- **TiDB Cloud 专属版** - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 在 Google Cloud 上通过优化 NAT 子网分配策略，现支持每区域超过 8 个 Google Private Service Connect（PSC）连接。 + - [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 在 Google Cloud 上通过优化 NAT 子网分配策略，现支持每个区域超过 8 个 Google Private Service Connect（PSC）连接。 - 详情参见 [通过 Google Cloud Private Service Connect 连接 TiDB Cloud Dedicated 集群](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md#restrictions)。 + 了解更多信息，请参见 [通过 Google Cloud Private Service Connect 连接 TiDB Cloud 专属版集群](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md#restrictions)。 - - 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 监控指标： + - 优化 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 监控指标： - 在 [**Advanced**](/tidb-cloud/built-in-monitoring.md#advanced) 分类下，新增 **Affected Rows**、**Leader Count** 和 **Region Count** 指标，提升诊断能力。 - 在 [**Server**](/tidb-cloud/built-in-monitoring.md#server) 分类下，优化 **TiKV IO Bps** 指标，提升准确性和一致性。 - 详情参见 [TiDB Cloud 内置监控指标](/tidb-cloud/built-in-monitoring.md)。 + 了解更多信息，请参见 [TiDB Cloud 内置监控指标](/tidb-cloud/built-in-monitoring.md)。 @@ -236,95 +256,95 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] 将 “TiDB Cloud Serverless” 重命名为 “TiDB Cloud Starter”。 - 自动扩缩容入门方案现称为 “TiDB Cloud Starter”，更好地体现其为新用户提供的角色。所有功能、价格和免费额度保持不变。 + 自动扩缩容入门方案现更名为 “TiDB Cloud Starter”，更好地体现其为新用户提供的角色。所有功能、定价和免费额度保持不变。 - 自 2025 年 8 月 12 日（PDT）起，你现有的 Serverless 集群将在 [TiDB Cloud 控制台](https://tidbcloud.com) 中显示为 Starter。你的连接字符串、端点和数据均保持不变，无需修改代码或安排停机。 + 自 2025 年 8 月 12 日（PDT）起，你现有的 Serverless 集群将在 [TiDB Cloud 控制台](https://tidbcloud.com) 中显示为 Starter。你的连接字符串、端点和数据均保持不变，无需更改代码或安排停机。 -- **TiDB Cloud Dedicated** +- **TiDB Cloud 专属版** - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 在 Google Cloud 上通过优化 NAT 子网分配策略，现支持每区域超过 8 个 Google Private Service Connect（PSC）连接。 + - [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 在 Google Cloud 上通过优化 NAT 子网分配策略，现支持每个区域超过 8 个 Google Private Service Connect（PSC）连接。 - 详情参见 [通过 Google Cloud Private Service Connect 连接 TiDB Cloud Dedicated 集群](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md#restrictions)。 + 了解更多信息，请参见 [通过 Google Cloud Private Service Connect 连接 TiDB Cloud 专属版集群](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md#restrictions)。 - - 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 监控指标： + - 优化 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 监控指标： - 在 [**Advanced**](/tidb-cloud/built-in-monitoring.md#advanced) 分类下，新增 **Affected Rows**、**Leader Count** 和 **Region Count** 指标，提升诊断能力。 - 在 [**Server**](/tidb-cloud/built-in-monitoring.md#server) 分类下，优化 **TiKV IO Bps** 指标，提升准确性和一致性。 - 详情参见 [TiDB Cloud 内置监控指标](/tidb-cloud/built-in-monitoring.md)。 + 了解更多信息，请参见 [TiDB Cloud 内置监控指标](/tidb-cloud/built-in-monitoring.md)。 **API 变更** -- 推出 TiDB Cloud Dedicated API（v1beta1），可自动高效管理以下资源： +- 推出 TiDB Cloud 专属版 API（v1beta1），可自动高效地管理以下资源： - - **Cluster**：更灵活地管理你的 TiDB Cloud Dedicated 集群。 - - **Region**：展示所有可部署 TiDB Cloud Dedicated 集群的云区域。 - - **Private endpoint connection**：为集群配置安全私有连接。 + - **Cluster**：更灵活地管理你的 TiDB Cloud 专属版集群。 + - **Region**：展示可部署 TiDB Cloud 专属版集群的所有可用云区域。 + - **Private endpoint connection**：为集群设置安全的私有连接。 - **Import**：管理集群的数据导入任务。 - 详情参见 [TiDB Cloud Dedicated API](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated/)。 + 了解更多信息，请参见 [TiDB Cloud 专属版 API](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated/)。 -- 推出 TiDB Cloud Starter 和 Essential API（v1beta1），可自动高效管理以下资源： +- 推出 TiDB Cloud Starter 和 Essential API（v1beta1），可自动高效地管理以下资源： - **Cluster**：更灵活地管理你的 TiDB Cloud Starter 或 Essential 集群。 - **Branch**：管理集群的分支。 - **Export**：管理集群的数据导出任务。 - **Import**：管理集群的数据导入任务。 - 详情参见 [TiDB Cloud Starter 和 Essential API](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless/)。 + 了解更多信息，请参见 [TiDB Cloud Starter 和 Essential API](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless/)。 -- TiDB Cloud IAM API（v1beta1）支持 API 密钥的基于角色的访问控制（RBAC），可在组织和项目级别管理。 +- TiDB Cloud IAM API（v1beta1）支持 API 密钥管理的基于角色的访问控制（RBAC），适用于组织和项目级别。 - 你可以在组织级或项目级设置 API 密钥角色，提升安全性和访问控制。 + 你可以在组织级或项目级设置 API 密钥角色，以提升安全性和访问控制。 - 详情参见 [TiDB Cloud IAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/)。 + 了解更多信息，请参见 [TiDB Cloud IAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/)。 ## 2025 年 7 月 31 日 **通用变更** -- 增强版 Datadog 和 New Relic 集成现已公测。 +- 增强版 Datadog 和 New Relic 集成现已开放预览。 主要增强点： - - 重构集成后端，采用优化的隔离架构，最小化指标丢失。 + - 重构集成后端，采用优化的隔离架构，最大限度减少监控指标丢失。 - 根据用户需求增加更多监控指标。 - 优化指标规则，提升一致性。 - 这些增强带来更准确的监控和更可靠的 Datadog、New Relic 集成。 + 这些增强带来更准确的监控，并提升 Datadog 和 New Relic 集成的可靠性。 发布计划： - 本公测版本现已对未集成 Datadog 或 New Relic 的组织开放。对于已集成的组织，我们将在下月主动联系你，协商迁移方案和时间表。 + 该预览版现已面向未配置 Datadog 或 New Relic 集成的组织开放。对于已配置 Datadog 或 New Relic 集成的组织，我们将在下月主动联系你，协商合适的迁移方案和时间表。 - 详情参见 [集成 TiDB Cloud 与 Datadog（公测）](/tidb-cloud/monitor-datadog-integration.md) 和 [集成 TiDB Cloud 与 New Relic（公测）](/tidb-cloud/monitor-new-relic-integration.md)。 + 了解更多信息，请参见 [将 TiDB Cloud 集成到 Datadog（预览版）](/tidb-cloud/monitor-datadog-integration.md) 和 [将 TiDB Cloud 集成到 New Relic（预览版）](/tidb-cloud/monitor-new-relic-integration.md)。 ## 2025 年 7 月 22 日 **通用变更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（Google Cloud 托管）新增节点规格：`32 vCPU, 128 GiB`。 +- 为托管在 Google Cloud 上的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群提供新的节点规格：`32 vCPU, 128 GiB`。 - 该规格适用于 TiDB、TiKV 和 TiFlash 节点。 + 该节点规格适用于 TiDB、TiKV 和 TiFlash 节点。 -- 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 的 TiKV 扩缩容流程，提升集群稳定性。 +- 优化 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 中 TiKV 的扩缩容流程，提升集群稳定性。 - 当你[更改 TiKV 节点的 vCPU 和内存规格](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)时，TiDB Cloud 会自动检查集群内部服务是否需扩容以支持新配置。 + 当你[更改 TiKV 节点的 vCPU 和内存规格](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)时，TiDB Cloud 会自动检查集群内部服务是否需要扩容以支持新配置。 - - 若需扩容，TiDB Cloud 会提示你确认后再继续操作。 - - 若当前内部服务容量已大于扩容后所需，TiDB Cloud 会保留现有配置，避免不必要的变更影响集群稳定性。 + - 若需扩容，TiDB Cloud 会在操作前提示你确认。 + - 若扩容后内部服务容量已大于所需，TiDB Cloud 会保留现有内部服务配置，避免不必要的变更影响集群稳定性。 **控制台变更** -- 优化 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群的云存储数据导入体验。 +- 优化 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群的云存储数据导入体验。 - 导入流程现简化为 3 步向导，并带有智能预检查。新向导引导你完成连接配置、文件映射和存储桶扫描。通过扫描，TiDB Cloud 会在导入前准确展示将被导入的文件及其目标位置，大幅降低配置复杂度并防止导入失败。 + 导入流程现已简化为 3 步向导，并配备智能预检查。新向导将引导你完成连接设置、文件映射和存储桶扫描。通过扫描，TiDB Cloud 会在导入前准确展示将被导入的文件及其目标位置，大幅降低配置复杂度并防止导入失败。 - 详情参见以下文档： + 了解更多信息，请参见以下文档： - - [导入示例数据到 TiDB Cloud Serverless](/tidb-cloud/import-sample-data-serverless.md) + - [将示例数据导入 TiDB Cloud Serverless](/tidb-cloud/import-sample-data-serverless.md) - [从云存储导入 CSV 文件到 TiDB Cloud Serverless](/tidb-cloud/import-csv-files-serverless.md) - [从云存储导入 Apache Parquet 文件到 TiDB Cloud Serverless](/tidb-cloud/import-parquet-files-serverless.md) @@ -332,49 +352,49 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] **通用变更** -- 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v8.1.2](https://docs.pingcap.com/tidb/stable/release-8.1.2/) 升级为 [v8.5.2](https://docs.pingcap.com/tidb/stable/release-8.5.2/)。 +- 新建 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本从 [v8.1.2](https://docs.pingcap.com/tidb/stable/release-8.1.2/) 升级为 [v8.5.2](https://docs.pingcap.com/tidb/stable/release-8.5.2/)。 - 与 v8.1.2 相比，v8.5.2 包含 [v8.2.0-DMR](https://docs.pingcap.com/tidb/stable/release-8.2.0/)、[v8.3.0-DMR](https://docs.pingcap.com/tidb/stable/release-8.3.0/)、[v8.4.0-DMR](https://docs.pingcap.com/tidb/stable/release-8.4.0/)、[v8.5.0](https://docs.pingcap.com/tidb/stable/release-8.5.0/)、[v8.5.1](https://docs.pingcap.com/tidb/stable/release-8.5.1/) 和 [v8.5.2](https://docs.pingcap.com/tidb/stable/release-8.5.2/) 的新特性、改进和修复。 + 与 v8.1.2 相比，v8.5.2 包含了 [v8.2.0-DMR](https://docs.pingcap.com/tidb/stable/release-8.2.0/)、[v8.3.0-DMR](https://docs.pingcap.com/tidb/stable/release-8.3.0/)、[v8.4.0-DMR](https://docs.pingcap.com/tidb/stable/release-8.4.0/)、[v8.5.0](https://docs.pingcap.com/tidb/stable/release-8.5.0/)、[v8.5.1](https://docs.pingcap.com/tidb/stable/release-8.5.1/) 和 [v8.5.2](https://docs.pingcap.com/tidb/stable/release-8.5.2/) 的新特性、改进和 bug 修复。 - 支持审计 `BackupCompleted` 事件，增强备份活动的控制台审计日志。 - 该增强可记录备份完成活动，满足安全与合规要求。 + 该增强允许你记录备份完成活动，以满足安全和合规要求。 - 详情参见 [控制台审计日志](/tidb-cloud/tidb-cloud-console-auditing.md)。 + 了解更多信息，请参见 [控制台审计日志](/tidb-cloud/tidb-cloud-console-auditing.md)。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) changefeed 支持按列值过滤。 +- 支持在 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) changefeed 中过滤列值。 - 你现在可以在 changefeed 中使用表达式过滤特定列值，从源头排除无关数据。该功能实现 DML 事件的细粒度过滤，帮助降低资源消耗并提升性能。 + 你现在可以在 changefeed 中使用表达式过滤特定列值，从源头排除无关数据。该功能实现 DML 事件的细粒度过滤，有助于降低资源消耗并提升性能。 - 详情参见 [Changefeed](/tidb-cloud/changefeed-overview.md)。 + 了解更多信息，请参见 [Changefeed](/tidb-cloud/changefeed-overview.md)。 ## 2025 年 6 月 24 日 **通用变更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 数据库审计日志（Beta）现可按需申请。该功能可记录用户访问详情（如执行的 SQL 语句）历史日志。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 数据库审计日志（beta）现可按需申请。该功能允许你在日志中记录用户访问详情（如执行的 SQL 语句）历史。 - 申请方式：在 [TiDB Cloud 控制台](https://tidbcloud.com) 右下角点击 **?**，选择 **Request Support**，在 Description 字段填写 “Apply for TiDB Cloud Serverless database audit logging”，点击 **Submit**。 + 申请该功能，请点击 [TiDB Cloud 控制台](https://tidbcloud.com) 右下角的 **?**，再点击 **Request Support**，在 Description 字段填写 “Apply for TiDB Cloud Serverless database audit logging”，然后点击 **Submit**。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持用户自主管理日志脱敏。 +- [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 支持用户自主管理日志脱敏。 - 你现在可以为 TiDB Cloud Dedicated 集群启用或关闭日志脱敏，自主管理集群日志的脱敏状态。 + 你现在可以为 TiDB Cloud 专属版集群启用或禁用日志脱敏，自主管理集群日志的脱敏状态。 - 详情参见 [用户自主管理日志脱敏](/tidb-cloud/tidb-cloud-log-redaction.md)。 + 了解更多信息，请参见 [用户自主管理日志脱敏](/tidb-cloud/tidb-cloud-log-redaction.md)。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（AWS 托管）现已正式（GA）支持使用客户自管加密密钥（CMEK）进行静态加密。 +- 在 AWS 上托管的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群现已正式支持（GA）使用客户自管加密密钥（CMEK）进行静态加密。 该功能允许你通过 Key Management Service（KMS）管理的对称加密密钥保护静态数据。 - 详情参见 [在 AWS 上使用客户自管加密密钥进行静态加密](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)。 + 了解更多信息，请参见 [在 AWS 上使用客户自管加密密钥进行静态加密](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)。 ## 2025 年 6 月 17 日 **通用变更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中，16 vCPU 和 32 vCPU 的 TiKV 节点最大存储容量由 **6144 GiB** 调整为 **4096 GiB**。 +- 对于 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群，16 vCPU 和 32 vCPU 的 TiKV 节点最大存储容量由 **6144 GiB** 调整为 **4096 GiB**。 - 详情参见 [TiKV 节点存储容量](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)。 + 了解更多信息，请参见 [TiKV 节点存储容量](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)。 **控制台变更** @@ -385,88 +405,88 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] - - 左侧导航栏的入口会根据组合框当前选择动态调整，帮助你聚焦最相关功能。 - - **Support**、**Notification** 和账号入口现始终显示在左侧导航栏底部，便于快速访问。 + - 左侧导航栏的入口会根据组合框当前选择动态调整，帮助你聚焦最相关的功能。 + - **Support**、**Notification** 和账户入口现始终显示在左侧导航栏底部，便于快速访问。 ## 2025 年 6 月 4 日 **通用变更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 在 Microsoft Azure 上公测。 +- [TiDB Cloud 专属版](/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 专属版集群。 - - AWS 和 Google Cloud 上的所有核心功能在 Azure 上均已支持。 - - 目前 Azure 支持 East US 2、日本东部和东南亚 3 个区域，后续将支持更多区域。 - - Azure 上的 TiDB Cloud Dedicated 集群需 TiDB 版本 v7.5.3 或更高。 + - 在 AWS 和 Google Cloud 上的所有核心功能均已在 Azure 上全面支持。 + - Azure 目前支持 East US 2、日本东部和东南亚三个区域，更多区域即将上线。 + - Azure 上的 TiDB Cloud 专属版集群需 TiDB 版本 v7.5.3 或更高。 - 快速入门文档： + 快速上手 Azure 上的 TiDB Cloud 专属版，请参见以下文档： - - [在 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) - -- Prometheus 集成为 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群提供更多监控指标。 + - [在 Azure 上创建 TiDB Cloud 专属版集群](/tidb-cloud/create-tidb-cluster.md) + - [通过 Azure 私有端点连接 TiDB Cloud 专属版集群](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md) + - [导入数据到 Azure 上的 TiDB Cloud 专属版集群](/tidb-cloud/import-csv-files.md) - 你现在可以将 `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)。 +- Prometheus 集成为 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群提供了更多监控指标，增强监控能力。 + + 你现在可以将 `tidbcloud_disk_read_latency`、`tidbcloud_kv_request_duration` 等更多指标集成到 Prometheus，追踪 TiDB Cloud 专属版的更多性能维度。 + + 了解可用指标及如何为新老用户启用，请参见 [将 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) 存储价格正式发布。 +- TiKV [标准](/tidb-cloud/size-your-cluster.md#standard-storage) 和 [性能](/tidb-cloud/size-your-cluster.md#performance-and-plus-storage) 存储定价正式发布。 - 优惠期自 **2025 年 6 月 5 日 00:00 UTC** 起结束，之后恢复标准价格。详情参见 [TiDB Cloud Dedicated 价格明细](https://www.pingcap.com/tidb-dedicated-pricing-details/#node-cost)。 + 优惠期自 **2025 年 6 月 5 日 00:00 UTC** 起结束，届时价格恢复为标准价。更多 TiDB Cloud 专属版价格信息，请参见 [TiDB Cloud 专属版定价详情](https://www.pingcap.com/tidb-dedicated-pricing-details/#node-cost)。 **控制台变更** -- 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群 TiFlash 节点规格配置交互体验。 +- 优化 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建时 TiFlash 节点规格配置的交互体验。 - 你现在可以在创建 TiDB Cloud Dedicated 集群时通过开关控制 TiFlash 配置，提升配置的直观性和流畅性。 + 你现在可以在创建 TiDB Cloud 专属版集群时通过开关按钮控制 TiFlash 配置，使配置过程更直观、流畅。 ## 2025 年 5 月 27 日 **通用变更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 changefeed 支持将数据流式同步到 [Apache Pulsar](https://pulsar.apache.org)。 +- [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的 changefeed 现支持将数据流式同步到 [Apache Pulsar](https://pulsar.apache.org)。 - 该功能让你能将 TiDB Cloud Dedicated 集群与更多下游系统集成，满足更多数据集成需求。使用该功能需确保集群版本为 v7.5.1 或更高。 + 该功能使你能够将 TiDB Cloud 专属版集群与更多下游系统集成，满足更多数据集成需求。使用该功能需确保 TiDB Cloud 专属版集群版本为 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#tidb-cloud-serverless) 现已支持全文检索（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 过滤、分组、关联等功能无缝结合。 + - 直接文本检索：可直接查询字符串列，无需 embedding。 + - 多语言支持：自动检测并分析多语言文本，即使在同一张表中，无需指定语言。 + - 基于相关性的排序：结果采用业界标准 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 节点最大存储容量提升： +- [TiDB Cloud 专属版](/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 专属版集群的分析型数据存储能力，提高了工作负载扩展效率，满足不断增长的数据需求。 - 详情参见 [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 日，届时价格恢复为标准价。 +- TiKV [标准](/tidb-cloud/size-your-cluster.md#standard-storage) 和 [性能](/tidb-cloud/size-your-cluster.md#performance-and-plus-storage) 存储类型的优惠期延长至 2025 年 6 月 5 日。届时价格将恢复为标准价。 **控制台变更** -- 优化 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群 **Backup Setting** 页面布局，提升备份配置体验。 +- 优化 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群 **Backup Setting** 页布局，提升备份配置体验。 - 详情参见 [备份与恢复 TiDB Cloud Dedicated 数据](/tidb-cloud/backup-and-restore.md)。 + 了解更多信息，请参见 [备份与恢复 TiDB Cloud 专属版数据](/tidb-cloud/backup-and-restore.md)。 ## 2025 年 4 月 22 日 @@ -474,21 +494,21 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] - 现已支持导出数据到阿里云 OSS。 - [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群现支持使用 [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/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#tidb-cloud-serverless) 集群 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)。 +- [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)。 ## 2025 年 4 月 15 日 **通用变更** -- 支持从 [阿里云对象存储 OSS](https://www.alibabacloud.com/en/product/object-storage-service) 导入数据到 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群。 +- 支持从 [阿里云对象存储服务（OSS）](https://www.alibabacloud.com/en/product/object-storage-service) 导入数据到 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群。 该功能简化了数据迁移到 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) @@ -497,171 +517,171 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] **通用变更** -- [TiDB Node Groups](/tidb-cloud/tidb-node-group-overview.md) 功能现已在 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（AWS 和 Google Cloud 托管）正式发布（GA）。 +- [TiDB 节点组](/tidb-cloud/tidb-node-group-overview.md) 功能现已在托管于 AWS 和 Google Cloud 的 [TiDB Cloud 专属版](/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 节点组](/tidb-cloud/tidb-node-group-management.md)。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（AWS 托管）引入 [Standard storage](/tidb-cloud/size-your-cluster.md#standard-storage) 类型的 TiKV 节点。 +- 在托管于 AWS 的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中引入 [标准存储](/tidb-cloud/size-your-cluster.md#standard-storage) 类型，适用于 TiKV 节点。 - Standard 存储类型适用于大多数负载，在性能和成本之间实现平衡。 + 标准存储类型适合大多数工作负载，在性能和成本之间实现平衡。 **主要优势：** - - **性能提升**：为 Raft 日志预留充足磁盘资源，减少 Raft 与数据存储的 I/O 争用，提升 TiKV 读写性能。 - - **稳定性增强**：将关键 Raft 操作与数据负载隔离，确保性能更可预测。 - - **成本效益**：与原有存储类型相比，提供更高性能且价格更具竞争力。 + - **性能提升**：为 Raft 日志预留充足磁盘资源，减少 Raft 与数据存储的 I/O 争用，从而提升 TiKV 的读写性能。 + - **稳定性增强**：将关键 Raft 操作与数据工作负载隔离，确保更可预测的性能。 + - **成本效益**：与之前的存储类型相比，在具有竞争力的价格下提供更高性能。 **可用性：** - 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，自动采用 Standard 存储类型。现有集群仍使用原有 [Basic storage](/tidb-cloud/size-your-cluster.md#basic-storage) 类型，无需迁移。 + 标准存储类型会自动应用于 2025 年 4 月 1 日及以后在 AWS 上新建的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群，且需支持的版本（>= 7.5.5、8.1.2 或 8.5.0）。现有集群仍使用之前的 [基础存储](/tidb-cloud/size-your-cluster.md#basic-storage) 类型，无需迁移。 - Standard 存储类型价格与 Basic 存储不同。详情参见 [价格说明](https://www.pingcap.com/tidb-dedicated-pricing-details/)。 + 标准存储的价格与基础存储不同。了解更多信息，请参见 [定价](https://www.pingcap.com/tidb-dedicated-pricing-details/)。 ## 2025 年 3 月 25 日 **控制台变更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群支持为公网端点配置防火墙规则。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群现支持为公有端点配置防火墙规则。 - 你现在可以为 TiDB Cloud Serverless 集群配置防火墙规则，控制公网端点的访问。可在 [TiDB Cloud 控制台](https://tidbcloud.com/) 直接指定允许的 IP 地址或范围，提升安全性。 + 你现在可以为 TiDB Cloud Serverless 集群配置防火墙规则，控制通过公有端点的访问。可在 [TiDB Cloud 控制台](https://tidbcloud.com/) 直接指定允许的 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 日 **通用变更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（Google Cloud 部署）支持创建 TiDB 节点组，提升资源管理灵活性。 +- 支持为部署在 Google Cloud 的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建 TiDB 节点组，提升资源管理灵活性。 - 详情参见 [TiDB Node Group 概览](/tidb-cloud/tidb-node-group-overview.md)。 + 了解更多信息，请参见 [TiDB 节点组概述](/tidb-cloud/tidb-node-group-overview.md)。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群（AWS 部署）支持将数据库审计日志文件存储在 TiDB Cloud。 +- 支持将数据库审计日志文件存储在 TiDB Cloud，适用于部署在 AWS 的 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 - 你可以直接从 TiDB Cloud 下载这些审计日志文件。该功能仅支持按需申请。 + 你可以直接从 TiDB Cloud 下载这些审计日志文件。该功能仅可按需申请。 - 详情参见 [数据库审计日志](/tidb-cloud/tidb-cloud-auditing.md)。 + 了解更多信息，请参见 [数据库审计日志](/tidb-cloud/tidb-cloud-auditing.md)。 -- 提升 TiDB Cloud 账号安全性，优化多因素认证（MFA）管理。该功能适用于 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 服务通过现代通信工具、主动支持和先进的 AI 能力，增强你与 TiDB Cloud 的连接，带来无缝且以客户为中心的体验。 - Connected Care 服务包括： + Connected Care 服务包括以下功能： - - **Clinic service**：高级监控与诊断，优化性能。 - - **AI chat in IM**：通过即时通讯工具获得 AI 实时帮助。 - - **IM 订阅告警与工单进展**：通过 IM 实时获知告警和工单进度。 - - **IM 工单交互**：可通过 IM 工具创建和跟进支持工单。 + - **Clinic 服务**：高级监控与诊断，优化性能。 + - **IM 中的 AI 聊天**：通过即时通讯工具获得 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#tidb-cloud-serverless) 集群支持从 GCS 和 Azure Blob Storage 导入数据。 +- 支持从 GCS 和 Azure Blob Storage 导入数据到 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群。 - 你现在可以使用 Google Cloud 服务账号密钥或 Azure SAS Token 认证，从 Google Cloud Storage（GCS）和 Azure Blob Storage 导入数据到 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#tidb-cloud-serverless) 集群单次任务支持导入最大 250 MiB 的本地 CSV 文件（原上限为 50 MiB）。 +- 支持将单个本地 CSV 文件导入 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群，单任务文件大小上限由 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 日 **通用变更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群新增支持 AWS 区域：`Jakarta (ap-southeast-3)`。 +- [TiDB Cloud 专属版](/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 日 **通用变更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持创建 TiDB 节点组，提升资源管理灵活性。 +- 支持为 [TiDB Cloud 专属版](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群创建 TiDB 节点组，提升资源管理灵活性。 - 详情参见 [TiDB Node Group 概览](/tidb-cloud/tidb-node-group-overview.md)。 + 了解更多信息，请参见 [TiDB 节点组概述](/tidb-cloud/tidb-node-group-overview.md)。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群支持通过 Private Connect（Beta）连接 AWS 和 Google Cloud 上的通用 Kafka。 +- 支持通过 Private Connect（beta）将 [TiDB Cloud 专属版](/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 Sink to 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#tidb-cloud-serverless) 集群区域级高可用（Beta）。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter) 集群区域级高可用性（beta）。 - 该功能适用于对基础设施冗余和业务连续性要求极高的负载。主要特性： + 该功能适用于对基础设施冗余和业务连续性要求极高的工作负载。主要功能包括： - - 节点分布于多个可用区，确保单区故障时高可用。 - - 关键 OLTP 组件（如 PD、TiKV）跨可用区冗余部署。 - - 主区故障时自动故障转移，最小化服务中断。 + - 节点分布在多个可用区，确保单区故障时的高可用性。 + - 关键 OLTP（联机事务处理）组件（如 PD 和 TiKV）在可用区间冗余部署。 + - 主可用区故障时自动故障转移，最小化服务中断。 - 目前仅 AWS 东京（ap-northeast-1）区域支持，且仅在集群创建时可启用。 + 该功能目前仅在 AWS 东京（ap-northeast-1）区域可用，且只能在集群创建时启用。 - 详情参见 [TiDB Cloud Serverless 高可用性](/tidb-cloud/serverless-high-availability.md)。 + 了解更多信息，请参见 [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)。 +- 新建 [TiDB Cloud 专属版](/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)。 **控制台变更** - 数据导出服务增强： - - [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 支持通过 [TiDB Cloud 控制台](https://tidbcloud.com/) 导出数据到 Google Cloud Storage 和 Azure Blob Storage。 + - 支持通过 [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)。 + 了解更多信息，请参见 [从 TiDB Cloud Serverless 导出数据](/tidb-cloud/serverless-export.md) 和 [为 TiDB Cloud Serverless 配置外部存储访问](/tidb-cloud/serverless-external-storage.md)。 \ No newline at end of file diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index 0ad6bb4f16873..b2b0b3ea33deb 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -1,141 +1,141 @@ --- -title: Chat2Query API 入门指南 -summary: 了解如何使用 TiDB Cloud Chat2Query API，通过提供指令来生成和执行 SQL 语句。 +title: Get Started with Chat2Query API +summary: 了解如何通过 TiDB Cloud Chat2Query API，使用 AI 根据指令生成并执行 SQL 语句。 --- -# Chat2Query API 入门指南 +# Get Started with Chat2Query API -TiDB Cloud 提供 Chat2Query API，这是一个 RESTful 接口，使你能够通过提供指令来使用 AI 生成和执行 SQL 语句。然后，API 会为你返回查询结果。 +TiDB Cloud 提供了 Chat2Query API，这是一个 RESTful 接口，可以让你通过提供指令，使用 AI 生成并执行 SQL 语句。随后，API 会返回查询结果。 -Chat2Query API 只能通过 HTTPS 访问，确保所有通过网络传输的数据都使用 TLS 加密。 +Chat2Query API 只能通过 HTTPS 访问，确保所有在网络上传输的数据都通过 TLS 加密。 -> **注意：** +> **Note:** > -> Chat2Query API 适用于 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群。要在 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群上使用 Chat2Query API，请联系 [TiDB Cloud 支持团队](/tidb-cloud/tidb-cloud-support.md)。 +> Chat2Query API 仅适用于托管在 AWS 上的 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群。如需在 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群上使用 Chat2Query API，请联系 [TiDB Cloud support](/tidb-cloud/tidb-cloud-support.md)。 ## 开始之前 -在调用 Chat2Query 端点之前，你需要创建一个 Chat2Query Data App 并为该 Data App 创建一个 API 密钥。 +在调用 Chat2Query 端点之前，你需要创建一个 Chat2Query Data App，并为该 Data App 创建一个 API key。 ### 创建 Chat2Query Data App 要为你的项目创建 Data App，请执行以下步骤： -1. 在项目的 [**Data Service**](https://tidbcloud.com/project/data-service) 页面，点击左侧窗格中的 **Create DataApp**。此时会显示数据应用创建对话框。 +1. 在项目的 [**Data Service**](https://tidbcloud.com/project/data-service) 页面左侧，点击 **Create DataApp**。此时会弹出数据应用创建对话框。 - > **提示：** + > **Tip:** > - > 如果你在集群的 **SQL Editor** 页面，也可以通过点击右上角的 **...** ，选择 **Access Chat2Query via API**，然后点击 **New Chat2Query Data App** 来打开数据应用创建对话框。 + > 如果你在集群的 **SQL Editor** 页面，也可以通过点击右上角的 **...**，选择 **Access Chat2Query via API**，再点击 **New Chat2Query Data App** 打开数据应用创建对话框。 -2. 在对话框中，为你的 Data App 定义一个名称，选择所需的集群作为数据源，并选择 **Chat2Query Data App** 作为 **Data App** 类型。你还可以选择为 App 编写描述。 +2. 在对话框中，为你的 Data App 命名，选择所需的集群作为数据源，并将 **Data App** 类型选择为 **Chat2Query Data App**。你还可以为该应用填写描述（可选）。 3. 点击 **Create**。 - 新创建的 Chat2Query Data App 将显示在左侧窗格中。在此 Data App 下，你可以找到 Chat2Query 端点列表。 + 新创建的 Chat2Query Data App 会显示在左侧面板。在该 Data App 下，你可以看到 Chat2Query 端点的列表。 -### 创建 API 密钥 +### 创建 API key -在调用端点之前，你需要为 Chat2Query Data App 创建一个 API 密钥，该密钥用于端点访问 TiDB Cloud 集群中的数据。 +在调用端点之前，你需要为 Chat2Query Data App 创建一个 API key，端点会使用该 key 访问你在 TiDB Cloud 集群中的数据。 -要创建 API 密钥，请执行以下步骤： +创建 API key 的步骤如下： -1. 在 [**Data Service**](https://tidbcloud.com/project/data-service) 的左侧窗格中，点击你的 Chat2Query Data App 以在右侧查看其详细信息。 +1. 在 [**Data Service**](https://tidbcloud.com/project/data-service) 左侧面板，点击你的 Chat2Query Data App，在右侧查看其详细信息。 2. 在 **Authentication** 区域，点击 **Create API Key**。 -3. 在 **Create API Key** 对话框中，输入描述，然后为你的 API 密钥选择以下角色之一： +3. 在 **Create API Key** 对话框中，输入描述，并为你的 API key 选择以下角色之一： - - `Chat2Query Admin`：允许 API 密钥管理数据摘要、根据提供的指令生成 SQL 语句，并执行任何 SQL 语句。 - - `Chat2Query Data Summary Management Role`：仅允许 API 密钥生成和更新数据摘要。 + - `Chat2Query Admin`：允许该 API key 管理数据摘要、根据指令生成 SQL 语句，并执行任意 SQL 语句。 + - `Chat2Query Data Summary Management Role`：仅允许该 API key 生成和更新数据摘要。 - > **提示：** + > **Tip:** > - > 对于 Chat2Query API，数据摘要是 AI 对你的数据库的分析结果，包括你的数据库描述、表描述和列描述。通过生成数据库的数据摘要，你可以在通过提供指令生成 SQL 语句时获得更准确的响应。 + > 对于 Chat2Query API，数据摘要是 AI 对你的数据库分析的结果，包括数据库描述、表描述和列描述。通过为数据库生成数据摘要，可以在根据指令生成 SQL 语句时获得更准确的响应。 - - `Chat2Query SQL ReadOnly`：仅允许 API 密钥根据提供的指令生成 SQL 语句并执行 `SELECT` SQL 语句。 - - `Chat2Query SQL ReadWrite`：允许 API 密钥根据提供的指令生成 SQL 语句并执行任何 SQL 语句。 + - `Chat2Query SQL ReadOnly`：仅允许该 API key 根据指令生成 SQL 语句并执行 `SELECT` SQL 语句。 + - `Chat2Query SQL ReadWrite`：允许该 API key 根据指令生成 SQL 语句并执行任意 SQL 语句。 -4. 默认情况下，API 密钥永不过期。如果你想为密钥设置过期时间，请点击 **Expires in**，选择时间单位（`Minutes`、`Days` 或 `Months`），然后填写所需的时间单位数值。 +4. 默认情况下，API key 永不过期。如果你希望为该 key 设置过期时间，点击 **Expires in**，选择时间单位（`Minutes`、`Days` 或 `Months`），并填写期望的时间数值。 5. 点击 **Next**。此时会显示公钥和私钥。 - 确保你已将私钥复制并保存在安全的位置。离开此页面后，你将无法再次获取完整的私钥。 + 请确保你已将私钥复制并保存在安全的位置。离开此页面后，将无法再次获取完整的私钥。 6. 点击 **Done**。 ## 调用 Chat2Query 端点 -> **注意：** +> **Note:** > -> 每个 Chat2Query Data App 每天有 100 个请求的速率限制。如果超过速率限制，API 将返回 `429` 错误。如需更多配额，你可以向我们的支持团队[提交请求](https://tidb.support.pingcap.com/)。 +> 每个 Chat2Query Data App 每天有 100 次请求的速率限制。如果超过限制，API 会返回 `429` 错误。如需更多配额，可以 [提交请求](https://tidb.support.pingcap.com/) 联系我们的支持团队。 在每个 Chat2Query Data App 中，你可以找到以下端点： -- Chat2Query v3 端点：名称以 `/v3` 开头的端点，如 `/v3/dataSummaries` 和 `/v3/chat2data`（推荐） -- Chat2Query v2 端点：名称以 `/v2` 开头的端点，如 `/v2/dataSummaries` 和 `/v2/chat2data` +- Chat2Query v3 端点：端点名称以 `/v3` 开头，如 `/v3/dataSummaries` 和 `/v3/chat2data`（推荐） +- Chat2Query v2 端点：端点名称以 `/v2` 开头，如 `/v2/dataSummaries` 和 `/v2/chat2data` - Chat2Query v1 端点：`/v1/chat2data`（已弃用） -> **提示：** +> **Tip:** > -> 与 `/v1/chat2data` 相比，`/v3/chat2data` 和 `/v2/chat2data` 需要你先通过调用 `/v3/dataSummaries` 或 `/v2/dataSummaries` 分析你的数据库。因此，`/v3/chat2data` 和 `/v2/chat2data` 返回的结果通常更准确。 +> 与 `/v1/chat2data` 相比，`/v3/chat2data` 和 `/v2/chat2data` 需要你先通过调用 `/v3/dataSummaries` 或 `/v2/dataSummaries` 对数据库进行分析。因此，`/v3/chat2data` 和 `/v2/chat2data` 返回的结果通常更为准确。 ### 获取端点的代码示例 -TiDB Cloud 提供代码示例来帮助你快速调用 Chat2Query 端点。要获取 Chat2Query 端点的代码示例，请执行以下步骤： +TiDB Cloud 提供了代码示例，帮助你快速调用 Chat2Query 端点。获取 Chat2Query 端点代码示例的步骤如下： -1. 在 [**Data Service**](https://tidbcloud.com/project/data-service) 页面的左侧窗格中，点击 Chat2Query 端点的名称。 +1. 在 [**Data Service**](https://tidbcloud.com/project/data-service) 页面左侧，点击某个 Chat2Query 端点的名称。 - 右侧将显示调用此端点的信息，如端点 URL、代码示例和请求方法。 + 右侧会显示调用该端点的信息，如端点 URL、代码示例和请求方法。 2. 点击 **Show Code Example**。 -3. 在显示的对话框中，选择要用于调用端点的集群、数据库和身份验证方法，然后复制代码示例。 +3. 在弹出的对话框中，选择你想要调用端点的集群、数据库和认证方式，然后复制代码示例。 - > **注意：** + > **Note:** > - > 对于某些端点（如 `/v2/jobs/{job_id}`），你只需要选择身份验证方法。 + > 对于某些端点（如 `/v2/jobs/{job_id}`），你只需选择认证方式即可。 -4. 要调用端点，你可以将示例粘贴到你的应用程序中，用你自己的参数替换示例中的参数（如用你的 API 密钥替换 `${PUBLIC_KEY}` 和 `${PRIVATE_KEY}` 占位符），然后运行它。 +4. 要调用端点，你可以将示例粘贴到你的应用中，将示例中的参数（如 `${PUBLIC_KEY}` 和 `${PRIVATE_KEY}` 占位符）替换为你自己的 API key，然后运行即可。 -### 调用 Chat2Query v3 端点或 v2 端点 +### 调用 Chat2Query v3 或 v2 端点 -TiDB Cloud Data Service 提供以下 Chat2Query v3 端点和 v2 端点： +TiDB Cloud Data Service 提供了以下 Chat2Query v3 和 v2 端点： -| 方法 | 端点 | 描述 | +| Method | Endpoint | Description | | ------ | -------- | ----------- | -| POST | `/v3/dataSummaries` | 此端点使用人工智能分析为你的数据库模式、表模式和列模式生成数据摘要。 | -| GET | `/v3/dataSummaries` | 此端点检索你数据库的所有数据摘要。 | -| GET | `/v3/dataSummaries/{data_summary_id}` | 此端点检索特定的数据摘要。 | -| PUT | `/v3/dataSummaries/{data_summary_id}` | 此端点更新特定的数据摘要。 | -| PUT | `/v3/dataSummaries/{data_summary_id}/tables/{table_name}` | 此端点更新特定数据摘要中特定表的描述。 | -| PUT | `/v3/dataSummaries/{data_summary_id}/tables/{table_name}/columns` | 此端点更新特定数据摘要中特定表的列描述。 | -| POST | `/v3/knowledgeBases` | 此端点创建新的知识库。有关知识库相关端点的使用信息，请参见[使用知识库](/tidb-cloud/use-chat2query-knowledge.md)。 | -| GET | `/v3/knowledgeBases` | 此端点检索所有知识库。 | -| GET | `/v3/knowledgeBases/{knowledge_base_id}` | 此端点检索特定的知识库。 | -| PUT | `/v3/knowledgeBases/{knowledge_base_id}` | 此端点更新特定的知识库。 | -| POST | `/v3/knowledgeBases/{knowledge_base_id}/data` | 此端点向特定知识库添加数据。 | -| GET | `/v3/knowledgeBases/{knowledge_base_id}/data` | 此端点从特定知识库检索数据。 | -| PUT | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | 此端点更新知识库中的特定数据。 | -| DEL | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | 此端点从知识库中删除特定数据。 | -| POST | `/v3/sessions` | 此端点创建新的会话。有关会话相关端点的使用信息，请参见[开始多轮 Chat2Query](/tidb-cloud/use-chat2query-sessions.md)。 | -| GET | `/v3/sessions` | 此端点检索所有会话的列表。 | -| GET | `/v3/sessions/{session_id}` | 此端点检索特定会话的详细信息。 | -| PUT | `/v3/sessions/{session_id}` | 此端点更新特定会话。 | -| PUT | `/v3/sessions/{session_id}/reset` | 此端点重置特定会话。 | -| POST | `/v3/sessions/{session_id}/chat2data` | 此端点在特定会话中使用人工智能生成和执行 SQL 语句。更多信息，请参见[使用会话开始多轮 Chat2Query](/tidb-cloud/use-chat2query-sessions.md)。 | -| POST | `/v3/chat2data` | 此端点使你能够通过提供数据摘要 ID 和指令使用人工智能生成和执行 SQL 语句。 | -| POST | `/v3/refineSql` | 此端点使用人工智能优化现有的 SQL 查询。 | -| POST | `/v3/suggestQuestions` | 此端点根据提供的数据摘要建议问题。 | -| POST | `/v2/dataSummaries` | 此端点使用人工智能为你的数据库模式、表模式和列模式生成数据摘要。 | -| GET | `/v2/dataSummaries` | 此端点检索所有数据摘要。 | -| POST | `/v2/chat2data` | 此端点使你能够通过提供数据摘要 ID 和指令使用人工智能生成和执行 SQL 语句。 | -| GET | `/v2/jobs/{job_id}` | 此端点使你能够查询特定数据摘要生成作业的状态。 | - -调用 `/v3/chat2data` 和 `/v2/chat2data` 的步骤相同。以下部分以 `/v3/chat2data` 为例说明如何调用它。 +| POST | `/v3/dataSummaries` | 该端点通过人工智能分析，为你的数据库 schema、表 schema 和列 schema 生成数据摘要。 | +| GET | `/v3/dataSummaries` | 该端点获取你数据库的所有数据摘要。 | +| GET | `/v3/dataSummaries/{data_summary_id}` | 该端点获取指定的数据摘要。 | +| PUT | `/v3/dataSummaries/{data_summary_id}` | 该端点更新指定的数据摘要。 | +| PUT | `/v3/dataSummaries/{data_summary_id}/tables/{table_name}` | 该端点更新指定数据摘要中某个表的描述。 | +| PUT | `/v3/dataSummaries/{data_summary_id}/tables/{table_name}/columns` | 该端点更新指定数据摘要中某个表的列描述。 | +| POST | `/v3/knowledgeBases` | 该端点创建新的知识库。关于知识库相关端点的用法，详见 [Use knowledge bases](/tidb-cloud/use-chat2query-knowledge.md)。 | +| GET | `/v3/knowledgeBases` | 该端点获取所有知识库。 | +| GET | `/v3/knowledgeBases/{knowledge_base_id}` | 该端点获取指定的知识库。 | +| PUT | `/v3/knowledgeBases/{knowledge_base_id}` | 该端点更新指定的知识库。 | +| POST | `/v3/knowledgeBases/{knowledge_base_id}/data` | 该端点向指定知识库添加数据。 | +| GET | `/v3/knowledgeBases/{knowledge_base_id}/data` | 该端点从指定知识库获取数据。 | +| PUT | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | 该端点更新知识库中的指定数据。 | +| DEL | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | 该端点从知识库中删除指定数据。 | +| POST | `/v3/sessions` | 该端点创建新的会话。关于会话相关端点的用法，详见 [Start multi-round Chat2Query](/tidb-cloud/use-chat2query-sessions.md)。 | +| GET | `/v3/sessions` | 该端点获取所有会话的列表。 | +| GET | `/v3/sessions/{session_id}` | 该端点获取指定会话的详细信息。 | +| PUT | `/v3/sessions/{session_id}` | 该端点更新指定会话。 | +| PUT | `/v3/sessions/{session_id}/reset` | 该端点重置指定会话。 | +| POST | `/v3/sessions/{session_id}/chat2data` | 该端点在指定会话中通过人工智能生成并执行 SQL 语句。详见 [Start multi-round Chat2Query by using sessions](/tidb-cloud/use-chat2query-sessions.md)。 | +| POST | `/v3/chat2data` | 该端点允许你通过提供数据摘要 ID 和指令，使用人工智能生成并执行 SQL 语句。 | +| POST | `/v3/refineSql` | 该端点通过人工智能优化已有 SQL 查询。 | +| POST | `/v3/suggestQuestions` | 该端点基于提供的数据摘要推荐问题。 | +| POST | `/v2/dataSummaries` | 该端点通过人工智能为你的数据库 schema、表 schema 和列 schema 生成数据摘要。 | +| GET | `/v2/dataSummaries` | 该端点获取所有数据摘要。 | +| POST | `/v2/chat2data` | 该端点允许你通过提供数据摘要 ID 和指令，使用人工智能生成并执行 SQL 语句。 | +| GET | `/v2/jobs/{job_id}` | 该端点允许你查询指定数据摘要生成任务的状态。 | + +调用 `/v3/chat2data` 和 `/v2/chat2data` 的步骤相同。以下以 `/v3/chat2data` 为例，介绍如何调用。 #### 1. 通过调用 `/v3/dataSummaries` 生成数据摘要 -在调用 `/v3/chat2data` 之前，先让 AI 分析数据库并通过调用 `/v3/dataSummaries` 生成数据摘要，这样 `/v3/chat2data` 在后续的 SQL 生成中可以获得更好的性能。 +在调用 `/v3/chat2data` 之前，先通过调用 `/v3/dataSummaries` 让 AI 分析数据库并生成数据摘要，这样 `/v3/chat2data` 在后续生成 SQL 时能获得更好的效果。 -以下是调用 `/v3/dataSummaries` 分析 `sp500insight` 数据库并为该数据库生成数据摘要的代码示例： +以下是调用 `/v3/dataSummaries` 分析 `sp500insight` 数据库并生成数据摘要的代码示例： ```bash curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v3/dataSummaries'\ @@ -148,12 +148,12 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.dev.tidbcloud.com/api/v1beta/app/chat2query-`/endpoint/v2/jobs/{job_id}'\ @@ -186,47 +186,47 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request GET 'https://.data.dev.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v2/jobs/{job_id}'\ @@ -298,12 +298,12 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request GET 'https:// **注意：** +> **Note:** > -> Chat2Data v1 端点已弃用。建议你改用 Chat2Data v3 端点。 +> Chat2Data v1 端点已弃用。建议优先调用 Chat2Data v3 端点。 TiDB Cloud Data Service 提供以下 Chat2Query v1 端点： -| 方法 | 端点| 描述 | +| Method | Endpoint| Description | | ---- | ---- |---- | -| POST | `/v1/chat2data` | 此端点允许你通过提供目标数据库名称和指令使用人工智能生成和执行 SQL 语句。 | +| POST | `/v1/chat2data` | 该端点允许你通过提供目标数据库名称和指令，使用人工智能生成并执行 SQL 语句。 | -你可以直接调用 `/v1/chat2data` 端点来生成和执行 SQL 语句。与 `/v2/chat2data` 相比，`/v1/chat2data` 提供更快的响应但性能较低。 +你可以直接调用 `/v1/chat2data` 端点生成并执行 SQL 语句。与 `/v2/chat2data` 相比，`/v1/chat2data` 响应更快，但性能较低。 -TiDB Cloud 生成代码示例来帮助你调用端点。要获取示例并运行代码，请参见[获取端点的代码示例](#获取端点的代码示例)。 +TiDB Cloud 会生成代码示例，帮助你调用端点。获取示例及运行代码，详见 [获取端点的代码示例](#get-the-code-example-of-an-endpoint)。 调用 `/v1/chat2data` 时，你需要替换以下参数： -- 用你的 API 密钥替换 `${PUBLIC_KEY}` 和 `${PRIVATE_KEY}` 占位符。 -- 用你要查询的表名替换 `` 占位符。如果不指定表名，AI 将查询数据库中的所有表。 -- 用你希望 AI 生成和执行 SQL 语句的指令替换 `` 占位符。 +- 将 `${PUBLIC_KEY}` 和 `${PRIVATE_KEY}` 占位符替换为你的 API key。 +- 将 `` 占位符替换为你要查询的表名。如果未指定表名，AI 会查询数据库中的所有表。 +- 将 `` 占位符替换为你希望 AI 生成并执行 SQL 语句的指令。 -> **注意：** +> **Note:** > -> - 每个 Chat2Query Data App 每天有 100 个请求的速率限制。如果超过速率限制，API 将返回 `429` 错误。如需更多配额，你可以向我们的支持团队[提交请求](https://tidb.support.pingcap.com/)。 -> - 具有 `Chat2Query Data Summary Management Role` 角色的 API 密钥不能调用 Chat2Data v1 端点。 +> - 每个 Chat2Query Data App 每天有 100 次请求的速率限制。如果超过限制，API 会返回 `429` 错误。如需更多配额，可以 [提交请求](https://tidb.support.pingcap.com/) 联系我们的支持团队。 +> - 角色为 `Chat2Query Data Summary Management Role` 的 API Key 无法调用 Chat2Data v1 端点。 -以下代码示例用于计算 `sp500insight.users` 表中有多少用户： +以下代码示例用于统计 `sp500insight.users` 表中的用户数量： ```bash curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.dev.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/chat2data'\ @@ -377,12 +377,12 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https:// **Note:** > -> 知识库相关接口在 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#tidb-cloud-serverless) 集群中默认可用。若要在 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群中使用知识库相关接口，请联系 [TiDB Cloud support](/tidb-cloud/tidb-cloud-support.md)。 +> 知识库相关接口仅适用于托管在 AWS 上的 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群。如需在 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群上使用知识库相关接口，请联系 [TiDB Cloud support](/tidb-cloud/tidb-cloud-support.md)。 ## 开始前的准备 @@ -20,19 +20,19 @@ summary: 了解如何通过使用 Chat2Query 知识库 API 提升 Chat2Query 的 - 一个 [Chat2Query Data App](/tidb-cloud/use-chat2query-api.md#create-a-chat2query-data-app) - 一个 [Chat2Query Data App 的 API key](/tidb-cloud/use-chat2query-api.md#create-an-api-key) -## 第 1 步：为已关联的数据库创建知识库 +## 步骤 1. 为已关联的数据库创建知识库 > **Note:** > -> Chat2Query 使用的知识是**按照数据库维度进行结构化**的。你可以将多个 Chat2Query Data App 连接到同一个数据库，但每个 Chat2Query Data App 只能使用其所关联数据库的知识。 +> Chat2Query 使用的知识是**以数据库维度进行结构化**的。你可以将多个 Chat2Query Data App 连接到同一个数据库，但每个 Chat2Query Data App 只能使用其所关联数据库的知识。 -在你的 Chat2Query Data App 中，可以通过调用 `/v3/knowledgeBases` 接口为某个特定数据库创建知识库。创建完成后，你将获得一个 `knowledge_base_id`，用于后续的知识管理。 +在你的 Chat2Query Data App 中，可以通过调用 `/v3/knowledgeBases` 接口为指定数据库创建知识库。创建完成后，你将获得一个 `knowledge_base_id`，用于后续知识管理。 以下是调用该接口的一般代码示例。 > **Tip:** > -> 若要获取该接口的具体代码示例，请在 Data App 左侧面板点击接口名称，然后点击 **Show Code Example**。更多信息参见 [Get the example code of an endpoint](/tidb-cloud/use-chat2query-api.md#get-the-code-example-of-an-endpoint)。 +> 如需获取该接口的具体代码示例，请在 Data App 左侧面板点击接口名称，然后点击 **Show Code Example**。更多信息参见 [Get the example code of an endpoint](/tidb-cloud/use-chat2query-api.md#get-the-code-example-of-an-endpoint)。 ```bash curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v3/knowledgeBases'\ @@ -59,9 +59,9 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https:// **Note:** > @@ -125,18 +125,18 @@ Term-sheet explanation 指对某个特定术语或一组相似术语的详细解 Term-sheet explanation 主要用于提升 Chat2Query 对用户查询的理解能力，尤其适用于以下情况： -- **处理行业专有术语或缩写时**：当你的查询包含行业专有术语或缩写，且这些术语并非通用时，使用 term-sheet explanation 可以帮助 Chat2Query 理解其含义和用法。 +- **处理行业专有术语或缩写时**：当你的查询包含行业专有术语或缩写，且这些术语并非通用时，使用 term-sheet explanation 可以帮助 Chat2Query 理解这些术语的含义和用法。 - **处理用户查询中的歧义时**：当你的查询包含容易引起混淆的概念时，使用 term-sheet explanation 可以帮助 Chat2Query 澄清这些歧义。 - **处理多义词时**：当你的查询包含在不同语境下有不同含义的术语时，使用 term-sheet explanation 可以帮助 Chat2Query 判断正确的解释。 ### Instruction -Instruction 是一段文本指令，用于引导或控制 Chat2Query 的行为，明确告知其在特定需求或条件下如何生成 SQL。 +Instruction 是一段文本指令，用于引导或控制 Chat2Query 的行为，明确指示其在特定需求或条件下如何生成 SQL。 > **Note:** > > - Instruction 的长度限制为 512 个字符。 -> - 请尽量提供清晰、具体的指令，以确保 Chat2Query 能够准确理解并执行。 +> - 请尽量提供清晰、具体的指令，以确保 Chat2Query 能够有效理解并执行指令。 #### 知识结构 @@ -152,18 +152,18 @@ Instruction 仅包含一段文本指令。 #### 适用场景 -Instruction 可用于多种场景，引导 Chat2Query 按你的需求输出结果，包括但不限于以下情况： +Instruction 可用于多种场景，引导 Chat2Query 按照你的需求输出结果，包括但不限于以下情况： -- **限定查询范围**：如果你希望 SQL 只考虑某些表或列，可以通过 instruction 进行指定。 -- **引导 SQL 结构**：如果你对 SQL 结构有特定要求，可以通过 instruction 指导 Chat2Query。 +- **限定查询范围**：如果你希望 SQL 只考虑某些表或列，可以通过指令进行限定。 +- **引导 SQL 结构**：如果你对 SQL 结构有特定要求，可以通过指令引导 Chat2Query。 -## 第 3 步：向新建的知识库添加知识 +## 步骤 3. 向新建的知识库添加知识 要添加新知识，可以调用 `/v3/knowledgeBases/{knowledge_base_id}/data` 接口。 -### 添加 few-shot example 类型的知识 +### 添加 Few-shot example 类型的知识 -例如，如果你希望 Chat2Query 以特定结构生成统计表中行数的 SQL 语句，可以通过如下方式调用 `/v3/knowledgeBases/{knowledge_base_id}/data` 添加 few-shot example 类型的知识： +例如，如果你希望 Chat2Query 以特定结构生成统计表中行数的 SQL 语句，可以通过如下方式调用 `/v3/knowledgeBases/{knowledge_base_id}/data` 添加 Few-shot example 类型的知识： ```bash curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v3/knowledgeBases//data'\ @@ -178,11 +178,11 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v3/knowledgeBases//data'\ @@ -197,11 +197,11 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v3/knowledgeBases//data'\ @@ -215,4 +215,4 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https:// **Note** > -> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 > **Tip** > -> 你可以在 Notebook 格式中查看完整的 [示例代码](https://github.com/aws-samples/aws-generativeai-partner-samples/blob/main/tidb/samples/tidb-bedrock-boto3-rag.ipynb)。 +> 你可以在 Notebook 格式下查看完整的 [示例代码](https://github.com/aws-samples/aws-generativeai-partner-samples/blob/main/tidb/samples/tidb-bedrock-boto3-rag.ipynb)。 ## 前置条件 @@ -31,15 +31,15 @@ summary: 学习如何将 TiDB 向量检索与 Amazon Bedrock 集成，构建基 - 已安装 [Pip](https://pypi.org/project/pip/) - 已安装 [AWS CLI](https://aws.amazon.com/cli/) - 请确保你的 AWS CLI 配置文件已设置为本教程支持的 [Amazon Bedrock](https://aws.amazon.com/bedrock/) 区域。支持的区域列表可参考 [Amazon Bedrock Regions](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html)。如需切换到支持的区域，可运行以下命令： + 请确保你的 AWS CLI 配置文件已设置为本教程支持的 [Amazon Bedrock](https://aws.amazon.com/bedrock/) 区域。支持区域列表可参考 [Amazon Bedrock Regions](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html)。如需切换到支持的区域，可运行以下命令： ```shell aws configure set region ``` -- 一个 TiDB Cloud Serverless 集群 +- 一个 TiDB Cloud Starter 集群 - 如果你还没有 TiDB Cloud 集群，请参考[创建 TiDB Cloud Serverless 集群](/tidb-cloud/create-tidb-cluster-serverless.md) 创建属于你自己的集群。 + 如果你还没有 TiDB Cloud 集群，请参考 [创建 TiDB Cloud Starter 集群](/tidb-cloud/create-tidb-cluster-serverless.md) 创建属于你自己的 TiDB Cloud 集群。 - 一个具有 [Amazon Bedrock 所需权限](https://docs.aws.amazon.com/bedrock/latest/userguide/security_iam_id-based-policy-examples.html) 的 AWS 账号，并且能够访问以下模型： @@ -54,9 +54,9 @@ summary: 学习如何将 TiDB 向量检索与 Amazon Bedrock 集成，构建基 ### 步骤 1. 设置环境变量 -从 [TiDB Cloud 控制台](https://tidbcloud.com/) 获取 TiDB 连接信息，并在你的开发环境中设置环境变量，具体如下： +从 [TiDB Cloud 控制台](https://tidbcloud.com/) 获取 TiDB 连接信息，并在你的开发环境中设置环境变量，操作如下： -1. 进入 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群名称，进入集群概览页。 +1. 进入 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群名称，进入集群概览页面。 2. 点击右上角的 **Connect**，弹出连接对话框。 @@ -77,7 +77,7 @@ summary: 学习如何将 TiDB 向量检索与 Amazon Bedrock 集成，构建基 > > 如果你之前已经创建过密码，可以继续使用原密码，或点击 **Reset Password** 生成新密码。 -5. 在终端中运行以下命令设置环境变量。你需要将命令中的占位符替换为连接对话框中获取的实际参数。 +5. 在终端中运行以下命令设置环境变量。你需要将命令中的占位符替换为连接对话框中获取的对应参数。 ```shell export TIDB_HOST= @@ -110,7 +110,7 @@ summary: 学习如何将 TiDB 向量检索与 Amazon Bedrock 集成，构建基 ### 步骤 3. 导入所需库 -在 `demo.py` 文件开头添加以下代码，导入所需的库： +在 `demo.py` 文件开头添加以下代码以导入所需库： ```python import os @@ -123,7 +123,7 @@ from tidb_vector.sqlalchemy import VectorType ### 步骤 4. 配置数据库连接 -在 `demo.py` 中添加以下代码，配置数据库连接： +在 `demo.py` 中添加以下代码以配置数据库连接： ```python # ---- Configuration Setup ---- @@ -144,16 +144,16 @@ engine = create_engine(get_db_url(), pool_recycle=300) Base = declarative_base() ``` -### 步骤 5. 使用 Bedrock runtime client 调用 Amazon Titan Text Embeddings V2 模型 +### 步骤 5. 通过 Bedrock runtime client 调用 Amazon Titan Text Embeddings V2 模型 -Amazon Bedrock runtime client 提供了 `invoke_model` API，支持以下参数： +Amazon Bedrock runtime client 提供了 `invoke_model` API，接受以下参数： - `modelId`：Amazon Bedrock 可用基础模型的模型 ID - `accept`：输入请求的类型 - `contentType`：输入内容的类型 - `body`：包含 prompt 和配置的 JSON 字符串负载 -在 `demo.py` 中添加以下代码，调用 `invoke_model` API，使用 Amazon Titan Text Embeddings 生成文本向量，并从 Meta Llama 3 获取响应： +在 `demo.py` 中添加以下代码，通过 `invoke_model` API 使用 Amazon Titan Text Embeddings 生成文本向量，并通过 Meta Llama 3 获取响应： ```python # Bedrock Runtime Client Setup @@ -227,7 +227,7 @@ def generate_result(query: str, info_str: str): ### 步骤 6. 创建向量表 -在 `demo.py` 中添加以下代码，创建用于存储文本及其向量的表： +在 `demo.py` 中添加以下代码，创建用于存储文本及其向量的向量表： ```python # ---- TiDB Setup and Vector Index Creation ---- @@ -242,14 +242,14 @@ class Entity(Base): Base.metadata.create_all(engine) ``` -### 步骤 7. 将向量数据保存到 TiDB Cloud Serverless +### 步骤 7. 将向量数据保存到 TiDB Cloud Starter -在 `demo.py` 中添加以下代码，将向量数据保存到你的 TiDB Cloud Serverless 集群： +在 `demo.py` 中添加以下代码，将向量数据保存到你的 TiDB Cloud Starter 集群： ```python # ---- Saving Vectors to TiDB ---- def save_entities_with_embedding(session, contents): - """Save multiple entities with their embeddings to the TiDB Serverless database.""" + """Save multiple entities with their embeddings to the TiDB database.""" for content in contents: entity = Entity(content=content, content_vec=embedding(content)) session.add(entity) @@ -258,7 +258,7 @@ def save_entities_with_embedding(session, contents): ### 步骤 8. 运行应用 -1. 在 `demo.py` 中添加以下代码，建立数据库会话，将向量保存到 TiDB，提出示例问题（如 "What is TiDB?"），并从模型生成结果： +1. 在 `demo.py` 中添加以下代码，建立数据库会话，将向量保存到 TiDB，提出示例问题（如 "What is TiDB?"），并通过模型生成结果： ```python if __name__ == "__main__": @@ -318,4 +318,4 @@ def save_entities_with_embedding(session, contents): ## 参见 - [向量数据类型](/vector-search/vector-search-data-types.md) -- [向量检索索引](/vector-search/vector-search-index.md) +- [向量检索索引](/vector-search/vector-search-index.md) \ No newline at end of file diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md index 099f086a5a7c4..55e8f9db9805a 100644 --- a/tidb-distributed-execution-framework.md +++ b/tidb-distributed-execution-framework.md @@ -7,24 +7,24 @@ summary: 了解 TiDB 分布式执行框架（DXF）的使用场景、限制、 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 集群上不可用。 +> 该功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 -TiDB 采用计算存储分离架构，具有出色的可扩展性和弹性。从 v7.1.0 版本开始，TiDB 引入了 **Distributed eXecution Framework (DXF)**，以进一步发挥分布式架构的资源优势。DXF 的目标是实现任务的统一调度和分布式执行，并为整体和单个任务提供统一的资源管理能力，更好地满足用户对资源使用的预期。 +TiDB 采用计算与存储分离的架构，具备出色的可扩展性和弹性。从 v7.1.0 开始，TiDB 引入了 **分布式执行框架（DXF）**，以进一步发挥分布式架构的资源优势。DXF 的目标是实现任务的统一调度与分布式执行，并为整体和单个任务提供统一的资源管理能力，更好地满足用户对资源使用的预期。 -本文档描述了 DXF 的使用场景、限制、用法和实现原理。 +本文档介绍了 DXF 的使用场景、限制、用法和实现原理。 ## 使用场景 -在数据库管理系统中，除了核心的事务处理（TP）和分析处理（AP）工作负载外，还有其他重要任务，例如 DDL 操作、[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)、[TTL](/time-to-live.md)、[`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 和备份/恢复。这些任务需要处理数据库对象（表）中的大量数据，因此通常具有以下特征： +在数据库管理系统中，除了核心的事务处理（TP）和分析处理（AP）负载外，还有其他重要任务，例如 DDL 操作、[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)、[TTL](/time-to-live.md)、[`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 以及备份/恢复。这些任务需要处理数据库对象（表）中的大量数据，因此通常具有以下特点： -- 需要处理某个 schema 或数据库对象（表）中的所有数据。 -- 可能需要定期执行，但频率较低。 +- 需要处理某个 schema 或数据库对象（表）中的全部数据。 +- 可能需要周期性执行，但频率较低。 - 如果资源控制不当，容易影响 TP 和 AP 任务，降低数据库服务质量。 -启用 DXF 可以解决上述问题，具有以下三大优势： +启用 DXF 可以解决上述问题，并具备以下三大优势： -- 框架提供高扩展性、高可用性和高性能的统一能力。 -- DXF 支持任务的分布式执行，能够灵活调度整个 TiDB 集群的可用计算资源，从而更好地利用 TiDB 集群中的计算资源。 +- 框架提供统一的高扩展性、高可用性和高性能能力。 +- DXF 支持任务的分布式执行，可以灵活调度整个 TiDB 集群的可用计算资源，从而更好地利用 TiDB 集群中的计算资源。 - DXF 为整体和单个任务提供统一的资源使用和管理能力。 目前，DXF 支持 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) 和 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 语句的分布式执行。 @@ -36,30 +36,30 @@ TiDB 采用计算存储分离架构，具有出色的可扩展性和弹性。从 CREATE INDEX idx1 ON table t1(c1); ``` -- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 用于将 CSV、SQL、Parquet 等格式的数据导入空表。 +- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 用于将 CSV、SQL、Parquet 等格式的数据导入到空表中。 ## 限制 -DXF 只能同时调度最多 16 个任务（包括 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) 任务和 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 任务）。 +DXF 最多只能同时调度 16 个任务（包括 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) 任务和 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 任务）。 -## 前提条件 +## 前置条件 -在使用 DXF 执行 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) 任务之前，需要启用 [Fast Online DDL](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) 模式。 +在使用 DXF 执行 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) 任务前，你需要开启 [Fast Online DDL](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) 模式。 1. 调整以下与 Fast Online DDL 相关的系统变量： - * [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)：用于启用 Fast Online DDL 模式。从 TiDB v6.5.0 开始默认启用。 - * [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630)：用于控制在 Fast Online DDL 模式下可使用的本地磁盘最大配额。 + * [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)：用于开启 Fast Online DDL 模式。从 TiDB v6.5.0 起默认开启。 + * [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630)：用于控制 Fast Online DDL 模式下可使用的本地磁盘最大配额。 2. 调整以下与 Fast Online DDL 相关的配置项： - * [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630)：指定在 Fast Online DDL 模式下可用的本地磁盘路径。 + * [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630)：指定 Fast Online DDL 模式下可使用的本地磁盘路径。 > **Note:** > -> 建议你为 TiDB 的 `temp-dir` 目录准备至少 100 GiB 的空闲空间。 +> 建议你为 TiDB 的 `temp-dir` 目录预留至少 100 GiB 的可用空间。 @@ -67,65 +67,65 @@ DXF 只能同时调度最多 16 个任务（包括 [`ADD INDEX`](/sql-statements 调整以下与 Fast Online DDL 相关的系统变量： -* [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)：用于启用 Fast Online DDL 模式。从 TiDB v6.5.0 开始默认启用。 -* [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630)：用于控制在 Fast Online DDL 模式下可使用的本地磁盘最大配额。 +* [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)：用于开启 Fast Online DDL 模式。从 TiDB v6.5.0 起默认开启。 +* [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630)：用于控制 Fast Online DDL 模式下可使用的本地磁盘最大配额。 -## 用法 +## 使用方法 -1. 要启用 DXF，将 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 的值设置为 `ON`。从 v8.1.0 版本开始，该变量默认启用。对于新创建的 v8.1.0 或更高版本的集群，可以跳过此步骤。 +1. 要启用 DXF，请将 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 的值设置为 `ON`。从 v8.1.0 起，该变量默认开启。对于 v8.1.0 及以上版本新建的集群，可以跳过此步骤。 ```sql SET GLOBAL tidb_enable_dist_task = ON; ``` - 当 DXF 任务运行时，框架支持的语句（如 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) 和 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)）会以分布式方式执行。所有 TiDB 节点默认运行 DXF 任务。 + 当 DXF 任务运行时，框架支持的语句（如 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) 和 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)）将以分布式方式执行。所有 TiDB 节点默认都会运行 DXF 任务。 -2. 一般情况下，建议你使用以下系统变量的默认值，这些变量可能影响 DDL 任务的分布式执行： +2. 通常，对于以下可能影响 DDL 任务分布式执行的系统变量，建议你使用默认值： - * [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt)：使用默认值 `4`。建议最大值为 `16`。 + * [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt)：使用默认值 `4`，推荐最大值为 `16`。 * [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority) * [`tidb_ddl_error_count_limit`](/system-variables.md#tidb_ddl_error_count_limit) - * [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size)：使用默认值。建议最大值为 `1024`。 + * [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size)：使用默认值，推荐最大值为 `1024`。 ## 任务调度 -默认情况下，DXF 调度所有 TiDB 节点执行分布式任务。从 v7.4.0 版本开始，对于 TiDB 自管理集群，你可以通过配置 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 来控制哪些 TiDB 节点可以被 DXF 调度执行分布式任务。 +默认情况下，DXF 会调度所有 TiDB 节点执行分布式任务。从 v7.4.0 起，对于 TiDB 自建集群，你可以通过配置 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 控制哪些 TiDB 节点可以被 DXF 调度执行分布式任务。 -- 从 v7.4.0 到 v8.0.0 版本，`tidb_service_scope` 的可选值为 `''` 或 `background`。如果当前集群中存在 `tidb_service_scope = 'background'` 的 TiDB 节点，DXF 会调度任务到这些节点执行。如果没有（由于故障或正常扩容），DXF 会调度任务到 `tidb_service_scope = ''` 的节点。 +- 在 v7.4.0 到 v8.0.0 版本中，[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 的可选值为 `''` 或 `background`。如果当前集群中存在 `tidb_service_scope = 'background'` 的 TiDB 节点，DXF 会将任务调度到这些节点执行。如果当前集群没有 `tidb_service_scope = 'background'` 的 TiDB 节点（无论是由于故障还是正常缩容），DXF 会将任务调度到 `tidb_service_scope = ''` 的节点执行。 -- 从 v8.1.0 开始，你可以将 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 设置为任何有效值。当提交分布式任务时，任务会绑定到当前连接的 TiDB 节点的 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 值，DXF 只会调度任务到具有相同 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 值的 TiDB 节点执行。但是，为了与早期版本的配置兼容，如果在 `tidb_service_scope = ''` 的节点上提交分布式任务，而当前集群中存在 `tidb_service_scope = 'background'` 的 TiDB 节点，DXF 会调度任务到 `tidb_service_scope = 'background'` 的节点执行。 +- 从 v8.1.0 起，你可以将 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 设置为任意有效值。当分布式任务提交时，任务会绑定到当前连接 TiDB 节点的 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 值，DXF 只会将任务调度到具有相同 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 值的 TiDB 节点执行。但为了兼容早期版本的配置，如果在 `tidb_service_scope = ''` 的节点上提交分布式任务，且当前集群存在 `tidb_service_scope = 'background'` 的 TiDB 节点，DXF 会将任务调度到 `tidb_service_scope = 'background'` 的 TiDB 节点执行。 -从 v8.1.0 开始，如果在任务执行过程中新增节点，DXF 会根据之前的规则判断是否调度任务到新节点。如果你不希望新加入的节点执行任务，建议提前为这些新加入的节点设置不同的 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)。 +从 v8.1.0 起，如果在任务执行期间新增节点，DXF 会根据上述规则判断是否将任务调度到新节点执行。如果你不希望新增节点参与任务执行，建议提前为这些新节点设置不同的 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)。 > **Note:** > -> - 从 v7.4.0 到 v8.0.0 版本，在拥有多个 TiDB 节点的集群中，强烈建议在两个或更多 TiDB 节点上将 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 设置为 `background`。如果只在单个节点上设置该变量，当该节点重启或故障时，任务会被重新调度到 `tidb_service_scope = ''` 的节点，影响在这些节点上运行的应用。 -> - 在分布式任务执行期间，修改 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 配置不会影响当前任务，但会在下一个任务中生效。 +> - 在 v7.4.0 到 v8.0.0 版本中，对于多 TiDB 节点的集群，强烈建议在两个及以上 TiDB 节点上将 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 设置为 `background`。如果只在单个 TiDB 节点上设置该变量，当该节点重启或故障时，任务会被重新调度到 `tidb_service_scope = ''` 的 TiDB 节点，进而影响这些节点上运行的应用。 +> - 分布式任务执行期间，[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 配置的变更不会影响当前任务，但会在下一个任务生效。 ## 实现原理 -DXF 的架构如下： +DXF 的架构如下所示： ![Architecture of the DXF](/media/dist-task/dist-task-architect.jpg) 如上图所示，DXF 中任务的执行主要由以下模块负责： -- Dispatcher：生成每个任务的分布式执行计划，管理执行过程，转换任务状态，收集并反馈运行时任务信息。 -- Scheduler：在 TiDB 节点之间复制分布式任务的执行，以提高任务执行效率。 -- Subtask Executor：分布式子任务的实际执行者。此外，子任务执行器会返回子任务的执行状态，调度器统一更新子任务的执行状态。 -- Resource pool：通过池化上述模块的计算资源，为资源使用和管理提供基础。 +- Dispatcher：为每个任务生成分布式执行计划，管理执行流程，转换任务状态，并收集和反馈运行时任务信息。 +- Scheduler：在 TiDB 节点间复制分布式任务的执行，以提升任务执行效率。 +- Subtask Executor：分布式子任务的实际执行者。此外，Subtask Executor 会将子任务的执行状态返回给 Scheduler，由 Scheduler 统一更新子任务的执行状态。 +- 资源池：通过对上述模块的计算资源进行池化，为资源使用量化和管理提供基础。 -## 相关链接 +## 参考 -* [Execution Principles and Best Practices of DDL Statements](/ddl-introduction.md) +* [DDL 语句的执行原理与最佳实践](/ddl-introduction.md) -* [Execution Principles and Best Practices of DDL Statements](https://docs.pingcap.com/tidb/stable/ddl-introduction) +* [DDL 语句的执行原理与最佳实践](https://docs.pingcap.com/tidb/stable/ddl-introduction) \ No newline at end of file diff --git a/tidb-global-sort.md b/tidb-global-sort.md index 2a72e7ccc2b64..06c412bd1cf02 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -1,43 +1,43 @@ --- -title: TiDB Global Sort -summary: 了解 TiDB Global Sort 的使用场景、限制、用法和实现原理。 +title: TiDB 全局排序 +summary: 了解 TiDB 全局排序的使用场景、限制、用法和实现原理。 --- -# TiDB Global Sort +# TiDB 全局排序 > **Note:** > -> - 目前，Global Sort 过程会消耗 TiDB 节点大量的计算和内存资源。在如在用户业务应用运行时在线添加索引等场景中，建议向集群中添加新的 TiDB 节点，配置这些节点的 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 变量，并连接到这些节点以创建任务。这样，分布式框架会调度任务到这些节点，隔离工作负载，减少执行后台任务（如 `ADD INDEX` 和 `IMPORT INTO`）对用户业务应用的影响。 -> - 使用 Global Sort 功能时，建议使用 CPU 至少为 16 核、内存为 32 GiB 的 TiDB 节点，以避免 OOM。 +> - 目前，全局排序过程会消耗 TiDB 节点大量的计算和内存资源。在用户业务应用运行期间进行在线添加索引等场景下，建议为集群新增 TiDB 节点，为这些节点配置 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) 变量，并连接到这些节点创建任务。这样，分布式框架会将任务调度到这些节点，从而将工作负载与其他 TiDB 节点隔离，减少执行 `ADD INDEX`、`IMPORT INTO` 等后台任务对用户业务应用的影响。 +> - 使用全局排序功能时，建议使用至少 16 核 CPU 和 32 GiB 内存的 TiDB 节点，以避免 OOM。 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 集群上不可用。 +> 该功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 ## 概述 -TiDB Global Sort 功能增强了数据导入和 DDL（数据定义语言）操作的稳定性和效率。它作为 [TiDB 分布式执行框架（DXF）](/tidb-distributed-execution-framework.md) 的通用操作符，为云端提供全局排序服务。 +TiDB 全局排序功能提升了数据导入和 DDL（数据定义语言）操作的稳定性和效率。它作为 [TiDB 分布式执行框架（DXF）](/tidb-distributed-execution-framework.md) 的通用算子，在云端提供全局排序服务。 -目前，Global Sort 功能支持使用 Amazon S3 作为云存储。 +目前，全局排序功能支持使用 Amazon S3 作为云存储。 ## 使用场景 -Global Sort 功能提升了 `IMPORT INTO` 和 `CREATE INDEX` 的稳定性和效率。通过对任务处理的数据进行全局排序，改善了写入 TiKV 的稳定性、可控性和可扩展性。这为数据导入和 DDL 任务提供了更优的用户体验和更高质量的服务。 +全局排序功能提升了 `IMPORT INTO` 和 `CREATE INDEX` 的稳定性和效率。通过对任务处理的数据进行全局排序，提升了向 TiKV 写入数据的稳定性、可控性和可扩展性，为数据导入和 DDL 任务带来更好的用户体验和更高质量的服务。 -Global Sort 功能在统一的 DXF 中执行任务，确保数据在全局范围内高效、并行地排序。 +全局排序功能在统一的 DXF 框架下执行任务，确保数据在全局范围内高效并行排序。 ## 限制 -目前，Global Sort 功能尚未作为排序查询结果的查询执行过程中的组件使用。 +目前，全局排序功能不会作为查询执行流程中负责排序查询结果的组件使用。 -## 用法 +## 使用方法 -启用 Global Sort，请按照以下步骤操作： +要启用全局排序，请按照以下步骤操作： -1. 通过将 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 设置为 `ON` 来启用 DXF。从 v8.1.0 开始，该变量默认启用。对于新创建的 v8.1.0 或更高版本的集群，可以跳过此步骤。 +1. 通过设置 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) 为 `ON` 启用 DXF。从 v8.1.0 开始，该变量默认开启。对于 v8.1.0 或更高版本新建的集群，可以跳过此步骤。 ```sql SET GLOBAL tidb_enable_dist_task = ON; @@ -45,7 +45,7 @@ Global Sort 功能在统一的 DXF 中执行任务，确保数据在全局范围 -2. 将 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 设置为正确的云存储路径。参见 [示例](/br/backup-and-restore-storages.md)。 +2. 设置 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 为正确的云存储路径。参见[示例](/br/backup-and-restore-storages.md)。 ```sql SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' @@ -54,7 +54,7 @@ Global Sort 功能在统一的 DXF 中执行任务，确保数据在全局范围 -2. 将 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 设置为正确的云存储路径。参见 [示例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)。 +2. 设置 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 为正确的云存储路径。参见[示例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)。 ```sql SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' @@ -64,29 +64,29 @@ Global Sort 功能在统一的 DXF 中执行任务，确保数据在全局范围 > **Note:** > -> 对于 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)，你也可以使用 [`CLOUD_STORAGE_URI`](/sql-statements/sql-statement-import-into.md#withoptions) 选项指定云存储路径。如果同时配置了 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 和 `CLOUD_STORAGE_URI`，且两者都指向有效的云存储路径，则以 `CLOUD_STORAGE_URI` 的配置为准。 +> 对于 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)，你也可以通过 [`CLOUD_STORAGE_URI`](/sql-statements/sql-statement-import-into.md#withoptions) 选项指定云存储路径。如果 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) 和 `CLOUD_STORAGE_URI` 都配置了有效的云存储路径，则 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 以 `CLOUD_STORAGE_URI` 的配置为准。 ## 实现原理 -Global Sort 功能的算法如下： +全局排序功能的算法如下： ![Algorithm of Global Sort](/media/dist-task/global-sort.jpeg) 详细的实现原理如下： -### Step 1: 扫描和准备数据 +### 第 1 步：扫描并准备数据 -1. 在 TiDB 节点扫描特定范围的数据后（数据源可以是 CSV 数据或 TiKV 中的表数据）： +1. TiDB 节点扫描特定范围的数据（数据源可以是 CSV 数据，也可以是 TiKV 中的表数据）后： 1. TiDB 节点将其编码为 Key-Value 对。 - 2. TiDB 节点将 Key-Value 对排序成多个块数据段（数据段在本地排序），每个段为一个文件，并上传到云存储。 + 2. TiDB 节点将 Key-Value 对排序为若干块数据段（每个数据段在本地已排序），每个数据段为一个文件，并上传到云存储。 -2. 同时，TiDB 节点还会为每个段记录一个连续的实际 Key-Value 范围（称为统计文件），这是实现可扩展排序的关键准备。这些文件会与实际数据一同上传到云存储。 +2. TiDB 节点还会为每个数据段记录一组实际的 Key-Value 范围（称为统计文件），这是实现可扩展排序的关键准备。这些文件会与真实数据一起上传到云存储。 -### Step 2: 排序和分发数据 +### 第 2 步：排序并分发数据 -从步骤 1，Global Sort 程序获得已排序块列表及其对应的统计文件，这些文件提供了本地排序块的数量。程序还拥有一个实际数据范围，可供 PD 用于拆分和分散。接下来执行： +在第 1 步中，全局排序程序获得了已排序的数据块列表及其对应的统计文件，这些文件提供了本地已排序块的数量。程序还拥有可供 PD 拆分和分散的真实数据范围。具体步骤如下： -1. 将统计文件中的记录排序，划分为几乎相等的范围，这些范围作为子任务，将在并行中执行。 -2. 将子任务分发到 TiDB 节点进行执行。 -3. 每个 TiDB 节点独立地将子任务中的数据排序到范围内，并无重叠地导入到 TiKV。 \ No newline at end of file +1. 对统计文件中的记录进行排序，将其划分为近似等大小的范围，这些范围即为将要并行执行的子任务。 +2. 将子任务分发到 TiDB 节点执行。 +3. 每个 TiDB 节点独立地将子任务的数据排序为范围，并无重叠地导入到 TiKV。 \ No newline at end of file diff --git a/tidb-resource-control-background-tasks.md b/tidb-resource-control-background-tasks.md index 8abaeb404b2ce..a559f329bc4bf 100644 --- a/tidb-resource-control-background-tasks.md +++ b/tidb-resource-control-background-tasks.md @@ -7,66 +7,66 @@ summary: 介绍如何通过资源控制管理后台任务。 > **Warning:** > -> 该功能为实验性功能。不建议在生产环境中使用。此功能可能在未提前通知的情况下被更改或移除。如果你发现 bug，可以在 GitHub 上提交 [issue](https://docs.pingcap.com/tidb/stable/support)。 +> 此功能为实验性功能。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下更改或移除。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://docs.pingcap.com/tidb/stable/support) 进行反馈。 > -> 资源控制中的后台任务管理基于 TiKV 对 CPU/IO 利用率的动态资源配额调整。因此，它依赖于每个实例的可用资源配额。如果在一台服务器上部署多个组件或实例，必须通过 `cgroup` 为每个实例设置合适的资源配额。在使用 TiUP Playground 等共享资源的部署环境中，难以达到预期效果。 +> 资源控制中的后台任务管理基于 TiKV 对 CPU/IO 利用率资源配额的动态调整。因此，它依赖于每个实例的可用资源配额。如果在单台服务器上部署了多个组件或实例，必须通过 `cgroup` 为每个实例设置合适的资源配额。在如 TiUP Playground 这类资源共享的部署环境下，难以达到预期效果。 > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 集群上不可用。 +> 该功能在 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群中不可用。 -后台任务，例如数据备份和自动统计信息收集，优先级较低但会消耗大量资源。这些任务通常周期性或不定期触发。在执行过程中，它们会占用大量资源，从而影响线上高优先级任务的性能。 +后台任务（如数据备份和自动统计信息收集）优先级较低，但会消耗大量资源。这些任务通常会定期或不定期触发。在执行过程中会占用大量资源，从而影响在线高优先级任务的性能。 -从 v7.4.0 版本开始，[TiDB 资源控制](/tidb-resource-control-ru-groups.md) 功能支持管理后台任务。当某个任务被标记为后台任务时，TiKV 会动态限制此类任务的资源使用，以避免影响其他前台任务的性能。TiKV 会实时监控所有前台任务的 CPU 和 IO 资源消耗，并根据实例的总资源限制计算后台任务可用的资源阈值。在任务执行期间，所有后台任务都受到此阈值的限制。 +从 v7.4.0 开始，[TiDB 资源控制](/tidb-resource-control-ru-groups.md) 功能支持后台任务管理。当任务被标记为后台任务时，TiKV 会动态限制此类任务使用的资源，以避免影响其他前台任务的性能。TiKV 实时监控所有前台任务消耗的 CPU 和 IO 资源，并根据实例的总资源限制计算后台任务可用的资源阈值。所有后台任务在执行时都受该阈值限制。 ## `BACKGROUND` 参数 -- `TASK_TYPES`：指定需要作为后台任务管理的任务类型。多个任务类型之间用逗号（`,`）分隔。 -- `UTILIZATION_LIMIT`：限制后台任务在每个 TiKV 节点上最多可占用的资源百分比（0-100）。默认情况下，TiKV 会根据节点的总资源和当前被前台任务占用的资源，自动计算后台任务的可用资源。如果配置了 `UTILIZATION_LIMIT`，后台任务所分配的资源不会超过此限制。 +- `TASK_TYPES`：指定需要作为后台任务管理的任务类型。多个任务类型使用逗号（`,`）分隔。 +- `UTILIZATION_LIMIT`：限制后台任务在每个 TiKV 节点上可消耗的最大资源百分比（0-100）。默认情况下，TiKV 会根据节点的总资源和当前前台任务占用的资源计算后台任务可用的资源。如果配置了 `UTILIZATION_LIMIT`，分配给后台任务的资源不会超过该限制。 TiDB 支持以下类型的后台任务： -- `lightning`：使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 进行导入任务。支持 TiDB Lightning 的物理和逻辑导入模式。 -- `br`：使用 [BR](/br/backup-and-restore-overview.md) 进行备份和恢复任务。不支持 PITR。 -- `ddl`：控制 Reorg DDL 执行过程中批量数据写回阶段的资源使用。 +- `lightning`：使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 执行导入任务。支持 TiDB Lightning 的物理和逻辑导入模式。 +- `br`：使用 [BR](/br/backup-and-restore-overview.md) 执行备份和恢复任务。不支持 PITR。 +- `ddl`：控制 Reorg DDL 批量数据回写阶段的资源使用。 - `stats`：由 TiDB 手动执行或自动触发的 [收集统计信息](/statistics.md#collect-statistics) 任务。 -- `background`：保留任务类型。你可以使用 [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740) 系统变量，将当前会话的任务类型指定为 `background`。 +- `background`：保留任务类型。你可以使用 [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740) 系统变量将当前会话的任务类型指定为 `background`。 -- `lightning`：使用 [TiDB Lightning](https://docs.pingcap.com/tidb/stable/tidb-lightning-overview) 进行导入任务。支持 TiDB Lightning 的物理和逻辑导入模式。 -- `br`：使用 [BR](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview) 进行备份和恢复任务。不支持 PITR。 -- `ddl`：控制 Reorg DDL 执行过程中批量数据写回阶段的资源使用。 +- `lightning`：使用 [TiDB Lightning](https://docs.pingcap.com/tidb/stable/tidb-lightning-overview) 执行导入任务。支持 TiDB Lightning 的物理和逻辑导入模式。 +- `br`：使用 [BR](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview) 执行备份和恢复任务。不支持 PITR。 +- `ddl`：控制 Reorg DDL 批量数据回写阶段的资源使用。 - `stats`：由 TiDB 手动执行或自动触发的 [收集统计信息](/statistics.md#collect-statistics) 任务。 -- `background`：保留任务类型。你可以使用 [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740) 系统变量，将当前会话的任务类型指定为 `background`。 +- `background`：保留任务类型。你可以使用 [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740) 系统变量将当前会话的任务类型指定为 `background`。 -默认情况下，标记为后台任务的任务类型为 `""`，后台任务管理功能处于禁用状态。要启用后台任务管理，你需要手动修改 `default` 资源组的后台任务类型。当后台任务被识别并匹配后，资源控制会自动进行管理。这意味着当系统资源不足时，后台任务会自动降到最低优先级，以确保前台任务的正常执行。 +默认情况下，被标记为后台任务的任务类型为 `""`，后台任务管理功能处于关闭状态。要启用后台任务管理，你需要手动修改 `default` 资源组的后台任务类型。当后台任务被识别并匹配后，资源控制会自动生效。这意味着当系统资源不足时，后台任务会自动降为最低优先级，以保障前台任务的执行。 > **Note:** > -> 目前，所有资源组的后台任务都绑定到 `default` 资源组。你可以通过 `default` 全局管理后台任务类型，目前不支持将后台任务绑定到其他资源组。 +> 目前，所有资源组的后台任务都绑定在 `default` 资源组。你可以通过 `default` 全局管理后台任务类型。暂不支持将后台任务绑定到其他资源组。 ## 示例 -1. 修改 `default` 资源组，将 `br` 和 `ddl` 标记为后台任务，并将后台任务的资源限制设置为 30%。 +1. 修改 `default` 资源组，将 `br` 和 `ddl` 标记为后台任务，并设置后台任务的资源限制为 30%。 ```sql ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='br,ddl', UTILIZATION_LIMIT=30); ``` -2. 将 `default` 资源组改回，恢复后台任务类型为默认值。 +2. 修改 `default` 资源组，将后台任务类型恢复为默认值。 ```sql ALTER RESOURCE GROUP `default` BACKGROUND=NULL; ``` -3. 将 `default` 资源组改为将后台任务类型设置为空。在这种情况下，该资源组的所有任务都不作为后台任务处理。 +3. 修改 `default` 资源组，将后台任务类型设置为空。此时该资源组的所有任务都不会被视为后台任务。 ```sql ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES=""); @@ -88,9 +88,9 @@ TiDB 支持以下类型的后台任务： +---------+------------+----------+-----------+-------------+-------------------------------------------+ ``` -5. 若要在当前会话中明确将任务标记为后台类型，可以使用 `tidb_request_source_type` 显式指定任务类型。示例如下： +5. 如果你希望在当前会话中显式将任务标记为后台类型，可以使用 `tidb_request_source_type` 显式指定任务类型。示例如下： - ```sql + ``` sql SET @@tidb_request_source_type="background"; /* 添加后台任务类型 */ ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES="background"); diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index f6e68466599bc..ef995e5ff1090 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -1,6 +1,6 @@ --- title: 使用资源控制实现资源组限制与流量控制 -summary: 学习如何使用资源控制功能对应用资源进行控制和调度。 +summary: 了解如何使用资源控制功能对应用资源进行控制和调度。 aliases: ['/tidb/v8.5/tidb-resource-control/','/tidb/stable/tidb-resource-control/'] --- @@ -8,139 +8,139 @@ aliases: ['/tidb/v8.5/tidb-resource-control/','/tidb/stable/tidb-resource-contro > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 集群上不可用。 +> 此功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 -作为集群管理员，你可以使用资源控制功能创建资源组，设置资源组配额，并绑定用户到这些资源组。 +作为集群管理员，你可以使用资源控制功能创建资源组、为资源组设置配额，并将用户绑定到这些资源组。 -TiDB 的资源控制功能提供了两层资源管理能力：TiDB 层的流量控制能力和 TiKV 层的优先级调度能力。这两种能力可以单独启用或同时启用。详细信息请参见 [Parameters for resource control](#parameters-for-resource-control)。这样，TiDB 层可以根据为资源组设置的配额控制用户读写请求的流量，而 TiKV 层可以根据映射到读写配额的优先级调度请求。通过这种方式，你可以确保应用的资源隔离，并满足服务质量（QoS）要求。 +TiDB 资源控制功能提供了两层资源管理能力：TiDB 层的流量控制能力和 TiKV 层的优先级调度能力。这两种能力可以单独启用，也可以同时启用。详情请参见 [资源控制参数](#parameters-for-resource-control)。这样，TiDB 层可以根据资源组设置的配额控制用户读写请求的流量，TiKV 层则可以根据映射到读写配额的优先级调度请求。通过这种方式，你可以实现应用的资源隔离，满足服务质量（QoS）要求。 -- TiDB 流量控制：TiDB 流量控制采用 [token bucket 算法](https://en.wikipedia.org/wiki/Token_bucket)。如果桶中的令牌不足，且资源组未指定 `BURSTABLE` 选项，请求将等待令牌桶补充令牌后重试。重试可能因超时而失败。 +- TiDB 流量控制：TiDB 流量控制采用 [令牌桶算法](https://en.wikipedia.org/wiki/Token_bucket)。如果桶中令牌不足，且资源组未指定 `BURSTABLE` 选项，则对该资源组的请求会等待令牌桶回填令牌后重试。重试可能因超时而失败。 -- TiKV 调度：你可以根据需要设置绝对优先级 [`PRIORITY`](/information-schema/information-schema-resource-groups.md#examples)。不同的资源根据 `PRIORITY` 设置进行调度。`PRIORITY` 高的任务优先调度。如果未设置绝对优先级，TiKV 会根据每个资源组的 `RU_PER_SEC` 值来确定读写请求的优先级。存储层会根据优先级使用优先级队列调度和处理请求。 +- TiKV 调度：你可以根据需要设置绝对优先级 [(`PRIORITY`)](/information-schema/information-schema-resource-groups.md#examples)。不同资源根据 `PRIORITY` 设置进行调度。高 `PRIORITY` 的任务优先调度。如果未设置绝对优先级，TiKV 会根据每个资源组的 `RU_PER_SEC` 值来决定各资源组读写请求的优先级。存储层会根据优先级队列调度和处理请求。 -从 v7.4.0 版本开始，资源控制功能支持控制 TiFlash 资源。其原理类似于 TiDB 流量控制和 TiKV 调度： +自 v7.4.0 起，资源控制功能支持对 TiFlash 资源进行控制，其原理与 TiDB 流量控制和 TiKV 调度类似： -- TiFlash 流量控制：结合 [TiFlash pipeline 执行模型](/tiflash/tiflash-pipeline-model.md)，TiFlash 能更准确地获取不同查询的 CPU 消耗，并将其转换为用于扣减的 [Request Units (RU)](#what-is-request-unit-ru)。流量控制采用 token bucket 算法实现。 -- TiFlash 调度：当系统资源不足时，TiFlash 会根据优先级在多个资源组之间调度 pipeline 任务。具体逻辑为：首先评估资源组的 `PRIORITY`，然后考虑 CPU 使用情况和 `RU_PER_SEC`。例如，若 `rg1` 和 `rg2` 的 `PRIORITY` 相同，但 `rg2` 的 `RU_PER_SEC` 是 `rg1` 的两倍，则 `rg2` 的 CPU 使用率也会是 `rg1` 的两倍。 +- TiFlash 流量控制：借助 [TiFlash 流水线执行模型](/tiflash/tiflash-pipeline-model.md)，TiFlash 能更准确地获取不同查询的 CPU 消耗，并将其转换为 [请求单位（RU）](#what-is-request-unit-ru) 进行扣减。流量控制通过令牌桶算法实现。 +- TiFlash 调度：当系统资源不足时，TiFlash 会根据各资源组的优先级在多个资源组间调度流水线任务。具体逻辑为：首先评估资源组的 `PRIORITY`，然后考虑 CPU 使用量和 `RU_PER_SEC`。因此，如果 `rg1` 和 `rg2` 的 `PRIORITY` 相同，但 `rg2` 的 `RU_PER_SEC` 是 `rg1` 的两倍，则 `rg2` 的 CPU 使用量也是 `rg1` 的两倍。 -- TiFlash 流量控制：结合 [TiFlash pipeline 执行模型](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)，TiFlash 能更准确地获取不同查询的 CPU 消耗，并将其转换为用于扣减的 [Request Units (RU)](#what-is-request-unit-ru)。流量控制采用 token bucket 算法实现。 -- TiFlash 调度：当系统资源不足时，TiFlash 会根据优先级在多个资源组之间调度 pipeline 任务。具体逻辑为：首先评估资源组的 `PRIORITY`，然后考虑 CPU 使用情况和 `RU_PER_SEC`。例如，若 `rg1` 和 `rg2` 的 `PRIORITY` 相同，但 `rg2` 的 `RU_PER_SEC` 是 `rg1` 的两倍，则 `rg2` 的 CPU 使用率也会是 `rg1` 的两倍。 +- TiFlash 流量控制：借助 [TiFlash 流水线执行模型](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)，TiFlash 能更准确地获取不同查询的 CPU 消耗，并将其转换为 [请求单位（RU）](#what-is-request-unit-ru) 进行扣减。流量控制通过令牌桶算法实现。 +- TiFlash 调度：当系统资源不足时，TiFlash 会根据各资源组的优先级在多个资源组间调度流水线任务。具体逻辑为：首先评估资源组的 `PRIORITY`，然后考虑 CPU 使用量和 `RU_PER_SEC`。因此，如果 `rg1` 和 `rg2` 的 `PRIORITY` 相同，但 `rg2` 的 `RU_PER_SEC` 是 `rg1` 的两倍，则 `rg2` 的 CPU 使用量也是 `rg1` 的两倍。 -关于如何管理后台任务和处理资源密集型查询（Runaway Queries），请参阅以下文档： +关于如何管理后台任务和处理资源消耗较大的查询（Runaway Queries），请参见以下文档： - [使用资源控制管理后台任务](/tidb-resource-control-background-tasks.md) - [管理超出预期资源消耗的查询（Runaway Queries）](/tidb-resource-control-runaway-queries.md) -## 资源控制场景 +## 资源控制的应用场景 -引入资源控制功能是 TiDB 的一个里程碑。它可以将分布式数据库集群划分为多个逻辑单元。即使某个单元资源过度使用，也不会挤占其他单元所需的资源。 +资源控制功能的引入是 TiDB 的一个里程碑。它可以将分布式数据库集群划分为多个逻辑单元，即使某个单元资源消耗过多，也不会挤占其他单元所需的资源。 -有了这个功能，你可以： +通过该功能，你可以： -- 将来自不同系统的多个中小型应用合并到一个 TiDB 集群中。当某个应用的工作负载变大时，不会影响其他应用的正常运行。当系统负载较低时，即使超出配额，繁忙的应用仍能获得所需的系统资源，从而实现资源的最大利用。 -- 选择将所有测试环境合并到一个 TiDB 集群，或将消耗较多资源的批处理任务分组到一个资源组中。这可以提高硬件利用率，降低运营成本，同时确保关键应用始终获得必要的资源。 -- 当系统中存在混合负载时，可以将不同的负载放入不同的资源组。通过使用资源控制功能，可以确保事务型应用的响应时间不受数据分析或批处理应用的影响。 -- 当集群遇到意外的 SQL 性能问题时，可以结合 SQL 绑定和资源组，临时限制某个 SQL 语句的资源消耗。 +- 将来自不同系统的多个中小型应用合并到一个 TiDB 集群中。当某个应用的负载变大时，不会影响其他应用的正常运行。当系统负载较低时，即使某些应用超出设定配额，仍可分配所需系统资源，从而实现资源的最大化利用。 +- 可以选择将所有测试环境合并到一个 TiDB 集群，或将消耗资源较多的批量任务分组到一个资源组。这样既能提升硬件利用率，降低运维成本，又能保证关键应用始终获得必要资源。 +- 当系统存在混合负载时，可以将不同负载分别放入不同资源组。通过资源控制功能，可以确保事务型应用的响应时间不受数据分析或批量应用影响。 +- 当集群遇到突发 SQL 性能问题时，可以结合 SQL 绑定和资源组，临时限制某条 SQL 语句的资源消耗。 -此外，合理使用资源控制功能还可以减少集群数量，简化运维难度，降低管理成本。 +此外，合理使用资源控制功能可以减少集群数量，降低运维难度，节省管理成本。 > **Note:** > -> - 为评估资源管理的效果，建议在独立的计算和存储节点上部署集群。在通过 `tiup playground` 创建的部署中，调度和其他对集群资源敏感的功能难以正常工作，因为资源在实例间共享。 +> - 为了评估资源管理的效果，建议将集群部署在独立的计算和存储节点上。调度等对集群资源敏感的功能在 `tiup playground` 部署的环境下难以正常工作，因为该环境下资源在各实例间共享。 ## 限制 -资源控制会带来额外的调度开销。因此，启用该功能时，可能会出现轻微的性能下降（小于 5%）。 +资源控制会带来额外的调度开销。因此，启用该功能后，系统性能可能会有轻微下降（小于 5%）。 -## 什么是 Request Unit (RU) +## 什么是请求单位（RU） -Request Unit (RU) 是 TiDB 中对系统资源的统一抽象单位，目前包括 CPU、IOPS 和 IO 带宽指标。它用于表示对数据库的单个请求所消耗的资源量。请求消耗的 RU 数量取决于多种因素，例如操作类型、查询或修改的数据量。目前，RU 包含以下表格中的资源消耗统计： +请求单位（Request Unit，RU）是 TiDB 对系统资源的统一抽象单位，目前包括 CPU、IOPS 和 IO 带宽等指标。它用于表示单个数据库请求消耗的资源量。一个请求消耗的 RU 数量取决于多种因素，如操作类型、查询或修改的数据量等。目前，RU 包含下表中的资源消耗统计： - - + + - - + + - + - + - - + + - + - + - +
Resource typeRU consumption资源类型RU 消耗
Read2 storage read batches consume 1 RU读2 次存储读批次消耗 1 RU
8 storage read requests consume 1 RU8 次存储读请求消耗 1 RU
64 KiB read request payload consumes 1 RU64 KiB 读请求负载消耗 1 RU
Write1 storage write batch consumes 1 RU写1 次存储写批次消耗 1 RU
1 storage write request consumes 1 RU1 次存储写请求消耗 1 RU
1 KiB write request payload consumes 1 RU1 KiB 写请求负载消耗 1 RU
CPU 3 ms consumes 1 RU3 ms 消耗 1 RU
> **Note:** > -> - 每次写操作最终会复制到所有副本（默认 TiKV 有 3 个副本）。每次复制操作视为不同的写操作。 -> - 上表仅列出 TiDB 自管理集群中 RU 计算涉及的资源，不包括网络和存储消耗。关于 {{{ .starter }}} 的 RU，请参见 [{{{ .starter }}} Pricing Details](https://www.pingcap.com/tidb-cloud-serverless-pricing-details/)。 -> - 目前，TiFlash 资源控制仅考虑 SQL CPU，即查询管道任务的 CPU 时间和读请求负载。 +> - 每次写操作最终会复制到所有副本（TiKV 默认有 3 个副本）。每次复制操作都视为一次独立的写操作。 +> - 上表仅列出了 TiDB 自建集群中参与 RU 计算的资源，不包括网络和存储消耗。关于 TiDB Cloud Starter 的 RU，请参见 [TiDB Cloud Starter 计费详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 +> - 目前，TiFlash 资源控制仅考虑 SQL CPU（即查询流水线任务执行所消耗的 CPU 时间）和读请求负载。 ## 资源控制参数 资源控制功能引入了以下系统变量或参数： -* TiDB：可以使用 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) 系统变量控制是否启用资源组的流量控制。 +* TiDB：你可以使用 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) 系统变量控制是否为资源组启用流量控制。 -* TiKV：可以使用 [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) 参数控制是否基于资源组配额进行请求调度。 -* TiFlash：可以使用 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) 系统变量和 [`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) 配置项（在 v7.4.0 引入）控制是否启用 TiFlash 资源控制。 +* TiKV：你可以使用 [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) 参数控制是否基于资源组进行请求调度。 +* TiFlash：你可以使用 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) 系统变量和 [`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) 配置项（v7.4.0 引入）控制是否启用 TiFlash 资源控制。 -* TiKV：对于 TiDB 自管理，可以使用 `resource-control.enabled` 参数控制是否基于资源组配额进行请求调度。对于 TiDB Cloud，`resource-control.enabled` 参数的值默认为 `true`，不支持动态修改。 -* TiFlash：对于 TiDB 自管理，可以使用 `tidb_enable_resource_control` 系统变量和 `enable_resource_control` 配置项（在 v7.4.0 引入）控制是否启用 TiFlash 资源控制。 +* TiKV：对于 TiDB 自建版，你可以使用 `resource-control.enabled` 参数控制是否基于资源组配额进行请求调度。对于 TiDB Cloud，该参数默认值为 `true`，且不支持动态修改。 +* TiFlash：对于 TiDB 自建版，你可以使用 `tidb_enable_resource_control` 系统变量和 `enable_resource_control` 配置项（v7.4.0 引入）控制是否启用 TiFlash 资源控制。 -从 TiDB v7.0.0 版本开始，`tidb_enable_resource_control` 和 `resource-control.enabled` 默认开启。这两个参数组合的结果如下表所示。 +自 TiDB v7.0.0 起，`tidb_enable_resource_control` 和 `resource-control.enabled` 默认开启。两者组合的结果如下表所示。 | `resource-control.enabled` | `tidb_enable_resource_control`= ON | `tidb_enable_resource_control`= OFF | |:----------------------------|:-------------------------------------|:-------------------------------------| -| `resource-control.enabled`= true | 流量控制和调度（推荐） | 无效组合 | -| `resource-control.enabled`= false | 仅流量控制（不推荐） | 该功能已禁用 | +| `resource-control.enabled`= true | 流量控制与调度（推荐） | 非法组合 | +| `resource-control.enabled`= false | 仅流量控制（不推荐） | 功能关闭。 | -从 v7.4.0 版本开始，TiFlash 配置项 `enable_resource_control` 默认为开启。它与 `tidb_enable_resource_control` 一起控制 TiFlash 资源控制功能。只有当 `enable_resource_control` 和 `tidb_enable_resource_control` 都启用时，TiFlash 才会执行流量控制和优先级调度。此外，启用 `enable_resource_control` 后，TiFlash 使用 [Pipeline 执行模型](/tiflash/tiflash-pipeline-model.md)。 +自 v7.4.0 起，TiFlash 配置项 `enable_resource_control` 默认开启。它与 `tidb_enable_resource_control` 一起控制 TiFlash 资源控制功能。只有当 `enable_resource_control` 和 `tidb_enable_resource_control` 都开启时，TiFlash 资源控制才会进行流量控制和优先级调度。此外，开启 `enable_resource_control` 后，TiFlash 会采用 [流水线执行模型](/tiflash/tiflash-pipeline-model.md)。 -从 v7.4.0 版本开始，TiFlash 配置项 `enable_resource_control` 默认为开启。它与 `tidb_enable_resource_control` 一起控制 TiFlash 资源控制功能。只有当 `enable_resource_control` 和 `tidb_enable_resource_control` 都启用时，TiFlash 才会执行流量控制和优先级调度。此外，启用 `enable_resource_control` 后，TiFlash 使用 [Pipeline 执行模型](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)。 +自 v7.4.0 起，TiFlash 配置项 `enable_resource_control` 默认开启。它与 `tidb_enable_resource_control` 一起控制 TiFlash 资源控制功能。只有当 `enable_resource_control` 和 `tidb_enable_resource_control` 都开启时，TiFlash 资源控制才会进行流量控制和优先级调度。此外，开启 `enable_resource_control` 后，TiFlash 会采用 [流水线执行模型](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)。 @@ -148,26 +148,26 @@ Request Unit (RU) 是 TiDB 中对系统资源的统一抽象单位，目前包 ## 如何使用资源控制 -本节介绍如何使用资源控制功能管理资源组以及控制各资源组的资源分配。 +本节介绍如何使用资源控制功能管理资源组，并控制各资源组的资源分配。 -### 估算集群容量 +### 评估集群容量 -在进行资源规划前，你需要了解集群的整体容量。TiDB 提供了 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md) 语句，用于估算集群容量。你可以采用以下方法之一： +在进行资源规划前，你需要了解集群的整体容量。TiDB 提供了 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md) 语句用于评估集群容量。你可以通过以下方式之一进行评估： -- [基于实际工作负载估算容量](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) -- [基于硬件部署估算容量](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) +- [基于实际负载评估容量](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) +- [基于硬件部署评估容量](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) -你可以在 TiDB Dashboard 的 [Resource Manager 页面](/dashboard/dashboard-resource-manager.md) 查看。更多信息请参见 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md#methods-for-estimating-capacity)。 +你可以在 TiDB Dashboard 的 [资源管理页面](/dashboard/dashboard-resource-manager.md) 查看。更多信息请参见 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md#methods-for-estimating-capacity)。 -对于 TiDB 自管理，你可以使用 [`CALIBRATE RESOURCE`](https://docs.pingcap.com/tidb/stable/sql-statement-calibrate-resource) 语句估算集群容量。 +对于 TiDB 自建版，你可以使用 [`CALIBRATE RESOURCE`](https://docs.pingcap.com/tidb/stable/sql-statement-calibrate-resource) 语句评估集群容量。 -对于 TiDB Cloud，该语句不适用。 +对于 TiDB Cloud，[`CALIBRATE RESOURCE`](https://docs.pingcap.com/tidb/stable/sql-statement-calibrate-resource) 语句不适用。 @@ -175,29 +175,29 @@ Request Unit (RU) 是 TiDB 中对系统资源的统一抽象单位，目前包 要创建、修改或删除资源组，你需要拥有 `SUPER` 或 `RESOURCE_GROUP_ADMIN` 权限。 -你可以使用 [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) 创建集群的资源组。 +你可以通过 [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) 为集群创建资源组。 -对于已存在的资源组，可以使用 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) 修改其 `RU_PER_SEC`（每秒的 RU 补充速率）选项。对资源组的更改会立即生效。 +对于已存在的资源组，你可以通过 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) 修改资源组的 `RU_PER_SEC` 选项（每秒 RU 回填速率）。资源组的更改会立即生效。 -你也可以使用 [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md) 删除资源组。 +你可以通过 [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md) 删除资源组。 ### 创建资源组 以下是创建资源组的示例。 -1. 创建资源组 `rg1`，资源限制为每秒 500 RU，允许应用在该资源组中超出资源限制。 +1. 创建资源组 `rg1`，资源限制为每秒 500 RU，并允许该资源组内的应用超额使用资源。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE; ``` -2. 创建资源组 `rg2`，RU 补充速率为每秒 600 RU，不允许应用超出资源限制。 +2. 创建资源组 `rg2`，RU 回填速率为每秒 600 RU，不允许该资源组内的应用超额使用资源。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 600; ``` -3. 创建资源组 `rg3`，绝对优先级设置为 `HIGH`。目前支持 `LOW|MEDIUM|HIGH`，默认值为 `MEDIUM`。 +3. 创建资源组 `rg3`，并将绝对优先级设置为 `HIGH`。绝对优先级目前支持 `LOW|MEDIUM|HIGH`，默认值为 `MEDIUM`。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 100 PRIORITY = HIGH; @@ -205,48 +205,48 @@ Request Unit (RU) 是 TiDB 中对系统资源的统一抽象单位，目前包 ### 绑定资源组 -TiDB 支持以下三个层级的资源组设置。 +TiDB 支持以下三种级别的资源组设置。 -- 用户层。通过 [`CREATE USER`](/sql-statements/sql-statement-create-user.md) 或 [`ALTER USER`](/sql-statements/sql-statement-alter-user.md#modify-the-resource-group-bound-to-the-user) 语句，将用户绑定到特定资源组。用户绑定后，用户创建的会话会自动绑定到对应的资源组。 -- 会话层。通过 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 设置当前会话的资源组。 -- 语句层。通过 [`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name) 优化器提示，为当前语句设置资源组。 +- 用户级。通过 [`CREATE USER`](/sql-statements/sql-statement-create-user.md) 或 [`ALTER USER`](/sql-statements/sql-statement-alter-user.md#modify-the-resource-group-bound-to-the-user) 语句将用户绑定到指定资源组。用户绑定资源组后，该用户新建的会话会自动绑定到对应资源组。 +- 会话级。通过 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 为当前会话设置资源组。 +- 语句级。通过 [`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name) Optimizer Hint 为当前语句设置资源组。 -#### 绑定用户到资源组 +#### 将用户绑定到资源组 -以下示例创建用户 `usr1`，并将其绑定到资源组 `rg1`。`rg1` 是在 [创建资源组](#create-a-resource-group) 中示例创建的资源组。 +以下示例创建用户 `usr1` 并将其绑定到资源组 `rg1`。`rg1` 是在 [创建资源组](#create-a-resource-group) 示例中创建的资源组。 ```sql CREATE USER 'usr1'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg1; ``` -以下示例使用 `ALTER USER` 将用户 `usr2` 绑定到资源组 `rg2`。`rg2` 是在 [创建资源组](#create-a-resource-group) 中示例创建的资源组。 +以下示例使用 `ALTER USER` 将用户 `usr2` 绑定到资源组 `rg2`。`rg2` 是在 [创建资源组](#create-a-resource-group) 示例中创建的资源组。 ```sql ALTER USER usr2 RESOURCE GROUP rg2; ``` -绑定用户后，新创建会话的资源消耗将由指定的配额（Request Unit，RU）控制。如果系统负载较高且没有剩余容量，`usr2` 的资源消耗速率将受到严格限制，不得超过配额。由于 `usr1` 绑定在配置了 `BURSTABLE` 的 `rg1` 上，`usr1` 的消耗速率允许超出配额。 +绑定用户后，新建会话的资源消耗将受指定配额（请求单位，RU）控制。如果系统负载较高且无空闲资源，`usr2` 的资源消耗速率将被严格限制在配额以内。由于 `usr1` 绑定的 `rg1` 配置了 `BURSTABLE`，因此 `usr1` 的消耗速率允许超出配额。 -如果请求过多导致资源组资源不足，客户端请求将等待。如果等待时间过长，请求会报错。 +如果请求过多导致资源组资源不足，客户端请求会进入等待。如果等待时间过长，请求会报错。 > **Note:** > -> - 使用 `CREATE USER` 或 `ALTER USER` 将用户绑定到资源组后，不会影响用户已有的会话，只对新会话生效。 -> - TiDB 在集群初始化时会自动创建一个 `default` 资源组。该资源组的 `RU_PER_SEC` 默认值为 `UNLIMITED`（等于 `INT` 类型的最大值，即 `2147483647`），且处于 `BURSTABLE` 模式。未绑定资源组的语句会自动绑定到此资源组。该资源组不支持删除，但可以修改其 RU 配额。 -> -> 要取消用户与资源组的绑定，可以将其重新绑定到 `default` 组，如下所示： +> - 通过 `CREATE USER` 或 `ALTER USER` 绑定用户到资源组后，仅对新建会话生效，已存在的会话不受影响。 +> - TiDB 在集群初始化时会自动创建 `default` 资源组。该资源组的 `RU_PER_SEC` 默认值为 `UNLIMITED`（等同于 `INT` 类型的最大值，即 `2147483647`），并处于 `BURSTABLE` 模式。未绑定资源组的语句会自动绑定到该资源组。该资源组不支持删除，但可以修改其 RU 配置。 + +如需将用户解绑资源组，只需重新绑定到 `default` 组： ```sql ALTER USER 'usr3'@'%' RESOURCE GROUP `default`; ``` -有关详细信息，请参见 [`ALTER USER ... RESOURCE GROUP`](/sql-statements/sql-statement-alter-user.md#modify-the-resource-group-bound-to-the-user)。 +更多详情请参见 [`ALTER USER ... RESOURCE GROUP`](/sql-statements/sql-statement-alter-user.md#modify-the-resource-group-bound-to-the-user)。 #### 将当前会话绑定到资源组 -你可以使用 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 语句，改变当前会话绑定的资源组。通过绑定会话到资源组，限制该会话的资源使用（RU）。 +你可以使用 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 语句更改当前会话绑定的资源组。会话绑定资源组后，该会话的资源使用受指定配额（RU）限制。 -当系统变量 [`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) 设置为 `ON` 时，执行此语句需要拥有 `SUPER` 或 `RESOURCE_GROUP_ADMIN` 或 `RESOURCE_GROUP_USER` 权限。 +当系统变量 [`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) 设置为 `ON` 时，执行该语句需要 `SUPER`、`RESOURCE_GROUP_ADMIN` 或 `RESOURCE_GROUP_USER` 权限。 以下示例将当前会话绑定到资源组 `rg1`。 @@ -256,9 +256,9 @@ SET RESOURCE GROUP rg1; #### 将当前语句绑定到资源组 -通过在 SQL 语句中添加 [`RESOURCE_GROUP(resource_group_name)`](/optimizer-hints.md#resource_groupresource_group_name) 提示，可以指定该语句绑定的资源组。此提示支持 `SELECT`、`INSERT`、`UPDATE` 和 `DELETE` 语句。 +通过在 SQL 语句中添加 [`RESOURCE_GROUP(resource_group_name)`](/optimizer-hints.md#resource_groupresource_group_name) Hint，可以指定该语句绑定的资源组。该 Hint 支持 `SELECT`、`INSERT`、`UPDATE` 和 `DELETE` 语句。 -当系统变量 [`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) 设置为 `ON` 时，使用此提示需要拥有 `SUPER` 或 `RESOURCE_GROUP_ADMIN` 或 `RESOURCE_GROUP_USER` 权限。 +当系统变量 [`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) 设置为 `ON` 时，使用该 Hint 需要 `SUPER`、`RESOURCE_GROUP_ADMIN` 或 `RESOURCE_GROUP_USER` 权限。 以下示例将当前语句绑定到资源组 `rg1`。 @@ -266,52 +266,52 @@ SET RESOURCE GROUP rg1; SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; ``` -## 禁用资源控制 +## 关闭资源控制 -1. 执行以下语句禁用资源控制功能。 +1. 执行以下语句关闭资源控制功能。 ```sql SET GLOBAL tidb_enable_resource_control = 'OFF'; ``` -2. 将 TiKV 参数 [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) 设置为 `false`，以禁用基于资源组 RU 的调度。 +2. 将 TiKV 参数 [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) 设置为 `false`，以关闭基于资源组 RU 的调度。 -3. 将 TiFlash 配置项 [`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) 设置为 `false`，以禁用 TiFlash 资源控制。 +3. 将 TiFlash 配置项 [`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) 设置为 `false`，以关闭 TiFlash 资源控制。 -1. 执行以下语句禁用资源控制功能。 +1. 执行以下语句关闭资源控制功能。 ```sql SET GLOBAL tidb_enable_resource_control = 'OFF'; ``` -2. 对于 TiDB 自管理，可以使用 `resource-control.enabled` 参数控制是否基于资源组配额进行请求调度。对于 TiDB Cloud，`resource-control.enabled` 参数的值默认为 `true`，不支持动态修改。如需在 TiDB Cloud Dedicated 集群中禁用此功能，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 +2. 对于 TiDB 自建版，你可以使用 `resource-control.enabled` 参数控制是否基于资源组配额进行请求调度。对于 TiDB Cloud，该参数默认值为 `true`，且不支持动态修改。如需为 TiDB Cloud 专业版集群关闭该参数，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 -3. 对于 TiDB 自管理，可以使用 `enable_resource_control` 配置项控制是否启用 TiFlash 资源控制。对于 TiDB Cloud，`enable_resource_control` 参数的值默认为 `true`，不支持动态修改。如需在 TiDB Cloud Dedicated 集群中禁用此功能，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 +3. 对于 TiDB 自建版，你可以使用 `enable_resource_control` 配置项控制是否启用 TiFlash 资源控制。对于 TiDB Cloud，该参数默认值为 `true`，且不支持动态修改。如需为 TiDB Cloud 专业版集群关闭该参数，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 ## 查看 RU 消耗 -你可以查看 RU 消耗信息。 +你可以查看 RU 消耗相关信息。 -### 查看 SQL 的 RU 消耗 +### 通过 SQL 查看 RU 消耗 你可以通过以下方式查看 SQL 语句的 RU 消耗： - 系统变量 `tidb_last_query_info` - `EXPLAIN ANALYZE` -- 慢查询及对应的系统表 +- 慢查询及对应系统表 - `statements_summary` -#### 通过查询系统变量 `tidb_last_query_info` 查看上次 SQL 执行的 RU +#### 通过查询系统变量 `tidb_last_query_info` 查看上次 SQL 执行消耗的 RU -TiDB 提供了系统变量 [`tidb_last_query_info`](/system-variables.md#tidb_last_query_info-new-in-v4014)。该变量记录了上次执行的 DML 语句信息，包括该 SQL 执行的 RU。 +TiDB 提供了系统变量 [`tidb_last_query_info`](/system-variables.md#tidb_last_query_info-new-in-v4014)。该变量记录了上一次执行的 DML 语句的信息，包括 SQL 执行消耗的 RU。 示例： @@ -326,7 +326,7 @@ TiDB 提供了系统变量 [`tidb_last_query_info`](/system-variables.md#tidb_la Rows matched: 1 Changed: 1 Warnings: 0 ``` -2. 查询系统变量 `tidb_last_query_info` 查看上次执行语句的信息： +2. 查询系统变量 `tidb_last_query_info`，查看上次执行语句的信息： ```sql SELECT @@tidb_last_query_info; @@ -341,33 +341,33 @@ TiDB 提供了系统变量 [`tidb_last_query_info`](/system-variables.md#tidb_la 1 row in set (0.01 sec) ``` - 结果中，`ru_consumption` 即为该 SQL 执行所消耗的 RU。 + 结果中的 `ru_consumption` 即为该 SQL 语句执行消耗的 RU。 -#### 通过 `EXPLAIN ANALYZE` 查看 SQL 执行的 RU +#### 通过 `EXPLAIN ANALYZE` 查看 SQL 执行过程中的 RU 消耗 -你可以使用 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md#ru-request-unit-consumption) 获取 SQL 执行过程中消耗的 RU 数量。注意，RU 数量受缓存（例如 [coprocessor cache](/coprocessor-cache.md)）影响。当多次执行相同 SQL 时，每次的 RU 消耗可能不同。RU 数值不代表每次执行的精确值，但可作为估算参考。 +你可以使用 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md#ru-request-unit-consumption) 语句获取 SQL 执行过程中的 RU 消耗量。需要注意，RU 消耗量会受到缓存（如 [coprocessor cache](/coprocessor-cache.md)）影响。相同 SQL 多次执行时，每次消耗的 RU 可能不同。RU 值不代表每次执行的精确值，但可作为估算参考。 -#### 慢查询及对应的系统表 +#### 慢查询及对应系统表 -启用资源控制后，TiDB 的 [慢查询日志](/identify-slow-queries.md) 和对应的系统表 [`INFORMATION_SCHEMA.SLOW_QUERY`](/information-schema/information-schema-slow-query.md) 会包含资源组信息、对应 SQL 的 RU 消耗以及等待可用 RU 的时间。 +启用资源控制后，TiDB 的 [慢查询日志](/identify-slow-queries.md) 及对应系统表 [`INFORMATION_SCHEMA.SLOW_QUERY`](/information-schema/information-schema-slow-query.md) 会包含资源组、对应 SQL 的 RU 消耗以及等待可用 RU 的耗时。 -启用资源控制后，系统表 [`INFORMATION_SCHEMA.SLOW_QUERY`](/information-schema/information-schema-slow-query.md) 会包含资源组信息、对应 SQL 的 RU 消耗以及等待可用 RU 的时间。 +启用资源控制后，系统表 [`INFORMATION_SCHEMA.SLOW_QUERY`](/information-schema/information-schema-slow-query.md) 会包含资源组、对应 SQL 的 RU 消耗以及等待可用 RU 的耗时。 #### 通过 `statements_summary` 查看 RU 统计信息 -TiDB 的系统表 [`INFORMATION_SCHEMA.statements_summary`](/statement-summary-tables.md#statements_summary) 存储了 SQL 语句的归一化和聚合统计信息。你可以通过该表查看和分析 SQL 执行性能，还包含资源控制的统计信息，包括资源组名、RU 消耗和等待可用 RU 的时间。更多详情请参见 [`statements_summary` 字段说明](/statement-summary-tables.md#statements_summary-fields-description)。 +TiDB 的系统表 [`INFORMATION_SCHEMA.statements_summary`](/statement-summary-tables.md#statements_summary) 存储了 SQL 语句的归一化和聚合统计信息。你可以通过该系统表查看和分析 SQL 语句的执行性能。该表也包含资源控制相关统计信息，包括资源组名称、RU 消耗和等待可用 RU 的耗时。更多详情请参见 [`statements_summary` 字段说明](/statement-summary-tables.md#statements_summary-fields-description)。 ### 查看资源组的 RU 消耗 -从 v7.6.0 版本开始，TiDB 提供了系统表 [`mysql.request_unit_by_group`](/mysql-schema/mysql-schema.md#system-tables-related-to-resource-control)，用于存储各资源组的 RU 消耗历史记录。 +自 v7.6.0 起，TiDB 提供了系统表 [`mysql.request_unit_by_group`](/mysql-schema/mysql-schema.md#system-tables-related-to-resource-control) 用于存储各资源组的 RU 消耗历史记录。 示例： @@ -390,17 +390,17 @@ SELECT * FROM request_unit_by_group LIMIT 5; > **Note:** > -> `mysql.request_unit_by_group` 的数据由 TiDB 每天结束时自动导入。如果某天某个资源组的 RU 消耗为 0，则不会生成记录。默认情况下，该表存储最近三个月（最多 92 天）的数据。超出此期限的数据会自动清除。 +> `mysql.request_unit_by_group` 的数据由 TiDB 定时任务在每天结束时自动导入。如果某天某资源组的 RU 消耗为 0，则不会生成记录。该表默认保留最近三个月（最多 92 天）数据，超出部分会自动清理。 ## 监控指标与图表 -TiDB 定期收集资源控制的运行时信息，并在 Grafana 的 **TiDB** > **Resource Control** 仪表盘中提供指标的可视化图表。指标详见 [TiDB 重要监控指标](/grafana-tidb-dashboard.md) 中的 **Resource Control** 部分。 +TiDB 会定期收集资源控制的运行时信息，并在 Grafana 的 **TiDB** > **Resource Control** 看板中提供可视化图表。相关指标详见 [TiDB 重要监控指标](/grafana-tidb-dashboard.md) 的 **Resource Control** 部分。 -TiKV 也会记录来自不同资源组的请求 QPS。更多详情请参见 [TiKV 监控指标详情](/grafana-tikv-dashboard.md#grpc)。 +TiKV 也会记录不同资源组的请求 QPS。详情请参见 [TiKV 监控指标详解](/grafana-tikv-dashboard.md#grpc)。 -你可以在 TiDB Dashboard 的 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md) 表中查看当前的资源组数据。更多信息请参见 [Resource Manager 页面](/dashboard/dashboard-resource-manager.md)。 +你可以在 TiDB Dashboard 的当前 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md) 表中查看资源组数据。更多详情请参见 [资源管理页面](/dashboard/dashboard-resource-manager.md)。 @@ -408,33 +408,33 @@ TiKV 也会记录来自不同资源组的请求 QPS。更多详情请参见 [TiK > **Note:** > -> 该部分仅适用于 TiDB 自管理。目前，TiDB Cloud 不提供资源控制指标。 +> 本节仅适用于 TiDB 自建版。目前，TiDB Cloud 不提供资源控制相关监控指标。 -TiDB 定期收集资源控制的运行时信息，并在 Grafana 的 **TiDB** > **Resource Control** 仪表盘中提供指标的可视化图表。 +TiDB 会定期收集资源控制的运行时信息，并在 Grafana 的 **TiDB** > **Resource Control** 看板中提供可视化图表。 -TiKV 也会在 Grafana 的 **TiKV** 仪表盘中记录来自不同资源组的请求 QPS。 +TiKV 也会在 Grafana 的 **TiKV** 看板中记录不同资源组的请求 QPS。 ## 工具兼容性 -资源控制功能不会影响数据导入、导出及其他复制工具的正常使用。BR、TiDB Lightning 和 TiCDC 目前不支持处理与资源控制相关的 DDL 操作，其资源消耗也不受资源控制限制。 +资源控制功能不会影响数据导入、导出及其他同步工具的常规使用。BR、TiDB Lightning 和 TiCDC 目前不支持处理与资源控制相关的 DDL 操作，其资源消耗也不受资源控制限制。 -## 常见问题 +## FAQ -1. 如果我不想使用资源组，是否必须禁用资源控制？ +1. 如果不想使用资源组，是否必须关闭资源控制？ - 不需要。未指定资源组的用户会绑定到资源无限制的 `default` 资源组。当所有用户都属于 `default` 资源组时，资源分配方式与禁用资源控制时相同。 + 不需要。未指定资源组的用户会被绑定到拥有无限资源的 `default` 资源组。当所有用户都属于 `default` 资源组时，资源分配方式与关闭资源控制时相同。 -2. 数据库用户可以绑定多个资源组吗？ +2. 一个数据库用户能否绑定多个资源组？ - 不可以。一个数据库用户只能绑定到一个资源组。但在会话运行期间，可以使用 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 设置当前会话使用的资源组，也可以使用优化器提示 [`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name) 设置运行语句的资源组。 + 不能。一个数据库用户只能绑定一个资源组。但在会话运行时，你可以通过 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 设置当前会话使用的资源组，也可以通过优化器 Hint [`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name) 设置当前语句的资源组。 -3. 如果所有资源组的总资源分配（`RU_PER_SEC`）超过系统容量，会发生什么？ +3. 如果所有资源组的总资源分配（`RU_PER_SEC`）超过系统容量会怎样？ - TiDB 在创建资源组时不会验证容量。只要系统有足够的可用资源，TiDB 就能满足每个资源组的资源需求。当系统资源超出限制时，TiDB 会优先满足高优先级资源组的请求。如果同一优先级的请求不能全部满足，TiDB 会根据 `RU_PER_SEC` 按比例分配资源。 + TiDB 在创建资源组时不会校验容量。只要系统有足够可用资源，TiDB 就能满足各资源组的资源需求。当系统资源超出上限时，TiDB 会优先满足高优先级资源组的请求。如果同一优先级的请求无法全部满足，TiDB 会按资源分配（`RU_PER_SEC`）比例分配资源。 -## 另请参见 +## 参见 * [CREATE RESOURCE GROUP](/sql-statements/sql-statement-create-resource-group.md) * [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md) diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index dd03e08f49826..02c97fed32060 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -1,77 +1,77 @@ --- -title: 管理消耗资源超出预期的查询（Runaway Queries） +title: 管理超出预期资源消耗的查询（Runaway Queries） summary: 介绍如何通过资源管理能力控制和降级资源消耗过多的查询（Runaway Queries）。 --- -# 管理消耗资源超出预期的查询（Runaway Queries） +# 管理超出预期资源消耗的查询（Runaway Queries） > **Note:** > -> 该功能在 [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 集群上不可用。 +> 此功能不适用于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 和 [TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 集群。 -Runaway query 指的是消耗时间或资源超出预期的查询。以下将使用 **runaway queries** 一词来描述管理 runaway query 的功能。 +Runaway query 指的是消耗时间或资源超出预期的查询。下文中使用 **runaway queries** 来描述对这类查询的管理功能。 -- 从 v7.2.0 版本开始，资源控制功能引入了对 runaway queries 的管理。你可以为资源组设置条件，以识别 runaway queries，并自动采取措施防止其耗尽资源，影响其他查询。你可以在 [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) 或 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) 中包含 `QUERY_LIMIT` 字段来管理 runaway queries。 -- 从 v7.3.0 版本开始，资源控制功能引入了手动管理 runaway watches，支持快速识别特定 SQL 语句或 Digest 的 runaway 查询。你可以执行 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md) 语句，手动管理资源组中的 runaway 查询监控列表。 +- 从 v7.2.0 开始，资源控制功能引入了 runaway queries 的管理。你可以为资源组设置判定 runaway query 的条件，并自动采取措施，防止其耗尽资源并影响其他查询。你可以通过在 [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) 或 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) 语句中包含 `QUERY_LIMIT` 字段来为资源组管理 runaway queries。 +- 从 v7.3.0 开始，资源控制功能引入了 runaway watch 的手动管理，支持针对指定 SQL 语句或 Digest 快速识别 runaway queries。你可以执行 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md) 语句，手动管理资源组中的 runaway queries watch 列表。 -关于资源控制功能的更多信息，请参见 [使用资源控制实现资源组限制和流控](/tidb-resource-control-ru-groups.md)。 +关于资源控制功能的更多信息，参见 [使用资源控制实现资源组限制与流控](/tidb-resource-control-ru-groups.md)。 ## `QUERY_LIMIT` 参数 -如果查询超过以下任一限制，即被识别为 runaway 查询： +如果查询超出了以下任一限制，则会被判定为 runaway query： -- `EXEC_ELAPSED`：检查查询执行时间是否超过限制。此规则适用于读写 DML 语句。 -- `PROCESSED_KEYS`：检查 Coprocessor 处理的键数量是否超过限制。此规则仅适用于读语句。 -- `RU`：检查查询消耗的总读写 RUs 是否超过限制。此规则仅适用于读语句。 +- `EXEC_ELAPSED`：检查查询执行时间是否超出限制。该规则适用于读写 DML 语句。 +- `PROCESSED_KEYS`：检查 Coprocessor 处理的 key 数量是否超出限制。该规则仅适用于读语句。 +- `RU`：检查语句消耗的读写 RU 总数是否超出限制。该规则仅适用于读语句。 支持的操作（`ACTION`）： -- `DRYRUN`：不采取任何操作。将记录追加到 runaway 查询的记录中，主要用于观察条件设置是否合理。 -- `COOLDOWN`：将查询的执行优先级降至最低。查询以最低优先级继续执行，不占用其他操作的资源。 -- `KILL`：自动终止识别出的查询，并报告错误 `Query execution was interrupted, identified as runaway query`。 -- `SWITCH_GROUP`：在 v8.4.0 版本引入，将识别出的查询切换到指定的资源组以继续执行。该查询完成后，后续 SQL 语句在原资源组中执行。如果指定的资源组不存在，查询将保持在原资源组。 +- `DRYRUN`：不采取任何操作，仅记录 runaway queries。主要用于观察条件设置是否合理。 +- `COOLDOWN`：将查询的执行优先级降至最低。查询以最低优先级继续执行，不再占用其他操作的资源。 +- `KILL`：自动终止被判定的查询，并报错 `Query execution was interrupted, identified as runaway query`。 +- `SWITCH_GROUP`：v8.4.0 引入，该参数将被判定的查询切换到指定的资源组继续执行。该查询完成后，后续 SQL 语句仍在原资源组中执行。如果指定的资源组不存在，查询仍留在原资源组。 -为了避免大量并发 runaway 查询耗尽系统资源，资源控制功能引入了快速识别机制，可以快速识别并隔离 runaway 查询。你可以通过 `WATCH` 子句使用此功能。当查询被识别为 runaway 查询时，该机制会提取匹配的特征（由 `WATCH` 后的参数定义）。在接下来的时间段（由 `DURATION` 定义）内，匹配的 runaway 查询特征会被加入监控列表，TiDB 实例会匹配监控列表中的查询。匹配的查询会被直接标记为 runaway 查询，并根据对应的操作进行隔离，而不是等待条件识别。`KILL` 操作会终止查询并报告错误 `Quarantined and interrupted because of being in runaway watch list`。 +为避免过多并发的 runaway queries 耗尽系统资源，资源控制功能引入了快速识别机制，可快速识别并隔离 runaway queries。你可以通过 `WATCH` 子句使用该功能。当查询被判定为 runaway query 时，该机制会提取查询的匹配特征（由 `WATCH` 后的参数定义）。在接下来的时间段内（由 `DURATION` 定义），runaway query 的匹配特征会被加入 watch 列表，TiDB 实例会将查询与 watch 列表进行匹配。匹配到的查询会被直接标记为 runaway query 并按对应操作隔离，无需等待条件再次判定。`KILL` 操作会终止查询并报错 `Quarantined and interrupted because of being in runaway watch list`。 -`WATCH` 快速识别的三种匹配方式： +`WATCH` 的快速识别有三种匹配方式： -- `EXACT` 表示只快速识别完全相同 SQL 文本的语句。 -- `SIMILAR` 表示匹配所有具有相同模式的 SQL Digest，忽略字面值。 -- `PLAN` 表示匹配所有具有相同模式的 Plan Digest。 +- `EXACT` 表示仅对 SQL 文本完全相同的语句进行快速识别。 +- `SIMILAR` 表示对 SQL Digest 相同的所有语句进行匹配，忽略字面量值。 +- `PLAN` 表示对 Plan Digest 相同的所有语句进行匹配。 `WATCH` 中的 `DURATION` 选项表示识别项的持续时间，默认为无限。 -添加监控项后，无论 `QUERY_LIMIT` 配置如何变更或删除，匹配特征和 `ACTION` 都不会被更改或删除。你可以使用 `QUERY WATCH REMOVE` 来移除监控项。 +添加 watch 项后，无论 `QUERY_LIMIT` 配置如何变更或删除，匹配特征和 `ACTION` 都不会被更改或删除。你可以使用 `QUERY WATCH REMOVE` 移除 watch 项。 `QUERY_LIMIT` 的参数如下： -| 参数 | 描述 | 备注 | -|------------------|--------------------------------------------------------------|--------------------------------------------------------------| -| `EXEC_ELAPSED` | 当查询执行时间超过此值时，识别为 runaway 查询 | `EXEC_ELAPSED = '60s'` 表示如果查询执行时间超过 60 秒，则识别为 runaway 查询。 | -| `PROCESSED_KEYS` | 当 Coprocessor 处理的键数量超过此值时，识别为 runaway 查询 | `PROCESSED_KEYS = 1000` 表示如果 Coprocessor 处理的键数超过 1000，则识别为 runaway 查询。 | -| `RU` | 当查询消耗的总读写 RUs 超过此值时，识别为 runaway 查询 | `RU = 1000` 表示如果查询消耗的读写 RUs 总数超过 1000，则识别为 runaway 查询。 | -| `ACTION` | 识别为 runaway 查询后采取的操作 | 可选值为 `DRYRUN`、`COOLDOWN`、`KILL` 和 `SWITCH_GROUP`。 | -| `WATCH` | 快速匹配识别的 runaway 查询。如果在一定时间内再次遇到相同或相似的查询，则立即执行对应操作。 | 可选。例如，`WATCH=SIMILAR DURATION '60s'`、`WATCH=EXACT DURATION '1m'` 和 `WATCH=PLAN`。 | +| 参数 | 描述 | 说明 | +|---------------------|-----------------|---------------------------------------| +| `EXEC_ELAPSED` | 当查询执行时间超过该值时，被判定为 runaway query | `EXEC_ELAPSED = '60s'` 表示查询执行超过 60 秒即被判定为 runaway query。 | +| `PROCESSED_KEYS` | 当 Coprocessor 处理的 key 数量超过该值时，被判定为 runaway query | `PROCESSED_KEYS = 1000` 表示 Coprocessor 处理的 key 数量超过 1000 即被判定为 runaway query。 | +| `RU` | 当查询消耗的读写 RU 总数超过该值时，被判定为 runaway query | `RU = 1000` 表示查询消耗的读写 RU 总数超过 1000 即被判定为 runaway query。 | +| `ACTION` | 被判定为 runaway query 时采取的操作 | 可选值为 `DRYRUN`、`COOLDOWN`、`KILL` 和 `SWITCH_GROUP`。 | +| `WATCH` | 快速匹配已判定的 runaway query。如果在一定时间内再次遇到相同或相似的查询，立即执行对应操作。 | 可选。例如，`WATCH=SIMILAR DURATION '60s'`、`WATCH=EXACT DURATION '1m'`、`WATCH=PLAN`。 | > **Note:** > -> 如果你希望严格限制 runaway 查询到某个特定资源组，建议结合 [`QUERY WATCH`](#query-watch-parameters) 语句使用 `SWITCH_GROUP`。因为 `QUERY_LIMIT` 仅在查询满足条件时触发对应的 `ACTION` 操作，在此类场景中，`SWITCH_GROUP` 可能无法及时将查询切换到目标资源组。 +> 如果你希望严格限制 runaway queries 到指定资源组，建议结合 `SWITCH_GROUP` 和 [`QUERY WATCH`](#query-watch-parameters) 语句使用。因为 `QUERY_LIMIT` 只会在查询满足条件时触发对应的 `ACTION` 操作，在此类场景下，`SWITCH_GROUP` 可能无法及时将查询切换到目标资源组。 ## 示例 -1. 创建一个资源组 `rg1`，配额为每秒 500 RUs，定义超时超过 60 秒的查询为 runaway 查询，并降低其优先级。 +1. 创建一个名为 `rg1` 的资源组，配额为每秒 500 RU，并将执行超过 60 秒的查询判定为 runaway query，降低其优先级。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN); ``` -2. 将 `rg1` 资源组设置为终止 runaway 查询，并在接下来的 10 分钟内立即将匹配相同模式的查询标记为 runaway 查询。 +2. 修改 `rg1` 资源组，将 runaway queries 直接终止，并在接下来的 10 分钟内对相同模式的查询立即判定为 runaway query。 ```sql ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m'); ``` -3. 将 `rg1` 资源组设置为取消 runaway 查询检测。 +3. 修改 `rg1` 资源组，取消 runaway query 检查。 ```sql ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL; @@ -79,42 +79,42 @@ Runaway query 指的是消耗时间或资源超出预期的查询。以下将使 ## `QUERY WATCH` 参数 -关于 `QUERY WATCH` 的详细说明，请参见 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)。 +关于 `QUERY WATCH` 的语法详情，参见 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)。 -参数如下： +参数说明如下： -- `RESOURCE GROUP` 指定一个资源组。由此语句添加的 runaway 查询匹配特征会加入到该资源组的监控列表中。此参数可省略，省略时适用于 `default` 资源组。 -- `ACTION` 的含义与 `QUERY LIMIT` 相同。此参数可省略，省略后识别后采取的操作会采用资源组中通过 `QUERY LIMIT` 配置的 `ACTION`，且不会随 `QUERY LIMIT` 配置变化而变化。如果资源组中未配置 `ACTION`，会报错。 -- `QueryWatchTextOption` 有三种选项：`SQL DIGEST`、`PLAN DIGEST` 和 `SQL TEXT`。 - - `SQL DIGEST` 与 `SIMILAR` 相同。后续参数接受字符串、用户变量或其他表达式，结果为字符串。字符串长度必须为 64，与 TiDB 中的 Digest 定义相同。 +- `RESOURCE GROUP` 指定资源组。该语句添加的 runaway query 匹配特征会加入该资源组的 watch 列表。该参数可省略，省略时应用于 `default` 资源组。 +- `ACTION` 的含义与 `QUERY LIMIT` 相同。该参数可省略，省略时，识别后采取的操作采用资源组中 `QUERY LIMIT` 配置的 `ACTION`，且该操作不会随 `QUERY LIMIT` 配置变更。如果资源组未配置 `ACTION`，则会报错。 +- `QueryWatchTextOption` 参数有三种选项：`SQL DIGEST`、`PLAN DIGEST` 和 `SQL TEXT`。 + - `SQL DIGEST` 与 `SIMILAR` 相同。后续参数接受字符串、用户自定义变量或其他返回字符串结果的表达式。字符串长度需为 64，与 TiDB 中 Digest 定义一致。 - `PLAN DIGEST` 与 `PLAN` 相同。后续参数为 Digest 字符串。 - - `SQL TEXT` 表示将输入的 SQL 作为原始字符串（`EXACT`）匹配，或解析并编译成 `SQL DIGEST`（`SIMILAR`）或 `PLAN DIGEST`（`PLAN`），具体取决于后续参数。 + - `SQL TEXT` 以原始字符串（`EXACT`）匹配输入 SQL，或根据后续参数解析编译为 `SQL DIGEST`（`SIMILAR`）或 `PLAN DIGEST`（`PLAN`）。 -- 添加匹配特征到默认资源组的 runaway 查询监控列表（需要提前为默认资源组设置 `QUERY LIMIT`）。 +- 为默认资源组的 runaway query watch 列表添加一个匹配特征（需提前为默认资源组设置 `QUERY LIMIT`）。 ```sql QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2'; ``` -- 通过解析 SQL 为 SQL Digest，将匹配特征添加到 `rg1` 资源组的 runaway 查询监控列表。当未指定 `ACTION` 时，使用 `rg1` 资源组已配置的 `ACTION`。 +- 通过解析 SQL 为 SQL Digest，为 `rg1` 资源组的 runaway query watch 列表添加一个匹配特征。当未指定 `ACTION` 时，使用 `rg1` 资源组已配置的 `ACTION` 选项。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 SQL TEXT SIMILAR TO 'select * from test.t2'; ``` -- 通过解析 SQL 为 SQL Digest，将匹配特征添加到 `rg1` 资源组的 runaway 查询监控列表，并将 `ACTION` 指定为 `SWITCH_GROUP(rg2)`。 +- 通过解析 SQL 为 SQL Digest，为 `rg1` 资源组的 runaway query watch 列表添加一个匹配特征，并指定 `ACTION` 为 `SWITCH_GROUP(rg2)`。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 ACTION SWITCH_GROUP(rg2) SQL TEXT SIMILAR TO 'select * from test.t2'; ``` -- 使用 `PLAN DIGEST` 将匹配特征添加到 `rg1` 资源组的 runaway 查询监控列表，并将 `ACTION` 指定为 `KILL`。 +- 通过 `PLAN DIGEST` 为 `rg1` 资源组的 runaway query watch 列表添加一个匹配特征，并指定 `ACTION` 为 `KILL`。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 ACTION KILL PLAN DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57'; ``` -- 通过查询 `INFORMATION_SCHEMA.RUNAWAY_WATCHES` 获取监控项 ID，并删除监控项。 +- 通过查询 `INFORMATION_SCHEMA.RUNAWAY_WATCHES` 获取 watch 项 ID 并删除该 watch 项。 ```sql SELECT * from information_schema.runaway_watches ORDER BY id\G @@ -138,11 +138,11 @@ Runaway query 指的是消耗时间或资源超出预期的查询。以下将使 QUERY WATCH REMOVE 1; ``` -## 可观察性 +## 可观测性 -你可以通过以下系统表和 `INFORMATION_SCHEMA` 获取关于 runaway 查询的更多信息： +你可以通过以下系统表和 `INFORMATION_SCHEMA` 获取更多 runaway query 的信息： -+ `mysql.tidb_runaway_queries` 表包含过去 7 天内所有识别的 runaway 查询的历史记录。以一行数据为例： ++ `mysql.tidb_runaway_queries` 表包含过去 7 天内所有被判定为 runaway query 的历史记录。以下为其中一行的示例： ```sql MySQL [(none)]> SELECT * FROM mysql.tidb_runaway_queries LIMIT 1\G @@ -160,10 +160,10 @@ Runaway query 指的是消耗时间或资源超出预期的查询。以下将使 字段说明： - - `start_time` 表示识别出 runaway 查询的时间。 - - `repeats` 表示自 `start_time` 以来识别出的次数。 - - `match_type` 表示识别方式。值可以是以下之一： - - `identify` 表示符合 runaway 查询条件。 - - `watch` 表示符合监控列表中的快速识别规则。 + - `start_time` 表示 runaway query 被判定的时间。 + - `repeats` 表示自 `start_time` 起该 runaway query 被判定的次数。 + - `match_type` 表示 runaway query 的判定方式。可选值如下： + - `identify` 表示匹配 runaway query 的条件。 + - `watch` 表示匹配 watch 列表中的快速识别规则。 -+ `information_schema.runaway_watches` 表包含 runaway 查询的快速识别规则记录。更多信息请参见 [`RUNAWAY_WATCHES`](/information-schema/information-schema-runaway-watches.md)。 ++ `information_schema.runaway_watches` 表包含 runaway query 快速识别规则的记录。更多信息参见 [`RUNAWAY_WATCHES`](/information-schema/information-schema-runaway-watches.md)。 \ No newline at end of file diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index d8126f93930d8..0aa9be3c0c5b3 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -1,11 +1,11 @@ --- -title: 创建 TiFlash 副本 -summary: 了解如何创建 TiFlash 副本。 +title: Create TiFlash Replicas +summary: Learn how to create TiFlash replicas. --- # 创建 TiFlash 副本 -本文介绍如何为表和数据库创建 TiFlash 副本，以及如何为副本调度设置可用区。 +本文介绍如何为表和数据库创建 TiFlash 副本，并设置可用区以进行副本调度。 ## 为表创建 TiFlash 副本 @@ -17,11 +17,11 @@ ALTER TABLE table_name SET TIFLASH REPLICA count; 上述命令的参数说明如下： -- `count` 表示副本数量。当该值为 `0` 时，表示删除副本。 +- `count` 表示副本数量。当值为 `0` 时，表示删除副本。 > **Note:** > -> 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 集群，TiFlash 副本的 `count` 只能为 `2`。如果你设置为 `1`，会自动调整为 `2` 执行。如果设置为大于 2 的数字，则会报副本数相关的错误。 +> 对于 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) 集群，TiFlash 副本的 `count` 只能为 `2`。如果你设置为 `1`，会自动调整为 `2` 执行。如果设置为大于 2 的数字，则会报副本数量的错误。 如果你对同一张表执行多条 DDL 语句，只有最后一条语句会生效。如下例所示，对表 `tpch50` 执行了两条 DDL 语句，但只有第二条（删除副本）生效。 @@ -51,16 +51,16 @@ ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 0; * 建议不要同步超过 1,000 张表，否则会降低 PD 调度性能。该限制将在后续版本中移除。 -* 在 v5.1 及之后的版本中，不再支持为系统表设置副本。在升级集群前，你需要清除相关系统表的副本。否则，升级到新版本后将无法修改系统表的副本设置。 +* 在 v5.1 及更高版本中，不再支持为系统表设置副本。在升级集群前，你需要清除相关系统表的副本。否则，升级集群后将无法修改系统表的副本设置。 -* 当前，使用 TiCDC 将表同步到下游 TiDB 集群时，不支持为表创建 TiFlash 副本，即 TiCDC 不支持同步与 TiFlash 相关的 DDL 语句，例如： +* 当前，使用 TiCDC 将表同步到下游 TiDB 集群时，不支持为这些表创建 TiFlash 副本，即 TiCDC 不支持同步与 TiFlash 相关的 DDL 语句，例如： * `ALTER TABLE table_name SET TIFLASH REPLICA count;` * `ALTER DATABASE db_name SET TIFLASH REPLICA count;` ### 查看同步进度 -你可以使用以下语句查看指定表的 TiFlash 副本状态。通过 `WHERE` 子句指定表名。如果去掉 `WHERE` 子句，则会查看所有表的副本状态。 +你可以使用以下语句查看指定表的 TiFlash 副本状态。表通过 `WHERE` 子句指定。如果去掉 `WHERE` 子句，则会查看所有表的副本状态。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '' and TABLE_NAME = ''; @@ -97,9 +97,9 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; > **Note:** > -> - 该语句实际会执行一系列 DDL 操作，资源消耗较大。如果执行过程中被中断，已执行的操作不会回滚，未执行的操作也不会继续。 +> - 该语句实际会执行一系列 DDL 操作，资源消耗较大。如果执行过程中被中断，已执行的操作不会回滚，未执行的操作也不会继续执行。 > -> - 执行该语句后，在**所有表都同步完成之前**，不要再设置 TiFlash 副本数量或对该数据库执行 DDL 操作。否则可能出现以下异常情况： +> - 执行该语句后，在**所有表都同步完成之前**，不要再设置 TiFlash 副本数量或对该数据库执行 DDL 操作。否则，可能会出现以下异常情况： > - 如果你将 TiFlash 副本数设置为 2，但在所有表同步完成前又改为 1，则最终所有表的 TiFlash 副本数不一定是 1 或 2。 > - 执行该语句后，如果在语句执行完成前在该数据库中创建新表，这些新表**可能会**也可能不会被创建 TiFlash 副本。 > - 执行该语句后，如果在语句执行完成前为数据库中的表添加索引，语句可能会卡住，直到索引添加完成后才会继续。 @@ -108,7 +108,7 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; > > - 该语句会跳过系统表、视图、临时表以及 TiFlash 不支持字符集的表。 -> - 你可以通过设置 [`tidb_batch_pending_tiflash_count`](/system-variables.md#tidb_batch_pending_tiflash_count-new-in-v60) 系统变量，控制执行过程中允许处于不可用状态的表的数量。降低该值有助于减少同步过程对集群的压力。需要注意的是，该限制并非实时生效，因此设置后仍有可能出现不可用表数量超过限制的情况。 +> - 你可以通过设置 [`tidb_batch_pending_tiflash_count`](/system-variables.md#tidb_batch_pending_tiflash_count-new-in-v60) 系统变量，控制执行过程中允许处于不可用状态的表的数量。降低该值有助于减少同步过程对集群的压力。需要注意的是，该限制并非实时生效，因此在设置后，不可用表的数量仍有可能超过限制。 ### 查看同步进度 @@ -118,13 +118,13 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ''; ``` -如需查看数据库中未创建 TiFlash 副本的表，可以执行以下 SQL 语句： +要查看数据库中没有 TiFlash 副本的表，可以执行以下 SQL 语句： ```sql SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = "" and TABLE_NAME not in (SELECT TABLE_NAME FROM information_schema.tiflash_replica where TABLE_SCHEMA = ""); ``` -## 加速 TiFlash 副本同步 +## 加速 TiFlash 同步 @@ -134,17 +134,17 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " -当你执行以下任一操作时，TiDB 集群会触发 TiFlash 副本的同步流程： +当你执行以下任一操作时，TiDB 集群会触发 TiFlash 副本的同步过程： * 为表添加 TiFlash 副本。 * 新增 TiFlash 实例，导致 PD 将 TiFlash 副本从原有实例调度到新 TiFlash 实例。 -在此过程中，每个 TiKV 实例会对全表进行扫描，并将扫描到的数据快照发送给 TiFlash 以创建副本。默认情况下，为了尽量减少对 TiKV 和 TiFlash 生产负载的影响，TiFlash 以较慢的速度添加副本，并使用较少的资源。如果你的 TiKV 和 TiFlash 节点有充足的 CPU 和磁盘 I/O 资源，可以通过以下步骤加速 TiFlash 副本同步。 +在此过程中，每个 TiKV 实例会对全表进行扫描，并将扫描到的数据快照发送到 TiFlash 以创建副本。默认情况下，为了尽量减少对 TiKV 和 TiFlash 生产负载的影响，TiFlash 以较慢的速度添加副本，并使用较少的资源。如果你的 TiKV 和 TiFlash 节点有充足的 CPU 和磁盘 I/O 资源，可以通过以下步骤加速 TiFlash 同步。 -1. 通过 [动态配置 SQL 语句](https://docs.pingcap.com/tidb/stable/dynamic-config) 临时提升每个 TiKV 和 TiFlash 实例的快照写入速度上限： +1. 通过 [Dynamic Config SQL 语句](https://docs.pingcap.com/tidb/stable/dynamic-config) 临时提升每个 TiKV 和 TiFlash 实例的快照写入速度上限： ```sql - -- 这两个配置的默认值均为 100MiB，即写入快照的最大磁盘带宽不超过 100MiB/s。 + -- 两项配置的默认值均为 100MiB，即写入快照的最大磁盘带宽不超过 100MiB/s。 SET CONFIG tikv `server.snap-io-max-bytes-per-sec` = '300MiB'; SET CONFIG tiflash `raftstore-proxy.server.snap-io-max-bytes-per-sec` = '300MiB'; ``` @@ -159,13 +159,13 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " tiup ctl:v pd -u http://:2379 store limit all engine tiflash 60 add-peer ``` - > 在上述命令中，需要将 `v` 替换为实际的集群版本，如 `v8.5.3`，将 `:2379` 替换为任意 PD 节点的地址。例如： + > 在上述命令中，需要将 `v` 替换为实际集群版本，如 `v8.5.3`，将 `:2379` 替换为任意 PD 节点的地址。例如： > > ```shell > tiup ctl:v8.5.3 pd -u http://192.168.1.4:2379 store limit all engine tiflash 60 add-peer > ``` - 如果集群中旧 TiFlash 节点上有大量 Region，PD 需要将它们重新平衡到新 TiFlash 节点。你需要相应地调整 `remove-peer` 限制。 + 如果集群中旧 TiFlash 节点上有大量 Region，PD 需要将它们重新平衡到新 TiFlash 节点。你需要相应调整 `remove-peer` 限制。 ```shell tiup ctl:v pd -u http://:2379 store limit all engine tiflash 60 remove-peer @@ -173,14 +173,14 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " 几分钟后，你会观察到 TiFlash 节点的 CPU 和磁盘 IO 资源使用率明显上升，TiFlash 副本同步速度加快。同时，TiKV 节点的 CPU 和磁盘 IO 资源使用率也会提升。 - 如果此时 TiKV 和 TiFlash 节点仍有剩余资源，且你的在线业务延迟没有明显增加，可以进一步放宽限制，例如将速度提升至原来的三倍： + 如果此时 TiKV 和 TiFlash 节点仍有剩余资源，且你的在线服务延迟没有明显增加，可以进一步放宽限制，例如将速度提升至原来的三倍： ```shell tiup ctl:v pd -u http://:2379 store limit all engine tiflash 90 add-peer tiup ctl:v pd -u http://:2379 store limit all engine tiflash 90 remove-peer ``` -3. TiFlash 副本同步完成后，恢复默认配置以减少对在线业务的影响。 +3. TiFlash 同步完成后，恢复默认配置以减少对在线服务的影响。 执行以下 PD Control 命令，恢复副本调度速度的默认限制： @@ -208,7 +208,7 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " 在配置副本时，如果你需要将 TiFlash 副本分布到多个数据中心以实现容灾，可以按照以下步骤配置可用区： -1. 在集群配置文件中为 TiFlash 节点指定 label。 +1. 在集群配置文件中为 TiFlash 节点指定 labels。 ``` tiflash_servers: @@ -231,7 +231,7 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " zone: "z2" ``` - 需要注意，早期版本中的 `flash.proxy.labels` 配置无法正确处理可用区名称中的特殊字符。建议使用 `learner_config` 下的 `server.labels` 配置可用区名称。 + 需要注意，早期版本中的 `flash.proxy.labels` 配置无法正确处理可用区名称中的特殊字符，建议使用 `learner_config` 下的 `server.labels` 配置可用区名称。 2. 启动集群后，指定 TiFlash 副本数量以实现高可用。语法如下： @@ -245,7 +245,7 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " ALTER TABLE t SET TIFLASH REPLICA 2; ``` -3. PD 会根据 TiFlash 节点 `learner_config` 中的 `server.labels` 以及表副本的数量（`count`），将表 `t` 的副本调度到不同的可用区，以保证可用性。更多信息可参考 [通过拓扑标签调度副本](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels/)。你可以使用以下 SQL 语句，验证某张表的 Region 在 TiFlash 节点上的分布情况： +3. PD 会根据 TiFlash 节点 `learner_config` 中的 `server.labels` 以及表副本数量（`count`），将表 `t` 的副本调度到不同的可用区，以保证可用性。更多信息可参考 [Schedule Replicas by Topology Labels](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels/)。你可以使用以下 SQL 语句，验证某张表的 Region 在 TiFlash 节点上的分布情况： ```sql -- 非分区表 @@ -281,12 +281,12 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " -关于使用 label 调度副本的更多信息，参见 [通过拓扑标签调度副本](/schedule-replicas-by-topology-labels.md)、[同城多数据中心部署](/multi-data-centers-in-one-city-deployment.md) 和 [两地三中心部署](/three-data-centers-in-two-cities-deployment.md)。 +关于使用 labels 调度副本的更多信息，请参见 [Schedule Replicas by Topology Labels](/schedule-replicas-by-topology-labels.md)、[同城多数据中心部署](/multi-data-centers-in-one-city-deployment.md) 和 [两地三中心部署](/three-data-centers-in-two-cities-deployment.md)。 -TiFlash 支持为不同可用区配置副本选择策略。更多信息，参见 [`tiflash_replica_read`](/system-variables.md#tiflash_replica_read-new-in-v730)。 +TiFlash 支持为不同可用区配置副本选择策略。更多信息请参见 [`tiflash_replica_read`](/system-variables.md#tiflash_replica_read-new-in-v730)。 > **Note:** > -> 在语法 `ALTER TABLE table_name SET TIFLASH REPLICA count LOCATION LABELS location_labels;` 中，如果你为 `location_labels` 指定了多个 label，TiDB 无法正确解析并设置 placement rule。因此，不要使用 `LOCATION LABELS` 配置 TiFlash 副本。 \ No newline at end of file +> 在语法 `ALTER TABLE table_name SET TIFLASH REPLICA count LOCATION LABELS location_labels;` 中，如果你为 `location_labels` 指定了多个 label，TiDB 无法正确解析并设置 placement rules。因此，不要使用 `LOCATION LABELS` 配置 TiFlash 副本。 \ No newline at end of file diff --git a/vector-search/vector-search-data-types.md b/vector-search/vector-search-data-types.md index 471930bb9f3fc..b4c73709be2c7 100644 --- a/vector-search/vector-search-data-types.md +++ b/vector-search/vector-search-data-types.md @@ -3,15 +3,15 @@ title: Vector Data Types summary: 了解 TiDB 中的 Vector 数据类型。 --- -# Vector Data Types +# Vector 数据类型 -向量是浮点数的序列，例如 `[0.3, 0.5, -0.1, ...]`。TiDB 提供了专门优化的 Vector 数据类型，旨在高效存储和查询广泛应用于 AI 领域的向量嵌入。 +向量（vector）是一组浮点数的序列，例如 `[0.3, 0.5, -0.1, ...]`。TiDB 提供了 Vector 数据类型，专门针对高效存储和查询在 AI 应用中广泛使用的向量嵌入进行了优化。 > **Warning:** > -> 该功能处于实验阶段。不建议在生产环境中使用。此功能可能会在不提前通知的情况下进行更改。如发现 bug，可以在 [issue](https://github.com/pingcap/tidb/issues) 上向 GitHub 报告。 +> 此功能为实验性功能。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,28 +19,28 @@ summary: 了解 TiDB 中的 Vector 数据类型。 > **Note:** > -> 该功能处于测试版，可能会在不提前通知的情况下进行更改。如发现 bug，可以在 [issue](https://github.com/pingcap/tidb/issues) 上向 GitHub 报告。 +> 此功能为 Beta 版本，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> Vector 数据类型在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可使用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 及以上（建议使用 v8.5.0 及以上）。 +> Vector 数据类型可用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 -目前可用的 Vector 数据类型如下： +目前支持以下 Vector 数据类型： - `VECTOR`：任意维度的单精度浮点数序列。 - `VECTOR(D)`：固定维度 `D` 的单精度浮点数序列。 -使用向量数据类型相较于 [`JSON`](/data-type-json.md) 类型具有以下优势： +与使用 [`JSON`](/data-type-json.md) 类型相比，使用 Vector 数据类型具有以下优势： -- 向量索引支持：可以构建 [向量搜索索引](/vector-search/vector-search-index.md) 来加快向量搜索速度。 -- 维度强制：可以指定维度，禁止插入不同维度的向量。 -- 优化存储格式：向量数据类型针对向量数据进行了优化，提供比 `JSON` 类型更好的空间效率和性能。 +- 支持向量索引：你可以构建 [向量检索索引](/vector-search/vector-search-index.md) 来加速向量检索。 +- 维度约束：你可以指定维度，禁止插入不同维度的向量。 +- 优化的存储格式：Vector 数据类型针对向量数据进行了优化，提供比 `JSON` 类型更好的空间效率和性能。 ## 语法 -你可以使用以下语法的字符串来表示一个 Vector 值： +你可以使用如下语法的字符串来表示一个 Vector 值： ```sql '[, , ...]' @@ -59,27 +59,27 @@ INSERT INTO vector_table VALUES (1, '[0.3, 0.5, -0.1]'); INSERT INTO vector_table VALUES (2, NULL); ``` -插入格式不正确的向量值会导致错误： +插入语法不合法的向量值会导致报错： ```sql [tidb]> INSERT INTO vector_table VALUES (3, '[5, ]'); ERROR 1105 (HY000): Invalid vector text: [5, ] ``` -在以下示例中，由于在创建表时对 `embedding` 列强制维度为 `3`，插入不同维度的向量会导致错误： +在下例中，由于在建表时为 `embedding` 列指定了维度 `3`，插入不同维度的向量会报错： ```sql [tidb]> INSERT INTO vector_table VALUES (4, '[0.3, 0.5]'); ERROR 1105 (HY000): vector has 2 dimensions, does not fit VECTOR(3) ``` -关于向量数据类型的函数和操作符，请参见 [Vector Functions and Operators](/vector-search/vector-search-functions-and-operators.md)。 +关于 Vector 数据类型可用的函数和操作符，参见 [Vector Functions and Operators](/vector-search/vector-search-functions-and-operators.md)。 -关于构建和使用向量搜索索引的更多信息，请参见 [Vector Search Index](/vector-search/vector-search-index.md)。 +关于如何构建和使用向量检索索引，参见 [Vector Search Index](/vector-search/vector-search-index.md)。 ## 存储不同维度的向量 -你可以通过省略 `VECTOR` 类型中的维度参数，在同一列中存储不同维度的向量： +你可以通过在 `VECTOR` 类型中省略维度参数，在同一列中存储不同维度的向量： ```sql CREATE TABLE vector_table ( @@ -91,32 +91,32 @@ INSERT INTO vector_table VALUES (1, '[0.3, 0.5, -0.1]'); -- 3 维向量，OK INSERT INTO vector_table VALUES (2, '[0.3, 0.5]'); -- 2 维向量，OK ``` -但请注意，不能为此列构建 [向量搜索索引](/vector-search/vector-search-index.md)，因为只能在维度相同的向量之间计算距离。 +但需要注意的是，你无法为该列构建 [向量检索索引](/vector-search/vector-search-index.md)，因为只有相同维度的向量之间才能计算向量距离。 ## 比较 -你可以使用 [comparison operators](/functions-and-operators/operators.md)（如 `=`, `!=`, `<`, `>`, `<=`, 和 `>=`）对向量数据类型进行比较。关于向量数据类型的完整比较操作符和函数列表，请参见 [Vector Functions and Operators](/vector-search/vector-search-functions-and-operators.md)。 +你可以使用 [比较操作符](/functions-and-operators/operators.md)（如 `=`, `!=`, `<`, `>`, `<=`, `>=`）对 Vector 数据类型进行比较。关于 Vector 数据类型的完整比较操作符和函数列表，参见 [Vector Functions and Operators](/vector-search/vector-search-functions-and-operators.md)。 -向量数据类型的比较是逐元素数值比较。例如： +Vector 数据类型按元素逐一进行数值比较。例如： - `[1] < [12]` - `[1,2,3] < [1,2,5]` - `[1,2,3] = [1,2,3]` - `[2,2,3] > [1,2,3]` -不同维度的两个向量采用字典序比较，规则如下： +对于不同维度的两个向量，采用字典序比较，规则如下： -- 从第一个元素开始逐个元素比较，每个元素按数值比较。 -- 第一个不匹配的元素决定哪个向量在字典序上 _更小_ 或 _更大_。 +- 两个向量从头开始逐元素比较，每个元素按数值比较。 +- 第一个不相等的元素决定哪个向量在字典序上 _更小_ 或 _更大_。 - 如果一个向量是另一个向量的前缀，则较短的向量在字典序上 _更小_。例如，`[1,2,3] < [1,2,3,0]`。 -- 长度相同且元素相同的两个向量在字典序上 _相等_。 +- 长度相同且元素完全相同的两个向量在字典序上 _相等_。 - 空向量在字典序上 _小于_ 任何非空向量。例如，`[] < [1]`。 - 两个空向量在字典序上 _相等_。 -在比较向量常量时，建议先进行 [显式类型转换](#cast)，避免基于字符串值的比较： +在比较向量常量时，建议进行 [显式类型转换](#cast)，将字符串转换为向量，以避免基于字符串值的比较： ```sql --- 由于给定的是字符串，TiDB 会比较字符串： +-- 由于传入的是字符串，TiDB 按字符串进行比较： [tidb]> SELECT '[12.0]' < '[4.0]'; +--------------------+ | '[12.0]' < '[4.0]' | @@ -125,7 +125,7 @@ INSERT INTO vector_table VALUES (2, '[0.3, 0.5]'); -- 2 维向量，OK +--------------------+ 1 row in set (0.01 sec) --- 显式转换为向量后按向量比较： +-- 显式转换为向量后按向量数值比较： [tidb]> SELECT VEC_FROM_TEXT('[12.0]') < VEC_FROM_TEXT('[4.0]'); +--------------------------------------------------+ | VEC_FROM_TEXT('[12.0]') < VEC_FROM_TEXT('[4.0]') | @@ -135,9 +135,9 @@ INSERT INTO vector_table VALUES (2, '[0.3, 0.5]'); -- 2 维向量，OK 1 row in set (0.01 sec) ``` -## 算术操作 +## 算术运算 -向量数据类型支持 `+`（加法）和 `-`（减法）算术操作。但不同维度的向量之间的算术运算不支持，执行会报错。 +Vector 数据类型支持 `+`（加法）和 `-`（减法）算术运算。但不支持不同维度的向量之间进行算术运算，否则会报错。 示例： @@ -166,14 +166,14 @@ ERROR 1105 (HY000): vectors have different dimensions: 1 and 3 ### Vector ⇔ String 之间的转换 -使用以下函数可以在 Vector 和 String 之间进行转换： +要在 Vector 和 String 之间进行类型转换，可以使用以下函数： -- `CAST(... AS VECTOR)`：字符串 ⇒ 向量 -- `CAST(... AS CHAR)`：向量 ⇒ 字符串 -- `VEC_FROM_TEXT`：字符串 ⇒ 向量 -- `VEC_AS_TEXT`：向量 ⇒ 字符串 +- `CAST(... AS VECTOR)`：String ⇒ Vector +- `CAST(... AS CHAR)`：Vector ⇒ String +- `VEC_FROM_TEXT`：String ⇒ Vector +- `VEC_AS_TEXT`：Vector ⇒ String -为了提升易用性，如果调用只支持向量数据类型的函数（如向量相关的距离函数），你也可以直接传入符合格式的字符串，TiDB 会自动进行隐式类型转换。 +为提升易用性，如果你调用的函数只支持 Vector 数据类型（如向量相关距离函数），也可以直接传入符合格式的字符串。此时 TiDB 会自动进行隐式类型转换。 ```sql -- VEC_DIMS 函数只接受 VECTOR 参数，因此可以直接传入字符串进行隐式转换。 @@ -185,7 +185,7 @@ ERROR 1105 (HY000): vectors have different dimensions: 1 and 3 +------------------------------+ 1 row in set (0.01 sec) --- 也可以显式将字符串转换为向量，再传入 VEC_DIMS： +-- 你也可以显式使用 VEC_FROM_TEXT 将字符串转换为向量，再传递给 VEC_DIMS 函数。 [tidb]> SELECT VEC_DIMS(VEC_FROM_TEXT('[0.3, 0.5, -0.1]')); +---------------------------------------------+ | VEC_DIMS(VEC_FROM_TEXT('[0.3, 0.5, -0.1]')) | @@ -204,10 +204,10 @@ ERROR 1105 (HY000): vectors have different dimensions: 1 and 3 1 row in set (0.01 sec) ``` -在使用支持多类型的操作符或函数时，必须先显式将字符串类型转换为向量类型，然后再传入字符串，否则 TiDB 不会进行隐式转换。例如，在进行比较操作前，必须显式将字符串转换为向量，否则会按字符串值进行比较，而非数值向量。 +当你使用接受多种数据类型的操作符或函数时，需要在将字符串传递给该操作符或函数前，显式将字符串类型转换为向量类型，因为此时 TiDB 不会进行隐式类型转换。例如，在进行比较操作前，需要显式将字符串转换为向量，否则 TiDB 会按字符串值进行比较，而不是按向量数值进行比较： ```sql --- 由于给定的是字符串，TiDB 会比较字符串： +-- 由于传入的是字符串，TiDB 按字符串进行比较： [tidb]> SELECT '[12.0]' < '[4.0]'; +--------------------+ | '[12.0]' < '[4.0]' | @@ -216,7 +216,7 @@ ERROR 1105 (HY000): vectors have different dimensions: 1 and 3 +--------------------+ 1 row in set (0.01 sec) --- 显式转换为向量后按向量比较： +-- 显式转换为向量后按向量数值比较： [tidb]> SELECT VEC_FROM_TEXT('[12.0]') < VEC_FROM_TEXT('[4.0]'); +--------------------------------------------------+ | VEC_FROM_TEXT('[12.0]') < VEC_FROM_TEXT('[4.0]') | @@ -226,10 +226,10 @@ ERROR 1105 (HY000): vectors have different dimensions: 1 and 3 1 row in set (0.01 sec) ``` -你也可以显式将向量转换为字符串，例如使用 `VEC_AS_TEXT()` 函数： +你也可以将向量显式转换为其字符串表示。例如，使用 `VEC_AS_TEXT()` 函数： ```sql --- 字符串先隐式转换为向量，然后再显式转换为字符串，返回标准格式的字符串： +-- 字符串首先被隐式转换为向量，然后向量被显式转换为字符串，最终返回规范化格式的字符串： [tidb]> SELECT VEC_AS_TEXT('[0.3, 0.5, -0.1]'); +--------------------------------------+ | VEC_AS_TEXT('[0.3, 0.5, -0.1]') | @@ -239,24 +239,24 @@ ERROR 1105 (HY000): vectors have different dimensions: 1 and 3 1 row in set (0.01 sec) ``` -关于其他的类型转换函数，请参见 [Vector Functions and Operators](/vector-search/vector-search-functions-and-operators.md)。 +更多类型转换函数，参见 [Vector Functions and Operators](/vector-search/vector-search-functions-and-operators.md)。 ### Vector ⇔ 其他数据类型之间的转换 -目前，不支持直接在 Vector 和其他数据类型（如 `JSON`）之间进行转换。可以在 SQL 语句中使用 String 作为中间类型进行转换。 +目前不支持 Vector 与其他数据类型（如 `JSON`）之间的直接类型转换。你可以在 SQL 语句中通过 String 作为中间类型进行转换来规避此限制。 -注意，存储在表中的向量数据类型列不能通过 `ALTER TABLE ... MODIFY COLUMN ...` 转换为其他数据类型。 +需要注意的是，表中存储的 Vector 类型列无法通过 `ALTER TABLE ... MODIFY COLUMN ...` 转换为其他数据类型。 ## 限制 -关于向量数据类型的限制，请参见 [Vector search limitations](/vector-search/vector-search-limitations.md) 和 [Vector index restrictions](/vector-search/vector-search-index.md#restrictions)。 +关于 Vector 数据类型的限制，参见 [向量检索限制](/vector-search/vector-search-limitations.md) 和 [向量索引限制](/vector-search/vector-search-index.md#restrictions)。 ## MySQL 兼容性 -向量数据类型为 TiDB 特有，不支持在 MySQL 中使用。 +Vector 数据类型为 TiDB 特有，MySQL 不支持。 -## 相关链接 +## 参见 - [Vector Functions and Operators](/vector-search/vector-search-functions-and-operators.md) - [Vector Search Index](/vector-search/vector-search-index.md) -- [Improve Vector Search Performance](/vector-search/vector-search-improve-performance.md) \ No newline at end of file +- [提升向量检索性能](/vector-search/vector-search-improve-performance.md) diff --git a/vector-search/vector-search-functions-and-operators.md b/vector-search/vector-search-functions-and-operators.md index 14cec85dbf4d6..544bc459508ba 100644 --- a/vector-search/vector-search-functions-and-operators.md +++ b/vector-search/vector-search-functions-and-operators.md @@ -19,46 +19,46 @@ summary: 了解可用于向量数据类型的函数与运算符。 > **Note:** > -> 此功能处于 Beta 阶段，可能会在未提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 此功能处于 beta 阶段，可能会在未提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 向量数据类型及这些向量函数可用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 +> 向量数据类型及这些向量函数可用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 ## 向量函数 -以下函数专为 [向量数据类型](/vector-search/vector-search-data-types.md) 设计。 +以下函数专为[向量数据类型](/vector-search/vector-search-data-types.md)设计。 **向量距离函数：** -| 函数名 | 描述 | [向量索引](/vector-search/vector-search-index.md#vector-search-index) 支持 | -| ---------------------------------------------------- | --------------------------------------------------------- |---------------------------| -| [`VEC_L2_DISTANCE`](#vec_l2_distance) | 计算两个向量之间的 L2 距离（欧氏距离） | 是 | -| [`VEC_COSINE_DISTANCE`](#vec_cosine_distance) | 计算两个向量之间的余弦距离 | 是 | -| [`VEC_NEGATIVE_INNER_PRODUCT`](#vec_negative_inner_product) | 计算两个向量内积的相反数 | 否 | -| [`VEC_L1_DISTANCE`](#vec_l1_distance) | 计算两个向量之间的 L1 距离（曼哈顿距离） | 否 | +| 函数名 | 描述 | [向量索引](/vector-search/vector-search-index.md#vector-search-index)支持 | +| ---------------------------------------------------- | --------------------------------------------------------- | --------------------------- | +| [`VEC_L2_DISTANCE`](#vec_l2_distance) | 计算两个向量之间的 L2 距离（欧氏距离） | 是 | +| [`VEC_COSINE_DISTANCE`](#vec_cosine_distance) | 计算两个向量之间的余弦距离 | 是 | +| [`VEC_NEGATIVE_INNER_PRODUCT`](#vec_negative_inner_product) | 计算两个向量内积的相反数 | 否 | +| [`VEC_L1_DISTANCE`](#vec_l1_distance) | 计算两个向量之间的 L1 距离（曼哈顿距离） | 否 | **其他向量函数：** | 函数名 | 描述 | | ----------------------------- | -------------------------------------------- | | [`VEC_DIMS`](#vec_dims) | 返回向量的维度 | -| [`VEC_L2_NORM`](#vec_l2_norm) | 计算向量的 L2 范数（欧氏范数） | +| [`VEC_L2_NORM`](#vec_l2_norm) | 计算向量的 L2 范数（欧氏范数） | | [`VEC_FROM_TEXT`](#vec_from_text) | 将字符串转换为向量 | | [`VEC_AS_TEXT`](#vec_as_text) | 将向量转换为字符串 | ## 扩展的内置函数与运算符 -以下内置函数与运算符已扩展以支持对 [向量数据类型](/vector-search/vector-search-data-types.md) 的操作。 +以下内置函数与运算符已扩展以支持对[向量数据类型](/vector-search/vector-search-data-types.md)的操作。 **算术运算符：** | 名称 | 描述 | | :------------------------------------------------------------------------------------- | :------------------------------- | -| [`+`](https://dev.mysql.com/doc/refman/8.0/en/arithmetic-functions.html#operator_plus) | 向量按元素加法运算符 | -| [`-`](https://dev.mysql.com/doc/refman/8.0/en/arithmetic-functions.html#operator_minus) | 向量按元素减法运算符 | +| [`+`](https://dev.mysql.com/doc/refman/8.0/en/arithmetic-functions.html#operator_plus) | 向量按元素加法运算符 | +| [`-`](https://dev.mysql.com/doc/refman/8.0/en/arithmetic-functions.html#operator_minus) | 向量按元素减法运算符 | 关于向量算术的更多信息，参见 [向量数据类型 | 算术运算](/vector-search/vector-search-data-types.md#arithmetic)。 @@ -66,16 +66,16 @@ summary: 了解可用于向量数据类型的函数与运算符。 | 名称 | 描述 | | :----------------------- | :---------------------------------------- | -| [`COUNT()`](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_count) | 返回结果行数的计数 | -| [`COUNT(DISTINCT)`](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_count-distinct) | 返回不同值的计数 | -| [`MAX()`](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_max) | 返回最大值 | -| [`MIN()`](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_min) | 返回最小值 | +| [`COUNT()`](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_count) | 返回结果行数 | +| [`COUNT(DISTINCT)`](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_count-distinct) | 返回不同值的数量 | +| [`MAX()`](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_max) | 返回最大值 | +| [`MIN()`](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_min) | 返回最小值 | **比较函数与运算符：** | 名称 | 描述 | | ---------------------------------------- | ---------------------------------------------- | -| [`BETWEEN ... AND ...`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_between) | 检查值是否在某个范围内 | +| [`BETWEEN ... AND ...`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_between) | 检查值是否在某个范围内 | | [`COALESCE()`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#function_coalesce) | 返回第一个非 NULL 的参数 | | [`=`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_equal) | 等于运算符 | | [`<=>`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_equal-to) | NULL 安全等于运算符 | @@ -83,8 +83,8 @@ summary: 了解可用于向量数据类型的函数与运算符。 | [`>=`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_greater-than-or-equal) | 大于等于运算符 | | [`GREATEST()`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#function_greatest) | 返回最大参数 | | [`IN()`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_in) | 检查值是否在某个集合中 | -| [`IS NULL`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_is-null) | 判断值是否为 `NULL` | -| [`ISNULL()`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#function_isnull) | 判断参数是否为 `NULL` | +| [`IS NULL`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_is-null) | 检查值是否为 `NULL` | +| [`ISNULL()`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#function_isnull) | 检查参数是否为 `NULL` | | [`LEAST()`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#function_least) | 返回最小参数 | | [`<`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_less-than) | 小于运算符 | | [`<=`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_less-than-or-equal) | 小于等于运算符 | @@ -92,25 +92,25 @@ summary: 了解可用于向量数据类型的函数与运算符。 | [`!=`, `<>`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_not-equal) | 不等于运算符 | | [`NOT IN()`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_not-in) | 检查值是否不在某个集合中 | -关于向量如何进行比较的更多信息，参见 [向量数据类型 | 比较](/vector-search/vector-search-data-types.md#comparison)。 +关于向量比较的更多信息，参见 [向量数据类型 | 比较运算](/vector-search/vector-search-data-types.md#comparison)。 **流程控制函数：** | 名称 | 描述 | -| :------------------------------------------------------------------------------------------------ | :-------------------- | -| [`CASE`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#operator_case) | CASE 运算符 | -| [`IF()`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_if) | IF/ELSE 结构 | -| [`IFNULL()`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_ifnull) | NULL IF/ELSE 结构 | +| :------------------------------------------------------------------------------------------------ | :------------------- | +| [`CASE`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#operator_case) | CASE 运算符 | +| [`IF()`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_if) | IF/ELSE 结构 | +| [`IFNULL()`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_ifnull) | NULL IF/ELSE 结构 | | [`NULLIF()`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_nullif) | 如果 expr1 = expr2 则返回 `NULL` | **类型转换函数：** | 名称 | 描述 | -| :------------------------------------------------------------------------------------------ | :-------------------------- | +| :------------------------------------------------------------------------------------------ | :------------------------- | | [`CAST()`](https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html#function_cast) | 将值转换为字符串或向量 | | [`CONVERT()`](https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html#function_convert) | 将值转换为字符串 | -关于如何使用 `CAST()` 的更多信息，参见 [向量数据类型 | 类型转换](/vector-search/vector-search-data-types.md#cast)。 +关于如何使用 `CAST()`，参见 [向量数据类型 | 类型转换](/vector-search/vector-search-data-types.md#cast)。 ## 完整参考 @@ -146,13 +146,13 @@ SELECT VEC_L2_DISTANCE('[0, 3]', '[4, 0]'); VEC_COSINE_DISTANCE(vector1, vector2) ``` -使用以下公式计算两个向量之间的 [余弦距离](https://en.wikipedia.org/wiki/Cosine_similarity)： +使用以下公式计算两个向量之间的[余弦距离](https://en.wikipedia.org/wiki/Cosine_similarity)： $DISTANCE(p,q)=1.0 - {\frac {\sum \limits _{i=1}^{n}{p_{i}q_{i}}}{{\sqrt {\sum \limits _{i=1}^{n}{p_{i}^{2}}}}\cdot {\sqrt {\sum \limits _{i=1}^{n}{q_{i}^{2}}}}}}$ 两个向量必须具有相同的维度，否则会返回错误。 -对于来自 OpenAI 的嵌入，建议[使用此函数](https://help.openai.com/en/articles/6824809-embeddings-faq)。 +对于来自 OpenAI 的嵌入，建议你[使用此函数](https://help.openai.com/en/articles/6824809-embeddings-faq)。 示例： @@ -174,7 +174,7 @@ SELECT VEC_COSINE_DISTANCE('[1, 1]', '[-1, -1]'); VEC_NEGATIVE_INNER_PRODUCT(vector1, vector2) ``` -使用以下公式，通过计算两个向量 [内积](https://en.wikipedia.org/wiki/Dot_product) 的相反数来计算距离： +使用以下公式，通过计算两个向量[内积](https://en.wikipedia.org/wiki/Dot_product)的相反数来计算距离： $DISTANCE(p,q)=- INNER\_PROD(p,q)=-\sum \limits _{i=1}^{n}{p_{i}q_{i}}$ @@ -284,7 +284,7 @@ SELECT VEC_L2_NORM('[3, 4]'); VEC_FROM_TEXT(string) ``` -将字符串转换为向量。在许多场景下，此转换会被隐式执行，例如向 `VECTOR` 数据类型的列插入数据时。然而，在某些表达式中（如向量的算术运算），如果不支持隐式转换，则需要显式调用此函数。 +将字符串转换为向量。在许多场景下，此转换会自动进行，例如向 `VECTOR` 数据类型的列插入数据时。然而，在某些表达式中（如向量的算术运算），如果不支持隐式转换，则需要显式调用此函数。 示例： diff --git a/vector-search/vector-search-get-started-using-python.md b/vector-search/vector-search-get-started-using-python.md index 59554e9d7dee1..3fb1a81aa2fa8 100644 --- a/vector-search/vector-search-get-started-using-python.md +++ b/vector-search/vector-search-get-started-using-python.md @@ -1,19 +1,19 @@ --- -title: 使用 Python 搭配 TiDB + AI 入门 -summary: 学习如何使用 Python 和 TiDB Vector Search 快速开发一个执行语义搜索的 AI 应用。 +title: 使用 Python 快速上手 TiDB + AI +summary: 学习如何使用 Python 和 TiDB 向量检索快速开发一个实现语义搜索的 AI 应用。 --- -# 使用 Python 搭配 TiDB + AI 入门 +# 使用 Python 快速上手 TiDB + AI -本教程演示如何开发一个提供 **semantic search** 功能的简单 AI 应用。与传统的关键词搜索不同，语义搜索能够智能理解你的查询背后的含义，并返回最相关的结果。例如，如果你有标题为 "dog"、"fish" 和 "tree" 的文档，当你搜索 "一只会游泳的动物" 时，应用会识别出 "fish" 是最相关的结果。 +本教程演示如何开发一个简单的 AI 应用，实现**语义搜索**功能。与传统的关键词搜索不同，语义搜索能够智能理解你的查询背后的含义，并返回最相关的结果。例如，如果你有标题为 "dog"、"fish" 和 "tree" 的文档，当你搜索 "a swimming animal" 时，应用会识别出 "fish" 是最相关的结果。 -在整个教程中，你将使用 [TiDB Vector Search](/vector-search/vector-search-overview.md)、Python、[TiDB Vector SDK for Python](https://github.com/pingcap/tidb-vector-python) 和 AI 模型来开发此应用。 +在本教程中，你将使用 [TiDB Vector Search](/vector-search/vector-search-overview.md)、Python、[TiDB Vector SDK for Python](https://github.com/pingcap/tidb-vector-python) 以及 AI 模型来开发这个 AI 应用。 > **Warning:** > -> 目前向量搜索功能处于实验阶段，不建议在生产环境中使用。此功能可能会在不提前通知的情况下进行更改。如发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能目前为实验性特性。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -21,46 +21,46 @@ summary: 学习如何使用 Python 和 TiDB Vector Search 快速开发一个执 > **Note:** > -> 目前向量搜索功能处于测试版，可能会在不提前通知的情况下进行更改。如发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能目前为 Beta 版本。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可使用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 及以上（建议使用 v8.5.0 及以上版本）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 -## 前提条件 +## 前置条件 完成本教程，你需要： -- 安装 [Python 3.8 或更高版本](https://www.python.org/downloads/) -- 安装 [Git](https://git-scm.com/downloads) -- 拥有一个 TiDB 集群 +- 已安装 [Python 3.8 或更高版本](https://www.python.org/downloads/)。 +- 已安装 [Git](https://git-scm.com/downloads)。 +- 一个 TiDB 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- 参考 [部署本地测试用 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产用 TiDB 集群](/production-deployment-using-tiup.md) 来创建本地集群。 -- 参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 +- 参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 -- 参考 [部署本地测试用 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产用 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 来创建版本为 v8.4.0 或更高版本的本地集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建 v8.4.0 或更高版本的本地集群。 -## 入门步骤 +## 快速开始 -以下步骤演示如何从零开始开发应用。若想直接运行示例，可以在 [pingcap/tidb-vector-python](https://github.com/pingcap/tidb-vector-python/blob/main/examples/python-client-quickstart) 仓库中查看示例代码。 +以下步骤展示了如何从零开发该应用。如果你想直接运行示例，可以在 [pingcap/tidb-vector-python](https://github.com/pingcap/tidb-vector-python/blob/main/examples/python-client-quickstart) 仓库中查看示例代码。 -### 步骤 1. 创建一个新的 Python 项目 +### 步骤 1. 创建新的 Python 项目 -在你偏好的目录下，创建一个新的 Python 项目和一个名为 `example.py` 的文件： +在你喜欢的目录下，创建一个新的 Python 项目，并新建一个名为 `example.py` 的文件： ```shell mkdir python-client-quickstart @@ -70,48 +70,48 @@ touch example.py ### 步骤 2. 安装所需依赖 -在你的项目目录下，运行以下命令安装所需的包： +在你的项目目录下，运行以下命令安装所需的依赖包： ```shell pip install sqlalchemy pymysql sentence-transformers tidb-vector python-dotenv ``` -- `tidb-vector`：用于与 TiDB 向量搜索交互的 Python 客户端。 -- [`sentence-transformers`](https://sbert.net)：提供预训练模型，用于从文本生成 [vector embeddings](/vector-search/vector-search-overview.md#vector-embedding)。 +- `tidb-vector`：用于与 TiDB 向量检索交互的 Python 客户端。 +- [`sentence-transformers`](https://sbert.net)：一个 Python 库，提供用于从文本生成[向量嵌入](/vector-search/vector-search-overview.md#vector-embedding)的预训练模型。 -### 步骤 3. 配置连接字符串到 TiDB 集群 +### 步骤 3. 配置 TiDB 集群连接字符串 根据你选择的 TiDB 部署方式，配置集群连接字符串。 -
+
-对于 {{{ .starter }}} 集群，按照以下步骤获取集群连接字符串并配置环境变量： +对于 TiDB Cloud Starter 集群，按以下步骤获取集群连接字符串并配置环境变量： -1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入概览页面。 +1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入集群概览页。 2. 点击右上角的 **Connect**，弹出连接对话框。 3. 确认连接对话框中的配置与你的操作环境一致。 - - **Connection Type** 设为 `Public`。 - - **Branch** 设为 `main`。 - - **Connect With** 设为 `SQLAlchemy`。 - - **Operating System** 与你的环境匹配。 + - **Connection Type** 设置为 `Public`。 + - **Branch** 设置为 `main`。 + - **Connect With** 设置为 `SQLAlchemy`。 + - **Operating System** 与你的环境一致。 > **Tip:** > - > 如果你的程序在 Windows Subsystem for Linux (WSL) 中运行，切换到对应的 Linux 发行版。 + > 如果你的程序运行在 Windows Subsystem for Linux (WSL) 中，请切换到对应的 Linux 发行版。 -4. 点击 **PyMySQL** 标签页，复制连接字符串。 +4. 点击 **PyMySQL** 标签页并复制连接字符串。 > **Tip:** > - > 如果还未设置密码，可以点击 **Generate Password** 生成随机密码。 + > 如果你还未设置密码，可以点击 **Generate Password** 生成随机密码。 -5. 在你的 Python 项目的根目录下，创建 `.env` 文件，并将连接字符串粘贴进去。 +5. 在你的 Python 项目根目录下创建 `.env` 文件，并将连接字符串粘贴进去。 - 下面是 macOS 的示例： + 以下是 macOS 的示例： ```dotenv TIDB_DATABASE_URL="mysql+pymysql://.root:@gateway01..prod.aws.tidbcloud.com:4000/test?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" @@ -120,22 +120,22 @@ pip install sqlalchemy pymysql sentence-transformers tidb-vector python-dotenv
-对于 TiDB Self-Managed 集群，在你的 Python 项目根目录下创建 `.env` 文件。将以下内容复制到 `.env` 文件中，并根据你的 TiDB 集群连接参数修改环境变量值： +对于 TiDB 自建集群，在你的 Python 项目根目录下创建 `.env` 文件。将以下内容复制到 `.env` 文件中，并根据你的 TiDB 集群连接参数修改环境变量的值： ```dotenv TIDB_DATABASE_URL="mysql+pymysql://:@:/" # 例如：TIDB_DATABASE_URL="mysql+pymysql://root@127.0.0.1:4000/test" ``` -如果你在本地运行 TiDB，`` 默认为 `127.0.0.1`。初次启动集群时，`` 为空，可以省略此字段。 +如果你在本地运行 TiDB，`` 默认为 `127.0.0.1`。初始 `` 为空，因此如果你是首次启动集群，可以省略该字段。 -以下是各参数的说明： +各参数说明如下： - ``：连接 TiDB 集群的用户名。 - ``：连接 TiDB 集群的密码。 - ``：TiDB 集群的主机地址。 -- ``：TiDB 集群的端口。 -- ``：你要连接的数据库名。 +- ``：TiDB 集群的端口号。 +- ``：你要连接的数据库名称。
@@ -143,9 +143,9 @@ TIDB_DATABASE_URL="mysql+pymysql://:@:/" ### 步骤 4. 初始化嵌入模型 -[embedding model](/vector-search/vector-search-overview.md#embedding-model) 将数据转换为 [vector embeddings](/vector-search/vector-search-overview.md#vector-embedding)。本示例使用预训练模型 [**msmarco-MiniLM-L12-cos-v5**](https://huggingface.co/sentence-transformers/msmarco-MiniLM-L12-cos-v5) 进行文本嵌入。该轻量级模型由 `sentence-transformers` 库提供，将文本数据转换为 384 维的向量嵌入。 +[嵌入模型](/vector-search/vector-search-overview.md#embedding-model)用于将数据转换为[向量嵌入](/vector-search/vector-search-overview.md#vector-embedding)。本示例使用预训练模型 [**msmarco-MiniLM-L12-cos-v5**](https://huggingface.co/sentence-transformers/msmarco-MiniLM-L12-cos-v5) 进行文本嵌入。该轻量级模型由 `sentence-transformers` 库提供，可将文本数据转换为 384 维的向量嵌入。 -将以下代码复制到 `example.py` 文件中，用于初始化 `SentenceTransformer` 实例，并定义一个 `text_to_embedding()` 函数供后续使用。 +要设置模型，将以下代码复制到 `example.py` 文件中。该代码初始化了一个 `SentenceTransformer` 实例，并定义了后续使用的 `text_to_embedding()` 函数。 ```python from sentence_transformers import SentenceTransformer @@ -155,18 +155,18 @@ embed_model = SentenceTransformer("sentence-transformers/msmarco-MiniLM-L12-cos- embed_model_dims = embed_model.get_sentence_embedding_dimension() def text_to_embedding(text): - """为给定文本生成向量嵌入。""" + """Generates vector embeddings for the given text.""" embedding = embed_model.encode(text) return embedding.tolist() ``` -### 步骤 5. 连接到 TiDB 集群 +### 步骤 5. 连接 TiDB 集群 -使用 `TiDBVectorClient` 类连接到你的 TiDB 集群，并创建一个名为 `embedded_documents` 的表，包含一个向量列。 +使用 `TiDBVectorClient` 类连接到你的 TiDB 集群，并创建一个带有向量列的 `embedded_documents` 表。 > **Note** > -> 确保表中的向量列维度与嵌入模型生成的向量维度一致。例如，`msmarco-MiniLM-L12-cos-v5` 模型生成的向量维度为 384，因此 `embedded_documents` 表中的向量列维度也应为 384。 +> 请确保表中向量列的维度与你的嵌入模型生成的向量维度一致。例如，**msmarco-MiniLM-L12-cos-v5** 模型生成的向量为 384 维，因此 `embedded_documents` 表中的向量列维度也应为 384。 ```python import os @@ -177,20 +177,20 @@ from dotenv import load_dotenv load_dotenv() vector_store = TiDBVectorClient( - # `embedded_documents` 表将存储向量数据。 + # 'embedded_documents' 表用于存储向量数据。 table_name='embedded_documents', - # 连接 TiDB 集群的连接字符串。 + # TiDB 集群的连接字符串。 connection_string=os.environ.get('TIDB_DATABASE_URL'), # 嵌入模型生成的向量维度。 vector_dimension=embed_model_dims, - # 如果表已存在，则重新创建。 + # 如果表已存在则重新创建。 drop_existing_table=True, ) ``` ### 步骤 6. 嵌入文本数据并存储向量 -在此步骤中，你将准备包含单词的示例文档，例如 "dog"、"fish" 和 "tree"。以下代码使用 `text_to_embedding()` 函数将这些文本转换为向量嵌入，然后插入到向量存储中。 +本步骤将准备包含单词的示例文档，如 "dog"、"fish" 和 "tree"。以下代码使用 `text_to_embedding()` 函数将这些文本文档转换为向量嵌入，并插入到向量存储中。 ```python documents = [ @@ -224,9 +224,9 @@ vector_store.insert( ### 步骤 7. 执行语义搜索 -在此步骤中，你将搜索 "一只会游泳的动物"，该词组与现有文档中的词没有直接匹配。 +本步骤将搜索 "a swimming animal"，该查询与现有文档中的任何单词都不直接匹配。 -以下代码再次使用 `text_to_embedding()` 函数，将查询文本转换为向量嵌入，然后用该嵌入进行查询，找到最接近的前三个匹配。 +以下代码再次使用 `text_to_embedding()` 函数将查询文本转换为向量嵌入，然后用该嵌入向量查询，找出最接近的前三个结果。 ```python def print_result(query, result): @@ -234,7 +234,7 @@ def print_result(query, result): for r in result: print(f"- text: \"{r.document}\", distance: {r.distance}") -query = "一只会游泳的动物" +query = "a swimming animal" query_embedding = text_to_embedding(query) search_result = vector_store.query(query_embedding, k=3) print_result(query, search_result) @@ -243,17 +243,17 @@ print_result(query, search_result) 运行 `example.py` 文件，输出如下： ```plain -Search result ("一只会游泳的动物"): +Search result ("a swimming animal"): - text: "fish", distance: 0.4562914811223072 - text: "dog", distance: 0.6469335836410557 - text: "tree", distance: 0.798545178640937 ``` -搜索结果中的三个词条按照它们与查询向量的距离排序：距离越小，相关性越高。 +搜索结果中的三个词根据与查询向量的距离排序：距离越小，`document` 越相关。 -因此，根据输出，最可能的匹配对象是鱼，或者是擅长游泳的狗。 +因此，根据输出，最有可能的游泳动物是 fish，或者是一只擅长游泳的 dog。 -## 相关链接 +## 参见 -- [Vector Data Types](/vector-search/vector-search-data-types.md) -- [Vector Search Index](/vector-search/vector-search-index.md) \ No newline at end of file +- [向量数据类型](/vector-search/vector-search-data-types.md) +- [向量检索索引](/vector-search/vector-search-index.md) \ No newline at end of file diff --git a/vector-search/vector-search-get-started-using-sql.md b/vector-search/vector-search-get-started-using-sql.md index ddd81ba80a3f5..0c8e36f7991ba 100644 --- a/vector-search/vector-search-get-started-using-sql.md +++ b/vector-search/vector-search-get-started-using-sql.md @@ -1,24 +1,24 @@ --- -title: 使用 SQL 快速入门向量搜索 -summary: 了解如何通过 SQL 语句在 TiDB 中快速开始向量搜索，为你的生成式 AI 应用提供支持。 +title: 通过 SQL 快速入门向量检索 +summary: 学习如何仅使用 SQL 语句在 TiDB 中快速开始向量检索，为你的生成式 AI 应用提供支持。 --- -# 使用 SQL 快速入门向量搜索 +# 通过 SQL 快速入门向量检索 -TiDB 扩展了 MySQL 语法，支持 [Vector Search](/vector-search/vector-search-overview.md)，引入了新的 [Vector data types](/vector-search/vector-search-data-types.md) 和多个 [vector functions](/vector-search/vector-search-functions-and-operators.md)。 +TiDB 扩展了 MySQL 语法以支持 [向量检索](/vector-search/vector-search-overview.md)，并引入了新的 [向量数据类型](/vector-search/vector-search-data-types.md) 以及若干 [向量函数](/vector-search/vector-search-functions-and-operators.md)。 -本教程演示了如何仅使用 SQL 语句在 TiDB 中开始向量搜索。你将学习如何使用 [MySQL command-line client](https://dev.mysql.com/doc/refman/8.4/en/mysql.html) 完成以下操作： +本教程演示了如何仅使用 SQL 语句在 TiDB 中快速开始向量检索。你将学习如何使用 [MySQL 命令行客户端](https://dev.mysql.com/doc/refman/8.4/en/mysql.html) 完成以下操作： - 连接到你的 TiDB 集群。 - 创建向量表。 - 存储向量嵌入。 -- 执行向量搜索查询。 +- 执行向量检索查询。 > **Warning:** > -> 向量搜索功能处于实验阶段。不建议在生产环境中使用此功能。此功能可能在未提前通知的情况下进行更改。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能为实验性特性。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -26,56 +26,56 @@ TiDB 扩展了 MySQL 语法，支持 [Vector Search](/vector-search/vector-searc > **Note:** > -> 向量搜索功能处于 beta 阶段。可能会在未提前通知的情况下进行更改。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能处于 beta 阶段，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 或更高（建议使用 v8.5.0 或更高版本）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 -## 前提条件 +## 前置条件 完成本教程，你需要： -- 在你的机器上安装 [MySQL command-line client](https://dev.mysql.com/doc/refman/8.4/en/mysql.html)（MySQL CLI）。 +- 在本地安装 [MySQL 命令行客户端](https://dev.mysql.com/doc/refman/8.4/en/mysql.html)（MySQL CLI）。 - 一个 TiDB 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- 参考 [Deploy a local test TiDB cluster](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [Deploy a production TiDB cluster](/production-deployment-using-tiup.md) 来创建本地集群。 -- 参考 [Creating a {{{ .starter }}} cluster](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 +- 参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- （推荐）参考 [Creating a {{{ .starter }}} cluster](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 -- 参考 [Deploy a local test TiDB cluster](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [Deploy a production TiDB cluster](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 来创建版本为 v8.4.0 或更高的本地集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建 v8.4.0 或更高版本的本地集群。 -## 开始操作 +## 快速开始 -### Step 1. 连接到 TiDB 集群 +### 第 1 步：连接到 TiDB 集群 根据你选择的 TiDB 部署方式，连接到你的 TiDB 集群。 -
+
-1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群的名称，进入其概览页面。 +1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群名称进入其概览页面。 -2. 点击右上角的 **Connect**。会显示连接对话框。 +2. 点击右上角的 **Connect**，弹出连接对话框。 -3. 在连接对话框中，从 **Connect With** 下拉列表选择 **MySQL CLI**，并保持 **Connection Type** 的默认设置为 **Public**。 +3. 在连接对话框中，从 **Connect With** 下拉列表中选择 **MySQL CLI**，并保持 **Connection Type** 的默认设置为 **Public**。 -4. 如果还没有设置密码，点击 **Generate Password** 以生成随机密码。 +4. 如果你还未设置密码，点击 **Generate Password** 生成一个随机密码。 -5. 复制连接命令，并粘贴到你的终端中。以下是 macOS 的示例： +5. 复制连接命令并粘贴到你的终端中。以下是 macOS 的示例： ```bash mysql -u '.root' -h '' -P 4000 -D 'test' --ssl-mode=VERIFY_IDENTITY --ssl-ca=/etc/ssl/cert.pem -p'' @@ -84,7 +84,7 @@ TiDB 扩展了 MySQL 语法，支持 [Vector Search](/vector-search/vector-searc
-在你的 TiDB Self-Managed 集群启动后，在终端中执行你的集群连接命令。 +当你的 TiDB 自建集群启动后，在终端中执行集群连接命令。 以下是 macOS 的示例连接命令： @@ -96,19 +96,19 @@ mysql --comments --host 127.0.0.1 --port 4000 -u root -### Step 2. 创建向量表 +### 第 2 步：创建向量表 -在创建表时，可以通过指定 `VECTOR` 数据类型，将某一列定义为 [vector](/vector-search/vector-search-overview.md#vector-embedding) 列。 +创建表时，你可以通过指定 `VECTOR` 数据类型将某一列定义为 [向量](/vector-search/vector-search-overview.md#vector-embedding) 列。 -例如，要创建一个名为 `embedded_documents`，包含一个三维 `VECTOR` 列的表，使用你的 MySQL CLI 执行以下 SQL 语句： +例如，若要创建一个包含三维 `VECTOR` 列的 `embedded_documents` 表，可在 MySQL CLI 中执行以下 SQL 语句： ```sql USE test; CREATE TABLE embedded_documents ( id INT PRIMARY KEY, - -- 用于存储文档的原始内容。 + -- Column to store the original content of the document. document TEXT, - -- 用于存储文档的向量表示。 + -- Column to store the vector representation of the document. embedding VECTOR(3) ); ``` @@ -119,9 +119,9 @@ CREATE TABLE embedded_documents ( Query OK, 0 rows affected (0.27 sec) ``` -### Step 3. 插入向量嵌入到表中 +### 第 3 步：向表中插入向量嵌入 -向 `embedded_documents` 表插入三个文档及其 [vector embeddings](/vector-search/vector-search-overview.md#vector-embedding)： +向 `embedded_documents` 表插入三条带有 [向量嵌入](/vector-search/vector-search-overview.md#vector-embedding) 的文档： ```sql INSERT INTO embedded_documents @@ -140,13 +140,13 @@ Records: 3 Duplicates: 0 Warnings: 0 > **Note** > -> 这个示例简化了向量嵌入的维度，只使用了 3 维向量进行演示。 +> 本示例简化了向量嵌入的维度，仅使用三维向量进行演示。 > -> 在实际应用中，[embedding models](/vector-search/vector-search-overview.md#embedding-model) 通常会生成数百或数千维的向量嵌入。 +> 在实际应用中，[嵌入模型](/vector-search/vector-search-overview.md#embedding-model) 通常会生成数百甚至数千维的向量嵌入。 -### Step 4. 查询向量表 +### 第 4 步：查询向量表 -为了验证文档是否正确插入，可以查询 `embedded_documents` 表： +为验证文档是否已正确插入，可查询 `embedded_documents` 表： ```sql SELECT * FROM embedded_documents; @@ -165,13 +165,13 @@ SELECT * FROM embedded_documents; 3 rows in set (0.15 sec) ``` -### Step 5. 执行向量搜索查询 +### 第 5 步：执行向量检索查询 -类似全文搜索，用户在使用向量搜索时会向应用提供搜索词。 +与全文检索类似，用户在使用向量检索时会向应用提供检索词。 -在本例中，搜索词为 “a swimming animal”，其对应的向量嵌入假设为 `[1,2,3]`。在实际应用中，你需要使用 embedding 模型将用户的搜索词转换为向量嵌入。 +本例中，检索词为 “a swimming animal”，其对应的向量嵌入假定为 `[1,2,3]`。在实际应用中，你需要使用嵌入模型将用户的检索词转换为向量嵌入。 -执行以下 SQL 语句，TiDB 将通过计算并排序表中向量嵌入的余弦距离（`vec_cosine_distance`），找到与 `[1,2,3]` 最接近的前三个文档。 +执行以下 SQL 语句，TiDB 会通过计算并排序表中向量嵌入与 `[1,2,3]` 的余弦距离（`vec_cosine_distance`），找出与其最接近的前三个文档。 ```sql SELECT id, document, vec_cosine_distance(embedding, '[1,2,3]') AS distance @@ -193,6 +193,11 @@ LIMIT 3; 3 rows in set (0.15 sec) ``` -搜索结果中的三个词条按照它们与查询向量的距离排序：距离越小，相关性越高。 +检索结果中的三个词条按照与查询向量的距离升序排列：距离越小，`document` 与检索向量的相关性越高。 -因此，根据输出，最有可能的“会游泳的动物”是鱼，或者是擅长游泳的狗。 \ No newline at end of file +因此，根据输出，最有可能的“swimming animal”是 fish，或者是一只擅长游泳的 dog。 + +## 参见 + +- [向量数据类型](/vector-search/vector-search-data-types.md) +- [向量检索索引](/vector-search/vector-search-index.md) diff --git a/vector-search/vector-search-improve-performance.md b/vector-search/vector-search-improve-performance.md index e5c5bf20ca3db..ab9e1e1255604 100644 --- a/vector-search/vector-search-improve-performance.md +++ b/vector-search/vector-search-improve-performance.md @@ -1,17 +1,17 @@ --- -title: 提升向量搜索性能 -summary: 学习提升 TiDB 向量搜索性能的最佳实践。 +title: 提升向量检索性能 +summary: 了解提升 TiDB 向量检索性能的最佳实践。 --- -# 提升向量搜索性能 +# 提升向量检索性能 -TiDB 向量搜索使你能够执行近似最近邻（ANN）查询，搜索与图片、文档或其他输入相似的结果。为了提升查询性能，请参考以下最佳实践。 +TiDB 向量检索支持执行近似最近邻（ANN）查询，用于查找与图片、文档或其他输入相似的结果。为了提升查询性能，请参考以下最佳实践。 > **Warning:** > -> The vector search feature is experimental. It is not recommended that you use it in the production environment. This feature might be changed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub. +> 向量检索功能为实验性特性。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交一个 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,38 +19,38 @@ TiDB 向量搜索使你能够执行近似最近邻（ANN）查询，搜索与图 > **Note:** > -> The vector search feature is in beta. It might be changed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub. +> 向量检索功能处于 beta 阶段，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交一个 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> The vector search feature is available on TiDB Self-Managed, [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless), and [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated). For TiDB Self-Managed and TiDB Cloud Dedicated, the TiDB version must be v8.4.0 or later (v8.5.0 or later is recommended). +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 -## 为向量列添加向量搜索索引 +## 为向量列添加向量检索索引 -[向量搜索索引](/vector-search/vector-search-index.md) 能显著提升向量搜索查询的性能，通常提升 10 倍或更多，代价是召回率略有下降。 +[向量检索索引](/vector-search/vector-search-index.md) 能显著提升向量检索查询的性能，通常可提升 10 倍以上，代价仅为召回率的轻微下降。 ## 确保向量索引已完全构建 -在插入大量向量数据后，部分数据可能处于 Delta 层，等待持久化。此类数据的向量索引会在数据持久化后进行构建。在所有向量数据完成索引之前，向量搜索的性能不会达到最佳。要查看索引构建进度，请参见 [View index build progress](/vector-search/vector-search-index.md#view-index-build-progress)。 +在你插入大量向量数据后，部分数据可能仍处于 Delta 层，等待持久化。这部分数据的向量索引会在数据持久化后构建。在所有向量数据都被索引之前，向量检索的性能并不理想。要查看索引的构建进度，请参见 [查看索引构建进度](/vector-search/vector-search-index.md#view-index-build-progress)。 -## 减少向量维度或缩短嵌入向量 +## 降低向量维度或缩短嵌入向量 -随着向量维度的增加，向量索引和查询的计算复杂度会显著提升，需进行更多的浮点数比较。 +随着向量维度的增加，向量检索索引和查询的计算复杂度会显著提升，需要进行更多的浮点数比较。 -为了优化性能，建议在可行的情况下减少向量维度。这通常需要切换到其他的嵌入模型。在切换模型时，需要评估模型变更对向量查询准确率的影响。 +为了优化性能，建议在可行的情况下降低向量维度。这通常需要切换到其他嵌入模型。在切换模型时，你需要评估模型变更对向量查询准确率的影响。 -某些嵌入模型如 OpenAI `text-embedding-3-large` 支持 [缩短嵌入向量](https://openai.com/index/new-embedding-models-and-api-updates/)，即在不影响嵌入表达概念的前提下，去除向量序列末尾的一些数字。你也可以使用此类模型来减小向量维度。 +某些嵌入模型（如 OpenAI 的 `text-embedding-3-large`）支持[缩短嵌入向量](https://openai.com/index/new-embedding-models-and-api-updates/)，即在不影响嵌入向量语义表达能力的前提下，从向量序列末尾移除部分数值。你也可以通过此类嵌入模型来降低向量维度。 -## 在结果中排除向量列 +## 查询结果中排除向量列 -向量嵌入数据通常较大，仅在搜索过程中使用。通过在查询结果中排除向量列，可以大幅减少 TiDB 服务器与 SQL 客户端之间传输的数据量，从而提升查询性能。 +向量嵌入数据通常体积较大，仅在检索过程中使用。通过在查询结果中排除向量列，可以大幅减少 TiDB 服务器与 SQL 客户端之间传输的数据量，从而提升查询性能。 -要排除向量列，应在 `SELECT` 子句中明确列出你希望检索的列，而不是使用 `SELECT *` 来获取所有列。 +要排除向量列，请在 `SELECT` 子句中显式列出你需要返回的列，而不是使用 `SELECT *` 返回所有列。 ## 预热索引 -当访问从未使用过或长时间未访问的索引（冷访问）时，TiDB 需要从云存储或磁盘加载整个索引（而非从内存加载）。此过程耗时较长，常导致查询延迟增加。此外，如果长时间没有 SQL 查询（例如数小时），计算资源会被回收，后续访问会变成冷访问。 +当访问从未被使用过或长时间未被访问（冷访问）的索引时，TiDB 需要从云存储或磁盘（而不是内存）加载整个索引。此过程会耗费时间，通常导致查询延迟升高。此外，如果长时间（例如数小时）没有 SQL 查询，计算资源会被回收，导致后续访问变为冷访问。 -为了避免此类查询延迟，可以在实际工作负载之前，通过运行类似的向量搜索查询预热索引，从而使索引处于热状态。 \ No newline at end of file +为避免此类查询延迟，在实际负载前，可以通过执行命中向量索引的类似向量检索查询来预热索引。 \ No newline at end of file diff --git a/vector-search/vector-search-index.md b/vector-search/vector-search-index.md index f20b5588ad9ff..2d0e388b741ad 100644 --- a/vector-search/vector-search-index.md +++ b/vector-search/vector-search-index.md @@ -1,19 +1,19 @@ --- -title: Vector Search Index -summary: 学习如何构建和使用向量搜索索引，以加速 TiDB 中的 K-Nearest neighbors (KNN) 查询。 +title: 向量检索索引 +summary: 了解如何构建和使用向量检索索引，以加速 TiDB 中的 K-最近邻（KNN）查询。 --- -# Vector Search Index +# 向量检索索引 -如 [Vector Search](/vector-search/vector-search-overview.md) 文档所述，向量搜索通过计算给定向量与数据库中存储的所有向量之间的距离，识别出前 K 个最近邻（KNN）。虽然这种方法可以提供准确的结果，但当表中包含大量向量时，速度可能较慢，因为涉及全表扫描。 [^1] +如 [向量检索](/vector-search/vector-search-overview.md) 文档所述，向量检索通过计算给定向量与数据库中所有向量之间的距离，找出 Top K-最近邻（KNN）。这种方式能够提供准确的结果，但当表中包含大量向量时，由于需要全表扫描，查询速度会很慢。[^1] -为了提高搜索效率，你可以在 TiDB 中创建向量搜索索引，用于近似 KNN（ANN）搜索。当使用向量索引进行向量搜索时，TiDB 可以大大提升查询性能，误差仅有微小的降低，通常能保持在 90% 以上的搜索召回率。 +为了提升检索效率，你可以在 TiDB 中为近似 KNN（ANN）检索创建向量检索索引。使用向量索引进行向量检索时，TiDB 可以大幅提升查询性能，仅以极小的准确率损失为代价，通常能保持 90% 以上的检索召回率。 > **Warning:** > -> 向量搜索功能处于实验阶段。不建议在生产环境中使用此功能。此功能可能在未提前通知的情况下进行更改。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能为实验性特性。不建议在生产环境中使用。该功能可能会在未提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -21,35 +21,35 @@ summary: 学习如何构建和使用向量搜索索引，以加速 TiDB 中的 K > **Note:** > -> 向量搜索功能处于测试版。可能会在未提前通知的情况下进行更改。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能处于 beta 阶段，可能会在未提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可使用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 及以上（建议使用 v8.5.0 及以上）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 及以上（推荐 v8.5.0 及以上）。 -目前，TiDB 支持 [HNSW (Hierarchical Navigable Small World)](https://en.wikipedia.org/wiki/Hierarchical_navigable_small_world) 向量搜索索引算法。 +目前，TiDB 支持 [HNSW（Hierarchical Navigable Small World）](https://en.wikipedia.org/wiki/Hierarchical_navigable_small_world) 向量检索索引算法。 ## 限制 -- 必须提前在集群中部署 TiFlash 节点。 -- 向量搜索索引不能用作主键或唯一索引。 -- 向量搜索索引只能在单个向量列上创建，不能与其他列（如整数或字符串）组合形成复合索引。 -- 创建和使用向量搜索索引时，必须指定距离函数。目前仅支持余弦距离 `VEC_COSINE_DISTANCE()` 和 L2 距离 `VEC_L2_DISTANCE()`。 -- 对于同一列，不支持使用相同距离函数创建多个向量搜索索引。 -- 不支持直接删除带有向量搜索索引的列。可以先删除该列上的向量搜索索引，再删除列本身。 -- 不支持修改带有向量索引的列的类型。 -- 不支持将向量搜索索引设置为 [invisible](/sql-statements/sql-statement-alter-index.md)。 -- 在启用 [encryption at rest](https://docs.pingcap.com/tidb/stable/encryption-at-rest) 的 TiFlash 节点上构建向量搜索索引不被支持。 +- 集群中必须提前部署 TiFlash 节点。 +- 向量检索索引不能作为主键或唯一索引使用。 +- 向量检索索引只能创建在单个向量列上，不能与其他列（如整数或字符串）组合为复合索引。 +- 创建和使用向量检索索引时，必须指定距离函数。目前仅支持余弦距离 `VEC_COSINE_DISTANCE()` 和 L2 距离 `VEC_L2_DISTANCE()`。 +- 对于同一列，不支持使用相同距离函数创建多个向量检索索引。 +- 不支持直接删除带有向量检索索引的列。你可以先删除该列上的向量检索索引，再删除该列。 +- 不支持修改带有向量索引的列的数据类型。 +- 不支持将向量检索索引设置为 [不可见](/sql-statements/sql-statement-alter-index.md)。 +- 不支持在启用了[静态加密](https://docs.pingcap.com/tidb/stable/encryption-at-rest)的 TiFlash 节点上构建向量检索索引。 ## 创建 HNSW 向量索引 -[HNSW](https://en.wikipedia.org/wiki/Hierarchical_navigable_small_world) 是最流行的向量索引算法之一。HNSW 索引在性能和准确率方面表现良好，在特定情况下最高可达 98%。 +[HNSW](https://en.wikipedia.org/wiki/Hierarchical_navigable_small_world) 是最流行的向量索引算法之一。HNSW 索引在性能和准确率之间取得了良好平衡，在特定场景下准确率可达 98%。 -在 TiDB 中，你可以通过以下两种方式为具有 [vector data type](/vector-search/vector-search-data-types.md) 的列创建 HNSW 索引： +在 TiDB 中，你可以通过以下任一方式为具有 [向量数据类型](/vector-search/vector-search-data-types.md) 的列创建 HNSW 索引： -- 在创建表时，使用以下语法指定向量列以建立 HNSW 索引： +- 创建表时，使用如下语法为向量列指定 HNSW 索引： ```sql CREATE TABLE foo ( @@ -59,36 +59,36 @@ summary: 学习如何构建和使用向量搜索索引，以加速 TiDB 中的 K ); ``` -- 对已包含向量列的现有表，使用以下语法为该列创建 HNSW 索引： +- 对于已存在且包含向量列的表，使用如下语法为该向量列创建 HNSW 索引： ```sql CREATE VECTOR INDEX idx_embedding ON foo ((VEC_COSINE_DISTANCE(embedding))); ALTER TABLE foo ADD VECTOR INDEX idx_embedding ((VEC_COSINE_DISTANCE(embedding))); - -- 你也可以显式指定 "USING HNSW" 来构建向量搜索索引。 + -- 你也可以显式指定 "USING HNSW" 来构建向量检索索引。 CREATE VECTOR INDEX idx_embedding ON foo ((VEC_COSINE_DISTANCE(embedding))) USING HNSW; ALTER TABLE foo ADD VECTOR INDEX idx_embedding ((VEC_COSINE_DISTANCE(embedding))) USING HNSW; ``` > **Note:** > -> 向量搜索索引功能依赖于表的 TiFlash 副本。 +> 向量检索索引功能依赖于表的 TiFlash 副本。 > -> - 如果在创建表时定义了向量搜索索引，TiDB 会自动为该表创建 TiFlash 副本。 -> - 如果在创建表时未定义向量搜索索引，且该表目前没有 TiFlash 副本，则需要手动创建 TiFlash 副本后，才能为表添加向量搜索索引。例如：`ALTER TABLE 'table_name' SET TIFLASH REPLICA 1;`。 +> - 如果在创建表时定义了向量检索索引，TiDB 会自动为该表创建 TiFlash 副本。 +> - 如果在创建表时未定义向量检索索引，且当前表没有 TiFlash 副本，则需要在为表添加向量检索索引前，手动创建 TiFlash 副本。例如：`ALTER TABLE 'table_name' SET TIFLASH REPLICA 1;`。 -在创建 HNSW 向量索引时，需要指定向量的距离函数： +创建 HNSW 向量索引时，需要为向量指定距离函数： - 余弦距离：`((VEC_COSINE_DISTANCE(embedding)))` - L2 距离：`((VEC_L2_DISTANCE(embedding)))` -索引只能用于固定维度的向量列，例如定义为 `VECTOR(3)` 的列。不能用于非固定维度的向量列（如定义为 `VECTOR`），因为只能在相同维度的向量之间计算距离。 +向量索引只能创建在定长向量列上，例如定义为 `VECTOR(3)` 的列。不能为非定长向量列（如定义为 `VECTOR` 的列）创建索引，因为只有相同维度的向量之间才能计算距离。 -关于向量搜索索引的限制和注意事项，请参见 [Restrictions](#restrictions)。 +关于向量检索索引的限制，参见 [限制](#限制)。 ## 使用向量索引 -可以在 K 最近邻搜索查询中使用向量搜索索引，通过 `ORDER BY ... LIMIT` 子句实现，例如： +在 K-最近邻检索查询中，可以通过如下 `ORDER BY ... LIMIT` 语句使用向量检索索引： ```sql SELECT * @@ -97,11 +97,11 @@ ORDER BY VEC_COSINE_DISTANCE(embedding, '[1, 2, 3, 4, 5]') LIMIT 10 ``` -使用索引进行向量搜索时，确保 `ORDER BY ... LIMIT` 子句使用的距离函数与创建索引时指定的相同。 +要在向量检索中使用索引，确保 `ORDER BY ... LIMIT` 子句使用的距离函数与创建向量索引时指定的距离函数一致。 -## 在过滤条件下使用向量索引 +## 向量索引与过滤条件的配合使用 -包含预过滤（使用 `WHERE` 子句）的查询无法利用向量索引，因为它们不是按照 SQL 语义进行 KNN 查询。例如： +包含预过滤（使用 `WHERE` 子句）的查询无法利用向量索引，因为根据 SQL 语义，这类查询并不是在查找 K-最近邻。例如： ```sql -- 对于以下查询，`WHERE` 过滤在 KNN 之前执行，因此无法使用向量索引： @@ -112,10 +112,10 @@ ORDER BY VEC_COSINE_DISTANCE(embedding, '[1, 2, 3]') LIMIT 5; ``` -要在过滤条件下使用向量索引，可以先用向量搜索查询出 K 最近邻，然后再过滤掉不需要的结果： +要在带有过滤条件的场景下使用向量索引，可以先通过向量检索查找 K-最近邻，再对结果进行过滤： ```sql --- 对于以下查询，`WHERE` 过滤在 KNN 之后执行，因此无法使用向量索引： +-- 对于以下查询，`WHERE` 过滤在 KNN 之后执行，因此可以使用向量索引： SELECT * FROM ( @@ -125,14 +125,14 @@ SELECT * FROM ) t WHERE category = "document"; --- 注意：如果过滤掉一些结果，最终返回的结果可能少于 5 条。 +-- 注意，如果部分结果被过滤，最终返回的结果可能少于 5 条。 ``` ## 查看索引构建进度 -在插入大量数据后，部分数据可能不会立即持久化到 TiFlash。对于已持久化的向量数据，向量搜索索引会同步构建。对于尚未持久化的数据，索引会在数据持久化后进行构建。此过程不会影响数据的准确性和一致性，你仍然可以随时进行向量搜索并获得完整结果，但性能会在索引完全构建前不理想。 +在你插入大量数据后，部分数据可能不会立即持久化到 TiFlash。对于已持久化的向量数据，向量检索索引会同步构建。对于尚未持久化的数据，索引会在数据持久化后再进行构建。该过程不会影响数据的准确性和一致性，你可以随时进行向量检索并获得完整结果。但在向量索引完全构建前，性能会低于最佳状态。 -你可以通过查询 `INFORMATION_SCHEMA.TIFLASH_INDEXES` 表来查看索引构建进度，示例如下： +你可以通过查询 `INFORMATION_SCHEMA.TIFLASH_INDEXES` 表来查看索引构建进度： ```sql SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; @@ -144,27 +144,27 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; +---------------+------------+----------+-------------+---------------+-----------+----------+------------+---------------------+-------------------------+--------------------+------------------------+---------------+------------------+ ``` -- 你可以检查 `ROWS_STABLE_INDEXED` 和 `ROWS_STABLE_NOT_INDEXED` 列以了解索引构建进度。当 `ROWS_STABLE_NOT_INDEXED` 变为 0 时，索引构建完成。 +- 你可以通过 `ROWS_STABLE_INDEXED` 和 `ROWS_STABLE_NOT_INDEXED` 列查看索引构建进度。当 `ROWS_STABLE_NOT_INDEXED` 为 0 时，索引构建完成。 - 作为参考，索引一个 768 维、500 MiB 大小的向量数据集可能需要最多 20 分钟。索引器可以对多个表并行运行。目前不支持调整索引器的优先级或速度。 + 作为参考，对 500 MiB、768 维的向量数据集进行索引，可能需要长达 20 分钟。索引器可以并行为多个表构建索引。目前不支持调整索引器的优先级或速度。 -- 你可以检查 `ROWS_DELTA_NOT_INDEXED` 列，了解 Delta 层中的行数。TiFlash 的存储层数据分为 Delta 层和 Stable 层。Delta 层存储最近插入或更新的行，且会根据写入负载定期合并到 Stable 层，这一过程称为压缩（Compaction）。 +- 你可以通过 `ROWS_DELTA_NOT_INDEXED` 列查看 Delta 层中的行数。TiFlash 存储层的数据分为 Delta 层和 Stable 层。Delta 层存储最近插入或更新的行，并会根据写入负载定期合并到 Stable 层。该合并过程称为 Compaction。 - Delta 层始终不被索引。为了获得最佳性能，可以强制将 Delta 层合并到 Stable 层，使所有数据都能被索引： + Delta 层始终不会被索引。为获得最佳性能，你可以强制将 Delta 层合并到 Stable 层，从而使所有数据都能被索引： ```sql ALTER TABLE COMPACT; ``` - 更多信息请参见 [`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)。 + 更多信息，参见 [`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)。 -此外，你还可以通过执行 `ADMIN SHOW DDL JOBS;` 并检查 `row count` 来监控 DDL 任务的执行进度，但此方法不完全准确，因为 `row count` 值来自 `TIFLASH_INDEXES` 中的 `rows_stable_indexed` 字段。你可以用此方法作为索引进度的参考。 +此外，你还可以通过执行 `ADMIN SHOW DDL JOBS;` 并查看 `row count` 字段来监控 DDL 任务的执行进度。但该方法并不完全准确，因为 `row count` 的值来源于 `TIFLASH_INDEXES` 中的 `rows_stable_indexed` 字段。你可以将此方法作为索引进度的参考。 -## 查看是否使用向量索引 +## 检查是否使用了向量索引 -使用 [`EXPLAIN`](/sql-statements/sql-statement-explain.md) 或 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 语句检查查询是否使用了向量索引。当 `operator info` 列中的 `annIndex:` 出现，表示此表扫描利用了向量索引。 +可以使用 [`EXPLAIN`](/sql-statements/sql-statement-explain.md) 或 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 语句，检查查询是否使用了向量索引。当 `TableFullScan` 执行器的 `operator info` 列中出现 `annIndex:` 时，表示该表扫描正在利用向量索引。 -**示例：使用了向量索引** +**示例：已使用向量索引** ```sql [tidb]> EXPLAIN SELECT * FROM vector_table_with_index @@ -186,7 +186,7 @@ LIMIT 10; 9 rows in set (0.01 sec) ``` -**示例：未使用向量索引（未指定前 K）** +**示例：未使用向量索引（未指定 Top K）** ```sql [tidb]> EXPLAIN SELECT * FROM vector_table_with_index @@ -204,7 +204,7 @@ LIMIT 10; 6 rows in set, 1 warning (0.01 sec) ``` -当无法使用向量索引时，某些情况下会出现警告，帮助你了解原因： +当无法使用向量索引时，部分场景下会出现警告，帮助你了解原因： ```sql -- 使用了错误的距离函数： @@ -224,9 +224,9 @@ LIMIT 10; ANN index not used: index can be used only when ordering by vec_cosine_distance() in ASC order ``` -## 分析向量搜索性能 +## 分析向量检索性能 -想了解向量索引的详细使用情况，可以执行 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 并查看输出中的 `execution info` 列，例如： +要了解向量索引的详细使用信息，可以执行 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 语句，并查看输出中的 `execution info` 列： ```sql [tidb]> EXPLAIN ANALYZE SELECT * FROM vector_table_with_index @@ -252,22 +252,22 @@ LIMIT 10; > **Note:** > -> 该执行信息为内部信息，字段和格式可能会在没有通知的情况下发生变化。请勿依赖。 +> 执行信息为内部字段，字段及格式可能随时变更，无需依赖。 -一些重要字段的说明： +部分重要字段说明： -- `vector_index.load.total`：加载索引的总时长。此字段可能大于实际查询时间，因为多个向量索引可能同时加载。 +- `vector_index.load.total`：索引加载总耗时。该字段可能大于实际查询耗时，因为可能有多个向量索引并行加载。 - `vector_index.load.from_s3`：从 S3 加载的索引数量。 -- `vector_index.load.from_disk`：从磁盘加载的索引数量，之前已从 S3 下载。 -- `vector_index.load.from_cache`：从缓存加载的索引数量，之前已从 S3 下载。 -- `vector_index.search.total`：在索引中搜索的总时长。较大的延迟通常意味着索引冷（未访问过或很久未访问），在搜索时会有较重的 I/O 操作。此字段可能大于实际查询时间，因为多个向量索引可能同时搜索。 -- `vector_index.search.discarded_nodes`：在搜索过程中访问但被丢弃的向量行数。这些被丢弃的向量不会计入搜索结果。数值较大通常表示存在大量陈旧行，可能由 `UPDATE` 或 `DELETE` 语句引起。 +- `vector_index.load.from_disk`：从磁盘加载的索引数量。该索引此前已从 S3 下载到本地磁盘。 +- `vector_index.load.from_cache`：从缓存加载的索引数量。该索引此前已从 S3 下载到缓存。 +- `vector_index.search.total`：在索引中检索的总耗时。较大的延迟通常意味着索引为冷数据（从未访问或长时间未访问），因此检索时会有大量 I/O 操作。该字段可能大于实际查询耗时，因为可能有多个向量索引并行检索。 +- `vector_index.search.discarded_nodes`：检索过程中访问但被丢弃的向量行数。这些被丢弃的向量不会计入检索结果。该值较大通常说明存在大量因 `UPDATE` 或 `DELETE` 语句导致的过时行。 -请参见 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)、[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 和 [EXPLAIN Walkthrough](/explain-walkthrough.md) 来理解输出内容。 +关于输出的解读，参见 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)、[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 及 [EXPLAIN 使用指南](/explain-walkthrough.md)。 -## 相关链接 +## 参见 -- [Improve Vector Search Performance](/vector-search/vector-search-improve-performance.md) -- [Vector Data Types](/vector-search/vector-search-data-types.md) +- [提升向量检索性能](/vector-search/vector-search-improve-performance.md) +- [向量数据类型](/vector-search/vector-search-data-types.md) -[^1]: KNN 搜索的说明借鉴自由 [rschu1ze](https://github.com/rschu1ze) 在 ClickHouse 文档中撰写的 [Approximate Nearest Neighbor Search Indexes](https://github.com/ClickHouse/ClickHouse/pull/50661/files#diff-7ebd9e71df96e74230c9a7e604fa7cb443be69ba5e23bf733fcecd4cc51b7576) 文档，授权协议为 Apache License 2.0。 \ No newline at end of file +[^1]: KNN 检索的解释改编自 ClickHouse 文档中由 [rschu1ze](https://github.com/rschu1ze) 撰写的 [Approximate Nearest Neighbor Search Indexes](https://github.com/ClickHouse/ClickHouse/pull/50661/files#diff-7ebd9e71df96e74230c9a7e604fa7cb443be69ba5e23bf733fcecd4cc51b7576) 文档，遵循 Apache License 2.0 许可。 \ No newline at end of file diff --git a/vector-search/vector-search-integrate-with-django-orm.md b/vector-search/vector-search-integrate-with-django-orm.md index ce28bfc0cc3cc..35a71f0d61329 100644 --- a/vector-search/vector-search-integrate-with-django-orm.md +++ b/vector-search/vector-search-integrate-with-django-orm.md @@ -1,17 +1,17 @@ --- -title: 将 TiDB 向量搜索集成到 Django ORM -summary: 学习如何将 TiDB 向量搜索与 Django ORM 集成，用于存储嵌入向量和执行语义搜索。 +title: 将 TiDB 向量检索集成到 Django ORM +summary: 学习如何将 TiDB 向量检索与 Django ORM 集成，用于存储嵌入向量并执行语义检索。 --- -# 将 TiDB 向量搜索集成到 Django ORM +# 将 TiDB 向量检索集成到 Django ORM -本教程将引导你如何使用 [Django](https://www.djangoproject.com/) ORM 与 [TiDB 向量搜索](/vector-search/vector-search-overview.md) 交互，存储嵌入向量，并执行向量搜索查询。 +本教程将指导你如何使用 [Django](https://www.djangoproject.com/) ORM 与 [TiDB 向量检索](/vector-search/vector-search-overview.md) 进行交互，存储嵌入向量，并执行向量检索查询。 > **Warning:** > -> 向量搜索功能处于实验阶段。不建议在生产环境中使用此功能。此功能可能在未提前通知的情况下进行更改。如发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能目前为实验性特性。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,54 +19,54 @@ summary: 学习如何将 TiDB 向量搜索与 Django ORM 集成，用于存储 > **Note:** > -> 向量搜索功能处于 beta 阶段。可能会在未提前通知的情况下进行更改。如发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能目前为 beta 版本，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 及以上（推荐 v8.5.0 及以上）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 -## 前提条件 +## 前置条件 完成本教程，你需要： -- 安装 [Python 3.8 或更高版本](https://www.python.org/downloads/) -- 安装 [Git](https://git-scm.com/downloads) -- 一个 TiDB 集群 +- 已安装 [Python 3.8 或更高版本](https://www.python.org/downloads/)。 +- 已安装 [Git](https://git-scm.com/downloads)。 +- 一个 TiDB 集群。 -**如果你还没有 TiDB 集群，可以按照以下步骤创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 来创建本地集群。 -- 参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 +- 参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 -**如果你还没有 TiDB 集群，可以按照以下步骤创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 -- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 来创建版本为 v8.4.0 或更高版本的本地集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建 v8.4.0 或更高版本的本地集群。 ## 运行示例应用 -你可以通过以下步骤快速了解如何将 TiDB 向量搜索与 Django ORM 集成。 +你可以按照以下步骤快速了解如何将 TiDB 向量检索与 Django ORM 集成。 -### 步骤 1. 克隆仓库 +### 第 1 步. 克隆代码仓库 -将 `tidb-vector-python` 仓库克隆到你的本地机器： +将 `tidb-vector-python` 仓库克隆到本地： ```shell git clone https://github.com/pingcap/tidb-vector-python.git ``` -### 步骤 2. 创建虚拟环境 +### 第 2 步. 创建虚拟环境 -为你的项目创建虚拟环境： +为你的项目创建一个虚拟环境： ```bash cd tidb-vector-python/examples/orm-django-quickstart @@ -74,15 +74,15 @@ python3 -m venv .venv source .venv/bin/activate ``` -### 步骤 3. 安装依赖 +### 第 3 步. 安装所需依赖 -安装示例项目所需的依赖： +为示例项目安装所需依赖： ```bash pip install -r requirements.txt ``` -或者，你也可以单独安装以下包： +或者，你也可以为你的项目单独安装以下包： ```bash pip install Django django-tidb mysqlclient numpy python-dotenv @@ -92,52 +92,52 @@ pip install Django django-tidb mysqlclient numpy python-dotenv #### 什么是 `django-tidb` -`django-tidb` 是 Django 的 TiDB 方言，增强了 Django ORM 对 TiDB 的支持（例如，向量搜索），并解决了 TiDB 与 Django 之间的兼容性问题。 +`django-tidb` 是 Django 的 TiDB 方言，增强了 Django ORM 对 TiDB 特性的支持（例如向量检索），并解决了 TiDB 与 Django 之间的兼容性问题。 -要安装 `django-tidb`，请选择与你的 Django 版本匹配的版本。例如，如果你使用 `django==4.2.*`，则安装 `django-tidb==4.2.*`。次版本号不必完全一致，建议使用最新的次版本。 +安装 `django-tidb` 时，请选择与你的 Django 版本相匹配的版本。例如，如果你使用的是 `django==4.2.*`，则安装 `django-tidb==4.2.*`。小版本号无需完全一致，建议使用最新的小版本。 更多信息请参考 [django-tidb 仓库](https://github.com/pingcap/django-tidb)。 -### 步骤 4. 配置环境变量 +### 第 4 步. 配置环境变量 -根据你选择的 TiDB 部署方式，配置环境变量。 +根据你选择的 TiDB 部署方式配置环境变量。 -
+
-对于 {{{ .starter }}} 集群，按照以下步骤获取集群连接字符串并配置环境变量： +对于 TiDB Cloud Starter 集群，请按以下步骤获取集群连接串并配置环境变量： -1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群的名称，进入其概览页面。 +1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入集群概览页。 2. 点击右上角的 **Connect**，弹出连接对话框。 -3. 确认连接对话框中的配置与操作环境匹配。 +3. 确保连接对话框中的配置与你的操作环境一致。 - **Connection Type** 设置为 `Public` - **Branch** 设置为 `main` - **Connect With** 设置为 `General` - - **Operating System** 与你的环境一致。 + - **Operating System** 与你的环境一致 > **Tip:** > - > 如果你的程序在 Windows 子系统 Linux（WSL）中运行，请切换到对应的 Linux 发行版。 + > 如果你的程序运行在 Windows Subsystem for Linux (WSL) 中，请切换到对应的 Linux 发行版。 -4. 从连接对话框复制连接参数。 +4. 从连接对话框中复制连接参数。 > **Tip:** > - > 如果还未设置密码，可以点击 **Generate Password** 生成随机密码。 + > 如果你还未设置密码，可点击 **Generate Password** 生成随机密码。 -5. 在你的 Python 项目的根目录下，创建一个 `.env` 文件，并将连接参数粘贴到对应的环境变量中。 +5. 在你的 Python 项目根目录下创建 `.env` 文件，并将连接参数粘贴到对应的环境变量中。 - - `TIDB_HOST`: TiDB 集群的主机地址 - - `TIDB_PORT`: TiDB 集群的端口 - - `TIDB_USERNAME`: 连接 TiDB 集群的用户名 - - `TIDB_PASSWORD`: 连接 TiDB 集群的密码 - - `TIDB_DATABASE`: 要连接的数据库名 - - `TIDB_CA_PATH`: 根证书文件的路径 + - `TIDB_HOST`：TiDB 集群的主机地址 + - `TIDB_PORT`：TiDB 集群的端口 + - `TIDB_USERNAME`：连接 TiDB 集群的用户名 + - `TIDB_PASSWORD`：连接 TiDB 集群的密码 + - `TIDB_DATABASE`：要连接的数据库名 + - `TIDB_CA_PATH`：根证书文件的路径 - 下面是 macOS 的示例： + 以下是 macOS 的示例： ```dotenv TIDB_HOST=gateway01.****.prod.aws.tidbcloud.com @@ -151,7 +151,7 @@ pip install Django django-tidb mysqlclient numpy python-dotenv
-对于 TiDB Self-Managed 集群，在你的 Python 项目的根目录下创建 `.env` 文件。将以下内容复制到 `.env` 文件中，并根据你的 TiDB 集群连接参数修改环境变量值： +对于 TiDB 自建集群，在你的 Python 项目根目录下创建 `.env` 文件。将以下内容复制到 `.env` 文件中，并根据你的 TiDB 集群连接参数修改环境变量的值： ```dotenv TIDB_HOST=127.0.0.1 @@ -161,49 +161,49 @@ TIDB_PASSWORD= TIDB_DATABASE=test ``` -如果你在本地运行 TiDB，`TIDB_HOST` 默认为 `127.0.0.1`。初次启动集群时，`TIDB_PASSWORD` 默认为空，可以省略此字段。 +如果你在本地运行 TiDB，`TIDB_HOST` 默认为 `127.0.0.1`。初始的 `TIDB_PASSWORD` 为空，因此如果是首次启动集群，可以省略该字段。 -以下是各参数的说明： +各参数说明如下： -- `TIDB_HOST`: TiDB 集群的主机地址 -- `TIDB_PORT`: TiDB 集群的端口 -- `TIDB_USERNAME`: 连接 TiDB 集群的用户名 -- `TIDB_PASSWORD`: 连接 TiDB 集群的密码 -- `TIDB_DATABASE`: 你要连接的数据库名称 +- `TIDB_HOST`：TiDB 集群的主机地址 +- `TIDB_PORT`：TiDB 集群的端口 +- `TIDB_USERNAME`：连接 TiDB 集群的用户名 +- `TIDB_PASSWORD`：连接 TiDB 集群的密码 +- `TIDB_DATABASE`：要连接的数据库名称
-### 步骤 5. 运行示例 +### 第 5 步. 运行示例 -迁移数据库架构： +迁移数据库结构： ```bash python manage.py migrate ``` -启动 Django 开发服务器： +运行 Django 开发服务器： ```bash python manage.py runserver ``` -打开浏览器，访问 `http://127.0.0.1:8000`，体验示例应用。以下是可用的 API 路径： +在浏览器中访问 `http://127.0.0.1:8000` 体验示例应用。以下是可用的 API 路径： -| API 路径 | 描述 | -| --------------------------------------- | -------------------------------- | -| `POST: /insert_documents` | 插入带有嵌入向量的文档。 | -| `GET: /get_nearest_neighbors_documents` | 获取最接近的 3 个邻居文档。 | -| `GET: /get_documents_within_distance` | 获取在一定距离内的文档。 | +| API Path | Description | +| --------------------------------------- | ---------------------------------------- | +| `POST: /insert_documents` | 插入带有嵌入向量的文档。 | +| `GET: /get_nearest_neighbors_documents` | 获取 3 个最近邻文档。 | +| `GET: /get_documents_within_distance` | 获取距离在指定范围内的文档。 | ## 示例代码片段 你可以参考以下示例代码片段，完成你自己的应用开发。 -### 连接到 TiDB 集群 +### 连接 TiDB 集群 -在 `sample_project/settings.py` 文件中添加以下配置： +在 `sample_project/settings.py` 文件中添加如下配置： ```python dotenv.load_dotenv() @@ -231,15 +231,15 @@ if TIDB_CA_PATH: } ``` -你可以在项目根目录下创建 `.env` 文件，设置环境变量 `TIDB_HOST`、`TIDB_PORT`、`TIDB_USERNAME`、`TIDB_PASSWORD`、`TIDB_DATABASE` 和 `TIDB_CA_PATH`，填入你的 TiDB 集群的实际值。 +你可以在项目根目录下创建 `.env` 文件，并将 `TIDB_HOST`、`TIDB_PORT`、`TIDB_USERNAME`、`TIDB_PASSWORD`、`TIDB_DATABASE` 和 `TIDB_CA_PATH` 等环境变量设置为你实际的 TiDB 集群参数。 ### 创建向量表 #### 定义向量列 -`tidb-django` 提供 `VectorField` 用于存储向量嵌入。 +`tidb-django` 提供了 `VectorField` 用于在表中存储向量嵌入。 -创建一个包含名为 `embedding` 的列的表，用于存储 3 维向量。 +创建一个包含名为 `embedding` 的 3 维向量列的表。 ```python class Document(models.Model): @@ -247,7 +247,7 @@ class Document(models.Model): embedding = VectorField(dimensions=3) ``` -### 存储带有嵌入的文档 +### 存储带嵌入向量的文档 ```python Document.objects.create(content="dog", embedding=[1, 2, 1]) @@ -255,16 +255,16 @@ Document.objects.create(content="fish", embedding=[1, 2, 4]) Document.objects.create(content="tree", embedding=[1, 0, 0]) ``` -### 搜索最邻近的文档 +### 检索最近邻文档 -TiDB 向量支持以下距离函数： +TiDB 向量检索支持以下距离函数： - `L1Distance` - `L2Distance` - `CosineDistance` - `NegativeInnerProduct` -根据余弦距离函数，搜索与查询向量 `[1, 2, 3]` 语义最接近的前 3 个文档。 +基于余弦距离函数，检索与查询向量 `[1, 2, 3]` 语义最接近的前 3 个文档。 ```python results = Document.objects.annotate( @@ -272,9 +272,9 @@ results = Document.objects.annotate( ).order_by('distance')[:3] ``` -### 搜索距离在一定范围内的文档 +### 检索距离在指定范围内的文档 -搜索与查询向量 `[1, 2, 3]` 的余弦距离小于 0.2 的文档。 +检索与查询向量 `[1, 2, 3]` 余弦距离小于 0.2 的文档。 ```python results = Document.objects.annotate( @@ -282,7 +282,7 @@ results = Document.objects.annotate( ).filter(distance__lt=0.2).order_by('distance')[:3] ``` -## 另请参阅 +## 相关链接 -- [Vector Data Types](/vector-search/vector-search-data-types.md) -- [Vector Search Index](/vector-search/vector-search-index.md) +- [向量数据类型](/vector-search/vector-search-data-types.md) +- [向量检索索引](/vector-search/vector-search-index.md) diff --git a/vector-search/vector-search-integrate-with-jinaai-embedding.md b/vector-search/vector-search-integrate-with-jinaai-embedding.md index 63c5c41e0f6d4..b285b4c861cad 100644 --- a/vector-search/vector-search-integrate-with-jinaai-embedding.md +++ b/vector-search/vector-search-integrate-with-jinaai-embedding.md @@ -1,17 +1,17 @@ --- -title: 将 TiDB Vector Search 与 Jina AI Embeddings API 集成 -summary: 学习如何将 TiDB Vector Search 与 Jina AI Embeddings API 集成，用于存储嵌入向量和执行语义搜索。 +title: 将 TiDB 向量检索与 Jina AI Embeddings API 集成 +summary: 学习如何将 TiDB 向量检索与 Jina AI Embeddings API 集成，以存储向量并进行语义检索。 --- -# 将 TiDB Vector Search 与 Jina AI Embeddings API 集成 +# 将 TiDB 向量检索与 Jina AI Embeddings API 集成 -本教程将引导你如何使用 [Jina AI](https://jina.ai/) 生成文本数据的嵌入向量，然后将这些嵌入存储在 TiDB 向量存储中，并基于嵌入向量进行相似文本搜索。 +本教程将指导你如何使用 [Jina AI](https://jina.ai/) 为文本数据生成向量，然后将这些向量存储在 TiDB 向量存储中，并基于向量进行相似文本检索。 > **Warning:** > -> 该向量搜索功能处于实验阶段。不建议在生产环境中使用。此功能可能在未提前通知的情况下进行更改。如发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能目前为实验性功能。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,54 +19,54 @@ summary: 学习如何将 TiDB Vector Search 与 Jina AI Embeddings API 集成， > **Note:** > -> 该向量搜索功能处于 beta 阶段，可能会在未提前通知的情况下进行更改。如发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能目前为 Beta 版本，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 该向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可使用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 及以上（推荐 v8.5.0 及以上）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 -## 前提条件 +## 前置条件 完成本教程，你需要： -- 安装 [Python 3.8 或更高版本](https://www.python.org/downloads/) -- 安装 [Git](https://git-scm.com/downloads) -- 拥有一个 TiDB 集群 +- 已安装 [Python 3.8 或更高版本](https://www.python.org/downloads/)。 +- 已安装 [Git](https://git-scm.com/downloads)。 +- 一个 TiDB 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 来创建本地集群。 -- 参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 +- 参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 -- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 来创建版本为 v8.4.0 或更高版本的本地集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建 v8.4.0 或更高版本的本地集群。 ## 运行示例应用 -你可以通过以下步骤快速了解如何将 TiDB Vector Search 与 JinaAI Embedding 集成。 +你可以按照以下步骤快速了解如何将 TiDB 向量检索与 JinaAI Embedding 集成。 -### 第一步：克隆仓库 +### 步骤 1. 克隆代码仓库 -将 `tidb-vector-python` 仓库克隆到你的本地机器： +将 `tidb-vector-python` 仓库克隆到本地： ```shell git clone https://github.com/pingcap/tidb-vector-python.git ``` -### 第二步：创建虚拟环境 +### 步骤 2. 创建虚拟环境 -为你的项目创建虚拟环境： +为你的项目创建一个虚拟环境： ```bash cd tidb-vector-python/examples/jina-ai-embeddings-demo @@ -74,52 +74,52 @@ python3 -m venv .venv source .venv/bin/activate ``` -### 第三步：安装依赖 +### 步骤 3. 安装依赖 -安装示例项目所需的依赖： +为示例项目安装所需依赖： ```bash pip install -r requirements.txt ``` -### 第四步：配置环境变量 +### 步骤 4. 配置环境变量 -从 [Jina AI Embeddings API](https://jina.ai/embeddings/) 页面获取你的 API 密钥，然后根据你选择的 TiDB 部署方式配置环境变量。 +从 [Jina AI Embeddings API](https://jina.ai/embeddings/) 页面获取 Jina AI API key，然后根据你选择的 TiDB 部署方式配置环境变量。 -
+
-对于 {{{ .starter }}} 集群，按照以下步骤获取集群连接字符串并配置环境变量： +对于 TiDB Cloud Starter 集群，按以下步骤获取集群连接串并配置环境变量： -1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群的名称进入其概览页面。 +1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入集群概览页。 2. 点击右上角的 **Connect**，弹出连接对话框。 -3. 确认连接对话框中的配置与您的操作环境一致。 +3. 确保连接对话框中的配置与你的操作环境一致。 - **Connection Type** 设置为 `Public` - **Branch** 设置为 `main` - **Connect With** 设置为 `SQLAlchemy` - - **Operating System** 与你的环境匹配。 + - **Operating System** 与你的环境一致 > **Tip:** > - > 如果你的程序在 Windows Subsystem for Linux (WSL) 中运行，请切换到对应的 Linux 发行版。 + > 如果你的程序运行在 Windows Subsystem for Linux (WSL) 中，请切换到对应的 Linux 发行版。 -4. 切换到 **PyMySQL** 标签页，点击 **Copy** 图标复制连接字符串。 +4. 切换到 **PyMySQL** 标签页，点击 **Copy** 图标复制连接串。 > **Tip:** > - > 如果还未设置密码，可以点击 **Create password** 生成一个随机密码。 + > 如果你还没有设置密码，请点击 **Create password** 生成随机密码。 -5. 在终端中将 Jina AI API 密钥和 TiDB 连接字符串设置为环境变量，或创建 `.env` 文件，内容如下： +5. 在终端中将 Jina AI API key 和 TiDB 连接串设置为环境变量，或创建一个包含如下环境变量的 `.env` 文件： ```dotenv JINAAI_API_KEY="****" TIDB_DATABASE_URL="{tidb_connection_string}" ``` - 下面是 macOS 的示例连接字符串： + 以下是 macOS 下的连接串示例： ```dotenv TIDB_DATABASE_URL="mysql+pymysql://.root:@gateway01..prod.aws.tidbcloud.com:4000/test?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" @@ -128,7 +128,7 @@ pip install -r requirements.txt
-对于 TiDB Self-Managed 集群，在你的终端中设置连接到 TiDB 集群的环境变量如下： +对于 TiDB 自建版集群，在终端中设置连接 TiDB 集群的环境变量： ```shell export JINA_API_KEY="****" @@ -136,21 +136,21 @@ export TIDB_DATABASE_URL="mysql+pymysql://:@:/` 默认为 `127.0.0.1`。初次启动集群时，`` 为空，可以省略。 +你需要根据自己的 TiDB 集群替换上述命令中的参数。如果你在本地运行 TiDB，`` 默认为 `127.0.0.1`。初始 `` 为空，如果是首次启动集群，可以省略该字段。 -以下是各参数的说明： +各参数说明如下： -- ``：连接 TiDB 集群的用户名。 -- ``：连接 TiDB 集群的密码。 -- ``：TiDB 集群的主机地址。 -- ``：TiDB 集群的端口。 -- ``：你要连接的数据库名称。 +- ``：连接 TiDB 集群的用户名 +- ``：连接 TiDB 集群的密码 +- ``：TiDB 集群的主机地址 +- ``：TiDB 集群的端口 +- ``：你要连接的数据库名称
-### 第五步：运行示例 +### 步骤 5. 运行示例 ```bash python jina-ai-embeddings-demo.py @@ -174,9 +174,9 @@ python jina-ai-embeddings-demo.py ## 示例代码片段 -### 获取 Jina AI 的嵌入向量 +### 从 Jina AI 获取向量 -定义一个 `generate_embeddings` 辅助函数，用于调用 Jina AI 嵌入 API： +定义 `generate_embeddings` 辅助函数调用 Jina AI 向量 API： ```python import os @@ -195,22 +195,21 @@ def generate_embeddings(text: str): } JINAAI_REQUEST_DATA = { 'input': [text], - 'model': 'jina-embeddings-v2-base-en' # 嵌入向量维度为 768。 + 'model': 'jina-embeddings-v2-base-en' # with dimension 768. } response = requests.post(JINAAI_API_URL, headers=JINAAI_HEADERS, json=JINAAI_REQUEST_DATA) return response.json()['data'][0]['embedding'] ``` -### 连接到 TiDB 集群 +### 连接 TiDB 集群 -通过 SQLAlchemy 连接到 TiDB 集群： +通过 SQLAlchemy 连接 TiDB 集群： ```python import os import dotenv from tidb_vector.sqlalchemy import VectorType -from sqlalchemy import create_engine from sqlalchemy.orm import Session, declarative_base dotenv.load_dotenv() @@ -222,7 +221,7 @@ engine = create_engine(url=TIDB_DATABASE_URL, pool_recycle=300) ### 定义向量表结构 -创建一个名为 `jinaai_tidb_demo_documents` 的表，包含存储文本的 `content` 列和存储嵌入向量的 `content_vec` 列： +创建名为 `jinaai_tidb_demo_documents` 的表，包含用于存储文本的 `content` 字段和用于存储向量的 `content_vec` 字段： ```python from sqlalchemy import Column, Integer, String, create_engine @@ -236,21 +235,20 @@ class Document(Base): id = Column(Integer, primary_key=True) content = Column(String(255), nullable=False) content_vec = Column( - # DIMENSIONS 由嵌入模型决定， - # 对于 Jina AI 的 jina-embeddings-v2-base-en 模型为 768。 + # DIMENSIONS is determined by the embedding model, + # for Jina AI's jina-embeddings-v2-base-en model it's 768. VectorType(dim=768), comment="hnsw(distance=cosine)" - ) ``` > **Note:** > -> - 向量列的维度必须与嵌入模型生成的嵌入向量维度一致。 -> - 在此示例中，`jina-embeddings-v2-base-en` 模型生成的嵌入向量维度为 `768`。 +> - 向量字段的维度必须与向量模型生成的向量维度一致。 +> - 本示例中，`jina-embeddings-v2-base-en` 模型生成的向量维度为 `768`。 -### 使用 Jina AI 生成嵌入向量并存入 TiDB +### 使用 Jina AI 生成向量并存储到 TiDB -利用 Jina AI Embeddings API 为每段文本生成嵌入向量，并存入 TiDB： +使用 Jina AI Embeddings API 为每条文本生成向量，并将向量存储到 TiDB： ```python TEXTS = [ @@ -260,7 +258,7 @@ TEXTS = [ data = [] for text in TEXTS: - # 通过 Jina AI API 生成文本的嵌入向量。 + # Generate embeddings for the texts via Jina AI API. embedding = generate_embeddings(text) data.append({ 'text': text, @@ -268,23 +266,23 @@ for text in TEXTS: }) with Session(engine) as session: - print('- Inserting Data to TiDB...') - for item in data: - print(f' - Inserting: {item["text"]}') - session.add(Document( - content=item['text'], - content_vec=item['embedding'] - )) - session.commit() + print('- Inserting Data to TiDB...') + for item in data: + print(f' - Inserting: {item["text"]}') + session.add(Document( + content=item['text'], + content_vec=item['embedding'] + )) + session.commit() ``` -### 在 TiDB 中使用 Jina AI 嵌入向量进行语义搜索 +### 在 TiDB 中使用 Jina AI 向量进行语义检索 -通过 Jina AI 嵌入 API 生成查询文本的嵌入向量，然后根据**查询文本的嵌入向量**与**向量表中的每个嵌入向量**的余弦距离，搜索最相关的文档： +通过 Jina AI 向量 API 为查询文本生成向量，然后基于 **查询文本的向量** 与 **向量表中每条数据的向量** 的余弦距离，检索最相关的文档： ```python query = 'What is TiDB?' -# 通过 Jina AI API 生成查询的嵌入向量。 +# Generate the embedding for the query via Jina AI API. query_embedding = generate_embeddings(query) with Session(engine) as session: @@ -299,7 +297,7 @@ with Session(engine) as session: f' content: {doc.content}') ``` -## 相关链接 +## 相关阅读 -- [Vector Data Types](/vector-search/vector-search-data-types.md) -- [Vector Search Index](/vector-search/vector-search-index.md) \ No newline at end of file +- [向量数据类型](/vector-search/vector-search-data-types.md) +- [向量检索索引](/vector-search/vector-search-index.md) diff --git a/vector-search/vector-search-integrate-with-langchain.md b/vector-search/vector-search-integrate-with-langchain.md index b9da54c6041cb..30836aff389fb 100644 --- a/vector-search/vector-search-integrate-with-langchain.md +++ b/vector-search/vector-search-integrate-with-langchain.md @@ -1,17 +1,17 @@ --- -title: 将向量搜索集成到 LangChain -summary: 学习如何将 TiDB 向量搜索与 LangChain 集成。 +title: 集成向量检索与 LangChain +summary: 学习如何将 TiDB 向量检索功能与 LangChain 集成。 --- -# 将向量搜索集成到 LangChain +# 集成向量检索与 LangChain -本教程演示如何将 [vector search](/vector-search/vector-search-overview.md) 功能的 TiDB 与 [LangChain](https://python.langchain.com/) 集成。 +本教程演示如何将 TiDB 的 [向量检索](/vector-search/vector-search-overview.md) 功能与 [LangChain](https://python.langchain.com/) 集成。 > **Warning:** > -> 向量搜索功能处于实验阶段。不建议在生产环境中使用。此功能可能在未通知的情况下进行更改。如发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能为实验性功能。不建议在生产环境中使用。该功能可能会在未提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,51 +19,51 @@ summary: 学习如何将 TiDB 向量搜索与 LangChain 集成。 > **Note:** > -> 向量搜索功能处于 beta 阶段，可能会在未通知的情况下进行更改。如发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能处于 beta 阶段，可能会在未提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可使用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 及以上（推荐 v8.5.0 及以上）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 及以上（推荐 v8.5.0 及以上）。 > **Tip** > -> 你可以在 Jupyter Notebook 上查看完整的 [示例代码](https://github.com/langchain-ai/langchain/blob/master/docs/docs/integrations/vectorstores/tidb_vector.ipynb)，也可以直接在 [Colab](https://colab.research.google.com/github/langchain-ai/langchain/blob/master/docs/docs/integrations/vectorstores/tidb_vector.ipynb) 在线环境中运行示例代码。 +> 你可以在 Jupyter Notebook 查看完整的 [示例代码](https://github.com/langchain-ai/langchain/blob/master/docs/docs/integrations/vectorstores/tidb_vector.ipynb)，或直接在 [Colab](https://colab.research.google.com/github/langchain-ai/langchain/blob/master/docs/docs/integrations/vectorstores/tidb_vector.ipynb) 在线环境中运行示例代码。 -## 前提条件 +## 前置条件 完成本教程，你需要： -- 安装 [Python 3.8 或更高版本](https://www.python.org/downloads/) -- 安装 [Jupyter Notebook](https://jupyter.org/install) -- 安装 [Git](https://git-scm.com/downloads) -- 拥有一个 TiDB 集群 +- 已安装 [Python 3.8 或更高版本](https://www.python.org/downloads/)。 +- 已安装 [Jupyter Notebook](https://jupyter.org/install)。 +- 已安装 [Git](https://git-scm.com/downloads)。 +- 一个 TiDB 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 来创建本地集群。 -- 参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 +- 参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 -- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 来创建版本为 v8.4.0 或更高版本的本地集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建 v8.4.0 或更高版本的本地集群。 -## 开始使用 +## 快速开始 -本节提供逐步指导，介绍如何将 TiDB 向量搜索与 LangChain 集成，实现语义搜索。 +本节将提供将 TiDB 向量检索与 LangChain 集成以实现语义检索的分步指导。 -### 步骤 1. 创建新的 Jupyter Notebook 文件 +### 步骤 1. 新建 Jupyter Notebook 文件 -在你偏好的目录下，创建一个名为 `integrate_with_langchain.ipynb` 的 Jupyter Notebook 文件： +在你喜欢的目录下，新建一个名为 `integrate_with_langchain.ipynb` 的 Jupyter Notebook 文件： ```shell touch integrate_with_langchain.ipynb @@ -71,7 +71,7 @@ touch integrate_with_langchain.ipynb ### 步骤 2. 安装所需依赖 -在你的项目目录下，运行以下命令安装所需的包： +在你的项目目录下，运行以下命令安装所需的依赖包： ```shell !pip install langchain langchain-community @@ -80,7 +80,7 @@ touch integrate_with_langchain.ipynb !pip install tidb-vector ``` -在 Jupyter Notebook 中打开 `integrate_with_langchain.ipynb` 文件，然后添加以下代码导入所需包： +在 Jupyter Notebook 中打开 `integrate_with_langchain.ipynb` 文件，然后添加以下代码以导入所需包： ```python from langchain_community.document_loaders import TextLoader @@ -89,45 +89,45 @@ from langchain_openai import OpenAIEmbeddings from langchain_text_splitters import CharacterTextSplitter ``` -### 步骤 3. 设置环境 +### 步骤 3. 配置环境 -根据你选择的 TiDB 部署方式，配置环境变量。 +根据你选择的 TiDB 部署方式配置环境变量。 -
+
-对于 {{{ .starter }}} 集群，按照以下步骤获取集群连接字符串并配置环境变量： +对于 TiDB Cloud Starter 集群，按以下步骤获取集群连接串并配置环境变量： -1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称，进入其概览页面。 +1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入集群概览页。 2. 点击右上角的 **Connect**，弹出连接对话框。 -3. 确认连接对话框中的配置与操作环境匹配。 +3. 确认连接对话框中的配置与你的操作环境一致。 - - **Connection Type** 设置为 `Public`。 - - **Branch** 设置为 `main`。 - - **Connect With** 设置为 `SQLAlchemy`。 + - **Connection Type** 选择为 `Public`。 + - **Branch** 选择为 `main`。 + - **Connect With** 选择为 `SQLAlchemy`。 - **Operating System** 与你的环境一致。 -4. 点击 **PyMySQL** 标签，复制连接字符串。 +4. 点击 **PyMySQL** 标签页并复制连接串。 > **Tip:** > - > 如果还未设置密码，可以点击 **Generate Password** 生成随机密码。 + > 如果你还未设置密码，可点击 **Generate Password** 生成随机密码。 5. 配置环境变量。 - 本文使用 [OpenAI](https://platform.openai.com/docs/introduction) 作为嵌入模型提供方。在此步骤中，你需要提供上一步获得的连接字符串和你的 [OpenAI API 密钥](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)。 + 本文档以 [OpenAI](https://platform.openai.com/docs/introduction) 作为嵌入模型提供方。在此步骤中，你需要提供上一步获取的连接串和你的 [OpenAI API key](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)。 - 运行以下代码配置环境变量。系统会提示你输入连接字符串和 OpenAI API 密钥： + 运行以下代码配置环境变量。你将被提示输入连接串和 OpenAI API key： ```python - # 使用 getpass 在终端中安全提示输入环境变量。 + # 使用 getpass 在终端安全地输入环境变量。 import getpass import os - # 从 TiDB Cloud 控制台复制你的连接字符串。 - # 连接字符串格式："mysql+pymysql://:@:4000/?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" + # 从 TiDB Cloud 控制台复制你的连接串。 + # 连接串格式："mysql+pymysql://:@:4000/?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" tidb_connection_string = getpass.getpass("TiDB Connection String:") os.environ["OPENAI_API_KEY"] = getpass.getpass("OpenAI API Key:") ``` @@ -135,36 +135,36 @@ from langchain_text_splitters import CharacterTextSplitter
-本文件使用 [OpenAI](https://platform.openai.com/docs/introduction) 作为嵌入模型提供方。在此步骤中，你需要提供上一步获得的连接字符串和你的 [OpenAI API 密钥](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)。 +本文档以 [OpenAI](https://platform.openai.com/docs/introduction) 作为嵌入模型提供方。在此步骤中，你需要提供上一步获取的连接串和你的 [OpenAI API key](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)。 -运行以下代码配置环境变量。系统会提示你输入连接字符串和 OpenAI API 密钥： +运行以下代码配置环境变量。你将被提示输入连接串和 OpenAI API key： ```python -# 使用 getpass 在终端中安全提示输入环境变量。 +# 使用 getpass 在终端安全地输入环境变量。 import getpass import os -# 连接字符串格式："mysql+pymysql://:@:4000/?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" +# 连接串格式："mysql+pymysql://:@:4000/?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" tidb_connection_string = getpass.getpass("TiDB Connection String:") os.environ["OPENAI_API_KEY"] = getpass.getpass("OpenAI API Key:") ``` -以 macOS 为例，集群连接字符串如下： +以 macOS 为例，集群连接串如下： ```dotenv TIDB_DATABASE_URL="mysql+pymysql://:@:/" # 例如：TIDB_DATABASE_URL="mysql+pymysql://root@127.0.0.1:4000/test" ``` -你需要根据你的 TiDB 集群修改连接参数的值。如果在本地运行 TiDB，`` 默认为 `127.0.0.1`。初始的 `` 为空，如果首次启动集群，可以省略此字段。 +你需要根据你的 TiDB 集群实际情况修改连接参数的值。如果你在本地运行 TiDB，`` 默认为 `127.0.0.1`。初始 `` 为空，因此首次启动集群时可以省略该字段。 -以下是各参数的说明： +各参数说明如下： - ``：连接 TiDB 集群的用户名。 - ``：连接 TiDB 集群的密码。 - ``：TiDB 集群的主机地址。 -- ``：TiDB 集群的端口。 -- ``：要连接的数据库名。 +- ``：TiDB 集群的端口号。 +- ``：你要连接的数据库名称。
@@ -174,16 +174,16 @@ TIDB_DATABASE_URL="mysql+pymysql://:@:/ #### 选项 2：使用 `similarity_search_with_relevance_scores()` -`similarity_search_with_relevance_scores()` 方法返回相关性得分最高的前 `k` 个文档。得分越高，表示文档与查询的相似度越高。 +`similarity_search_with_relevance_scores()` 方法返回相关性分数最高的前 `k` 个文档。分数越高，文档与查询的相似度越高。 ```python docs_with_relevance_score = vector_store.similarity_search_with_relevance_scores(query, k=2) @@ -311,7 +325,7 @@ We’re securing commitments and supporting partners in South and Central Americ ### 作为检索器使用 -在 Langchain 中，[retriever](https://python.langchain.com/v0.2/docs/concepts/#retrievers) 是一种在响应非结构化查询时检索文档的接口，提供比向量存储更丰富的功能。以下代码演示如何将 TiDB 向量存储作为检索器使用。 +在 Langchain 中，[retriever](https://python.langchain.com/v0.2/docs/concepts/#retrievers) 是一个用于响应非结构化查询检索文档的接口，提供比向量存储更多的功能。以下代码演示如何将 TiDB 向量存储作为检索器使用。 ```python retriever = vector_store.as_retriever( @@ -339,27 +353,27 @@ And I did that 4 days ago, when I nominated Circuit Court of Appeals Judge Ketan -------------------------------------------------------------------------------- ``` -### 删除向量存储 +### 移除向量存储 -要删除已有的 TiDB 向量存储，可以使用 `drop_vectorstore()` 方法： +要移除已存在的 TiDB 向量存储，可使用 `drop_vectorstore()` 方法： ```python vector_store.drop_vectorstore() ``` -## 使用元数据过滤器进行搜索 +## 使用元数据过滤进行检索 -为了细化搜索，可以使用元数据过滤器，检索符合条件的最近邻结果。 +为了优化检索结果，你可以使用元数据过滤器，仅返回符合过滤条件的最近邻结果。 ### 支持的元数据类型 -TiDB 向量存储中的每个文档都可以配有元数据，结构为键值对的 JSON 对象。键始终为字符串，值可以是以下类型之一： +TiDB 向量存储中的每个文档都可以配有元数据，元数据以 JSON 对象中的键值对形式存储。键始终为字符串，值可以是以下类型之一： - 字符串 - 数值：整数或浮点数 - 布尔值：`true` 或 `false` -例如，以下是有效的元数据负载： +例如，以下是一个有效的元数据示例： ```json { @@ -370,18 +384,18 @@ TiDB 向量存储中的每个文档都可以配有元数据，结构为键值对 ### 元数据过滤语法 -支持的过滤器包括： +可用的过滤器包括： -- `$or`：匹配任意一个条件的向量 -- `$and`：匹配所有条件的向量 -- `$eq`：等于指定值 -- `$ne`：不等于指定值 -- `$gt`：大于指定值 -- `$gte`：大于等于指定值 -- `$lt`：小于指定值 -- `$lte`：小于等于指定值 -- `$in`：在指定数组中 -- `$nin`：不在指定数组中 +- `$or`：选择匹配任一条件的向量。 +- `$and`：选择同时匹配所有条件的向量。 +- `$eq`：等于指定值。 +- `$ne`：不等于指定值。 +- `$gt`：大于指定值。 +- `$gte`：大于等于指定值。 +- `$lt`：小于指定值。 +- `$lte`：小于等于指定值。 +- `$in`：在指定值数组中。 +- `$nin`：不在指定值数组中。 如果某个文档的元数据如下： @@ -392,7 +406,7 @@ TiDB 向量存储中的每个文档都可以配有元数据，结构为键值对 } ``` -则以下元数据过滤器可以匹配此文档： +以下元数据过滤器都可以匹配该文档： ```json { "page": 12 } @@ -425,7 +439,7 @@ TiDB 向量存储中的每个文档都可以配有元数据，结构为键值对 } ``` -在元数据过滤器中，TiDB 将每个键值对作为单独的过滤条件，并用 `AND` 逻辑操作符组合。 +在元数据过滤器中，TiDB 会将每个键值对视为一个独立的过滤条件，并使用 `AND` 逻辑操作符将这些条件组合。 ### 示例 @@ -434,12 +448,12 @@ TiDB 向量存储中的每个文档都可以配有元数据，结构为键值对 ```python vector_store.add_texts( texts=[ - "TiDB Vector 提供先进的高速向量处理能力，提升 AI 工作流中的数据处理和分析效率。", - "TiDB Vector，基础用量低至每月 10 美元起", + "TiDB Vector offers advanced, high-speed vector processing capabilities, enhancing AI workflows with efficient data handling and analytics support.", + "TiDB Vector, starting as low as $10 per month for basic usage", ], metadatas=[ - {"title": "TiDB Vector 功能"}, - {"title": "TiDB Vector 价格"}, + {"title": "TiDB Vector functionality"}, + {"title": "TiDB Vector Pricing"}, ], ) ``` @@ -451,11 +465,11 @@ vector_store.add_texts( UUID('08dcd2ba-9f16-4f29-a9b7-18141f8edae3')] ``` -执行带有元数据过滤的相似度搜索： +使用元数据过滤器进行相似度检索： ```python docs_with_score = vector_store.similarity_search_with_score( - "Introduction to TiDB Vector", filter={"title": "TiDB Vector 功能"}, k=4 + "Introduction to TiDB Vector", filter={"title": "TiDB Vector functionality"}, k=4 ) for doc, score in docs_with_score: print("-" * 80) @@ -469,25 +483,25 @@ for doc, score in docs_with_score: ```plain -------------------------------------------------------------------------------- Score: 0.12761409169211535 -TiDB Vector 提供先进的高速向量处理能力，提升 AI 工作流中的数据处理和分析效率。 +TiDB Vector offers advanced, high-speed vector processing capabilities, enhancing AI workflows with efficient data handling and analytics support. -------------------------------------------------------------------------------- ``` -## 高级用例示例：旅游代理 +## 高级用法示例：旅行社场景 -本节演示如何将向量搜索与 Langchain 集成，用于旅游代理的场景。目标是为客户创建个性化的旅游报告，帮助他们找到具有特定设施的机场，例如干净的休息室和素食选择。 +本节演示将向量检索与 Langchain 集成的旅行社场景。目标是为客户生成个性化旅行报告，帮助他们找到拥有特定设施（如干净的休息室和素食选项）的机场。 -流程包括两个主要步骤： +流程主要包括两个步骤： -1. 在机场评论中进行语义搜索，识别符合需求的机场代码。 -2. 执行 SQL 查询，将这些代码与航线信息合并，突出显示符合用户偏好的航空公司和目的地。 +1. 对机场评论进行语义检索，找出符合所需设施的机场代码。 +2. 执行 SQL 查询，将这些代码与航线信息关联，突出显示符合用户偏好的航空公司和目的地。 ### 准备数据 -首先，创建存储机场航线数据的表： +首先，创建一个用于存储机场航线数据的表： ```python -# 创建存储航班计划数据的表。 +# 创建用于存储航班计划数据的表。 vector_store.tidb_vector_client.execute( """CREATE TABLE airplan_routes ( id INT AUTO_INCREMENT PRIMARY KEY, @@ -503,7 +517,7 @@ vector_store.tidb_vector_client.execute( );""" ) -# 插入一些示例数据到 airplan_routes 和向量表。 +# 向 airplan_routes 和向量表中插入一些示例数据。 vector_store.tidb_vector_client.execute( """INSERT INTO airplan_routes ( airport_code, @@ -516,16 +530,16 @@ vector_store.tidb_vector_client.execute( price, layover ) VALUES - ('JFK', 'DL', 'LAX', '非直达 JFK 至 LAX。', '06:00:00', 5, 'Boeing 777', 299.99, '无'), - ('LAX', 'AA', 'ORD', '直达 LAX 至 ORD。', '04:00:00', 3, 'Airbus A320', 149.99, '无'), - ('EFGH', 'UA', 'SEA', '每日 SFO 至 SEA 航班。', '02:30:00', 7, 'Boeing 737', 129.99, '无'); + ('JFK', 'DL', 'LAX', 'Non-stop from JFK to LAX.', '06:00:00', 5, 'Boeing 777', 299.99, 'None'), + ('LAX', 'AA', 'ORD', 'Direct LAX to ORD route.', '04:00:00', 3, 'Airbus A320', 149.99, 'None'), + ('EFGH', 'UA', 'SEA', 'Daily flights from SFO to SEA.', '02:30:00', 7, 'Boeing 737', 129.99, 'None'); """ ) vector_store.add_texts( texts=[ - "干净的休息室和优质的素食餐饮选择。强烈推荐。", - "休息区座椅舒适，食物多样，包括素食。", - "小型机场，设施基本。", + "Clean lounges and excellent vegetarian dining options. Highly recommended.", + "Comfortable seating in lounge areas and diverse food selections, including vegetarian.", + "Small airport with basic facilities.", ], metadatas=[ {"airport_code": "JFK"}, @@ -543,16 +557,16 @@ vector_store.add_texts( UUID('f426747c-0f7b-4c62-97ed-3eeb7c8dd76e')] ``` -### 进行语义搜索 +### 执行语义检索 -以下代码搜索具有干净设施和素食选项的机场： +以下代码检索拥有干净设施和素食选项的机场： ```python retriever = vector_store.as_retriever( search_type="similarity_score_threshold", search_kwargs={"k": 3, "score_threshold": 0.85}, ) -semantic_query = "你能推荐一个有干净休息室和良好素食餐饮的美国机场吗？" +semantic_query = "Could you recommend a US airport with clean lounges and good vegetarian dining options?" reviews = retriever.invoke(semantic_query) for r in reviews: print("-" * 80) @@ -565,21 +579,21 @@ for r in reviews: ```plain -------------------------------------------------------------------------------- -干净的休息室和优质的素食餐饮选择。强烈推荐。 +Clean lounges and excellent vegetarian dining options. Highly recommended. {'airport_code': 'JFK'} -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- -休息区座椅舒适，食物多样，包括素食。 +Comfortable seating in lounge areas and diverse food selections, including vegetarian. {'airport_code': 'LAX'} -------------------------------------------------------------------------------- ``` -### 获取详细机场信息 +### 获取机场详细信息 -提取搜索结果中的机场代码，并查询数据库获取详细的航线信息： +从检索结果中提取机场代码，并查询数据库获取详细航线信息： ```python -# 提取元数据中的机场代码 +# 从元数据中提取机场代码 airport_codes = [review.metadata["airport_code"] for review in reviews] # 执行查询获取机场详细信息 @@ -593,13 +607,13 @@ airport_details.get("result") 预期输出如下： ```plain -[(1, 'JFK', 'DL', 'LAX', '非直达 JFK 至 LAX。', datetime.timedelta(seconds=21600), 5, 'Boeing 777', Decimal('299.99'), '无'), - (2, 'LAX', 'AA', 'ORD', '直达 LAX 至 ORD。', datetime.timedelta(seconds=14400), 3, 'Airbus A320', Decimal('149.99'), '无')] +[(1, 'JFK', 'DL', 'LAX', 'Non-stop from JFK to LAX.', datetime.timedelta(seconds=21600), 5, 'Boeing 777', Decimal('299.99'), 'None'), + (2, 'LAX', 'AA', 'ORD', 'Direct LAX to ORD route.', datetime.timedelta(seconds=14400), 3, 'Airbus A320', Decimal('149.99'), 'None')] ``` -### 简化流程 +### 流程简化 -或者，可以用一条 SQL 查询简化整个流程： +你也可以通过一条 SQL 查询简化整个流程： ```python search_query = f""" @@ -623,14 +637,14 @@ airport_details.get("result") 预期输出如下： ```plain -[(0.1219207353407008, 1, 'JFK', 'DL', 'LAX', '非直达 JFK 至 LAX。', datetime.timedelta(seconds=21600), 5, 'Boeing 777', Decimal('299.99'), '无', '干净的休息室和优质的素食餐饮选择。强烈推荐。'), - (0.14613754359804654, 2, 'LAX', 'AA', 'ORD', '直达 LAX 至 ORD。', datetime.timedelta(seconds=14400), 3, 'Airbus A320', Decimal('149.99'), '无', '休息区座椅舒适，食物多样，包括素食。'), - (0.19840519342700513, 3, 'EFGH', 'UA', 'SEA', '每日 SFO 至 SEA 航班。', datetime.timedelta(seconds=9000), 7, 'Boeing 737', Decimal('129.99'), '无', '小型机场，设施基本。')] +[(0.1219207353407008, 1, 'JFK', 'DL', 'LAX', 'Non-stop from JFK to LAX.', datetime.timedelta(seconds=21600), 5, 'Boeing 777', Decimal('299.99'), 'None', 'Clean lounges and excellent vegetarian dining options. Highly recommended.'), + (0.14613754359804654, 2, 'LAX', 'AA', 'ORD', 'Direct LAX to ORD route.', datetime.timedelta(seconds=14400), 3, 'Airbus A320', Decimal('149.99'), 'None', 'Comfortable seating in lounge areas and diverse food selections, including vegetarian.'), + (0.19840519342700513, 3, 'EFGH', 'UA', 'SEA', 'Daily flights from SFO to SEA.', datetime.timedelta(seconds=9000), 7, 'Boeing 737', Decimal('129.99'), 'None', 'Small airport with basic facilities.')] ``` ### 清理数据 -最后，删除创建的表： +最后，通过删除创建的表来清理资源： ```python vector_store.tidb_vector_client.execute("DROP TABLE airplan_routes") @@ -638,11 +652,11 @@ vector_store.tidb_vector_client.execute("DROP TABLE airplan_routes") 预期输出如下： -```json -{"success": True, "result": 0, "error": null} +```plain +{'success': True, 'result': 0, 'error': None} ``` -## 相关链接 +## 参见 -- [Vector Data Types](/vector-search/vector-search-data-types.md) -- [Vector Search Index](/vector-search/vector-search-index.md) +- [向量数据类型](/vector-search/vector-search-data-types.md) +- [向量检索索引](/vector-search/vector-search-index.md) diff --git a/vector-search/vector-search-integrate-with-llamaindex.md b/vector-search/vector-search-integrate-with-llamaindex.md index 935aa2c47288a..d6017ffd32365 100644 --- a/vector-search/vector-search-integrate-with-llamaindex.md +++ b/vector-search/vector-search-integrate-with-llamaindex.md @@ -1,9 +1,9 @@ --- -title: 将向量搜索集成到 LlamaIndex -summary: 学习如何将 TiDB 向量搜索与 LlamaIndex 集成。 +title: 集成 Vector Search 与 LlamaIndex +summary: 了解如何将 TiDB Vector Search 集成到 LlamaIndex 中。 --- -# 将向量搜索集成到 LlamaIndex +# 集成 Vector Search 与 LlamaIndex 本教程演示如何将 TiDB 的 [vector search](/vector-search/vector-search-overview.md) 功能与 [LlamaIndex](https://www.llamaindex.ai) 集成。 @@ -11,7 +11,7 @@ summary: 学习如何将 TiDB 向量搜索与 LlamaIndex 集成。 > **Warning:** > -> 向量搜索功能处于实验阶段。不建议在生产环境中使用此功能。此功能可能在未通知的情况下进行更改。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能目前为实验性功能。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,51 +19,51 @@ summary: 学习如何将 TiDB 向量搜索与 LlamaIndex 集成。 > **Note:** > -> 向量搜索功能处于测试版，可能会在未通知的情况下进行更改。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能目前为 beta 版本。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 或更高（推荐 v8.5.0 及以上）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 > **Tip** > -> 你可以在 Jupyter Notebook 上查看完整的 [示例代码](https://github.com/run-llama/llama_index/blob/main/docs/docs/examples/vector_stores/TiDBVector.ipynb)，也可以直接在 [Colab](https://colab.research.google.com/github/run-llama/llama_index/blob/main/docs/docs/examples/vector_stores/TiDBVector.ipynb) 在线环境中运行示例代码。 +> 你可以在 Jupyter Notebook 查看完整的 [示例代码](https://github.com/run-llama/llama_index/blob/main/docs/docs/examples/vector_stores/TiDBVector.ipynb)，或直接在 [Colab](https://colab.research.google.com/github/run-llama/llama_index/blob/main/docs/docs/examples/vector_stores/TiDBVector.ipynb) 在线环境中运行示例代码。 -## 前提条件 +## 前置条件 完成本教程，你需要： -- 安装 [Python 3.8 或更高版本](https://www.python.org/downloads/) -- 安装 [Jupyter Notebook](https://jupyter.org/install) -- 安装 [Git](https://git-scm.com/downloads) -- 一个 TiDB 集群 +- 已安装 [Python 3.8 或更高版本](https://www.python.org/downloads/)。 +- 已安装 [Jupyter Notebook](https://jupyter.org/install)。 +- 已安装 [Git](https://git-scm.com/downloads)。 +- 一个 TiDB 集群。 -**如果你还没有 TiDB 集群，可以按照以下步骤创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 来创建本地集群。 -- 参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 +- 参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 -**如果你还没有 TiDB 集群，可以按照以下步骤创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 -- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 来创建版本为 v8.4.0 或更高的本地集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建 v8.4.0 或更高版本的本地集群。 -## 开始使用 +## 快速开始 -本节提供逐步指导，帮助你将 TiDB 向量搜索与 LlamaIndex 集成，实现语义搜索。 +本节将为你提供将 TiDB Vector Search 与 LlamaIndex 集成以进行语义检索的分步指南。 ### 步骤 1. 创建新的 Jupyter Notebook 文件 -在根目录下，创建一个名为 `integrate_with_llamaindex.ipynb` 的 Jupyter Notebook 文件： +在项目根目录下，创建一个名为 `integrate_with_llamaindex.ipynb` 的 Jupyter Notebook 文件： ```shell touch integrate_with_llamaindex.ipynb @@ -71,14 +71,14 @@ touch integrate_with_llamaindex.ipynb ### 步骤 2. 安装所需依赖 -在你的项目目录下，运行以下命令安装所需的包： +在你的项目目录下，运行以下命令安装所需的依赖包： ```shell pip install llama-index-vector-stores-tidbvector pip install llama-index ``` -在 Jupyter Notebook 中打开 `integrate_with_llamaindex.ipynb` 文件，并添加以下代码导入所需包： +在 Jupyter Notebook 中打开 `integrate_with_llamaindex.ipynb` 文件，并添加以下代码以导入所需包： ```python import textwrap @@ -90,43 +90,43 @@ from llama_index.vector_stores.tidbvector import TiDBVectorStore ### 步骤 3. 配置环境变量 -根据你选择的 TiDB 部署方式，配置环境变量。 +根据你选择的 TiDB 部署方式配置环境变量。 -
+
-对于 {{{ .starter }}} 集群，按照以下步骤获取集群连接字符串并配置环境变量： +对于 TiDB Cloud Starter 集群，请按照以下步骤获取集群连接串并配置环境变量： -1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群的名称，进入其概览页面。 +1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，点击目标集群名称进入集群概览页。 2. 点击右上角的 **Connect**，弹出连接对话框。 -3. 确认连接对话框中的配置与操作环境匹配。 +3. 确保连接对话框中的配置与你的操作环境一致。 - **Connection Type** 设置为 `Public`。 - **Branch** 设置为 `main`。 - **Connect With** 设置为 `SQLAlchemy`。 - **Operating System** 与你的环境一致。 -4. 点击 **PyMySQL** 标签，复制连接字符串。 +4. 点击 **PyMySQL** 标签页并复制连接串。 > **Tip:** > - > 如果还未设置密码，可以点击 **Generate Password** 生成随机密码。 + > 如果你还未设置密码，可点击 **Generate Password** 生成随机密码。 5. 配置环境变量。 - 本文档使用 [OpenAI](https://platform.openai.com/docs/introduction) 作为嵌入模型提供商。在此步骤中，你需要提供上一步获取的连接字符串和你的 [OpenAI API 密钥](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)。 + 本文档以 [OpenAI](https://platform.openai.com/docs/introduction) 作为嵌入模型提供方为例。在此步骤中，你需要提供上一步获取的连接串和你的 [OpenAI API key](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)。 - 运行以下代码配置环境变量。系统会提示你输入连接字符串和 OpenAI API 密钥： + 运行以下代码配置环境变量。你将被提示输入连接串和 OpenAI API key： ```python - # 使用 getpass 在终端中安全提示输入环境变量。 + # 使用 getpass 在终端安全地输入环境变量。 import getpass import os - # 从 TiDB Cloud 控制台复制你的连接字符串。 - # 连接字符串格式："mysql+pymysql://:@:4000/?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" + # 从 TiDB Cloud 控制台复制你的连接串。 + # 连接串格式: "mysql+pymysql://:@:4000/?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" tidb_connection_string = getpass.getpass("TiDB Connection String:") os.environ["OPENAI_API_KEY"] = getpass.getpass("OpenAI API Key:") ``` @@ -134,35 +134,35 @@ from llama_index.vector_stores.tidbvector import TiDBVectorStore
-本文档使用 [OpenAI](https://platform.openai.com/docs/introduction) 作为嵌入模型提供商。在此步骤中，你需要提供你的 TiDB 集群连接字符串和你的 [OpenAI API 密钥](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)。 +本文档以 [OpenAI](https://platform.openai.com/docs/introduction) 作为嵌入模型提供方为例。在此步骤中，你需要提供 TiDB 集群的连接串和你的 [OpenAI API key](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)。 -运行以下代码配置环境变量。系统会提示你输入连接字符串和 OpenAI API 密钥： +运行以下代码配置环境变量。你将被提示输入连接串和 OpenAI API key： ```python -# 使用 getpass 在终端中安全提示输入环境变量。 +# 使用 getpass 在终端安全地输入环境变量。 import getpass import os -# 连接字符串格式："mysql+pymysql://:@:4000/?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" +# 连接串格式: "mysql+pymysql://:@:4000/?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" tidb_connection_string = getpass.getpass("TiDB Connection String:") os.environ["OPENAI_API_KEY"] = getpass.getpass("OpenAI API Key:") ``` -以 macOS 为例，集群连接字符串如下： +以 macOS 为例，集群连接串如下： ```dotenv TIDB_DATABASE_URL="mysql+pymysql://:@:/" -# 例如：TIDB_DATABASE_URL="mysql+pymysql://root@127.0.0.1:4000/test" +# 例如: TIDB_DATABASE_URL="mysql+pymysql://root@127.0.0.1:4000/test" ``` -你需要根据你的 TiDB 集群修改连接字符串中的参数。如果你在本地运行 TiDB，`` 默认为 `127.0.0.1`。初始的 `` 为空，如果首次启动集群，可以省略此字段。 +你需要根据自己的 TiDB 集群修改连接串中的参数。如果你在本地运行 TiDB，`` 默认为 `127.0.0.1`。初始 `` 为空，因此首次启动集群时可以省略该字段。 -以下是各参数的说明： +各参数说明如下： - ``：连接 TiDB 集群的用户名。 - ``：连接 TiDB 集群的密码。 - ``：TiDB 集群的主机地址。 -- ``：TiDB 集群的端口。 +- ``：TiDB 集群的端口号。 - ``：你要连接的数据库名称。
@@ -173,7 +173,7 @@ TIDB_DATABASE_URL="mysql+pymysql://:@:/ > **Warning:** > -> 该向量搜索功能处于实验阶段。不建议在生产环境中使用。此功能可能在未提前通知的情况下进行更改。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能为实验性功能。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,54 +19,54 @@ summary: 学习如何将 TiDB Vector Search 与 peewee 集成，用于存储嵌 > **Note:** > -> 该向量搜索功能处于测试版，可能会在未提前通知的情况下进行更改。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量检索功能处于 beta 阶段，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 该向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 及以上（推荐 v8.5.0 及以上）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 -## 前提条件 +## 前置条件 完成本教程，你需要： -- 安装 [Python 3.8 或更高版本](https://www.python.org/downloads/) -- 安装 [Git](https://git-scm.com/downloads) -- 一个 TiDB 集群 +- 已安装 [Python 3.8 或更高版本](https://www.python.org/downloads/)。 +- 已安装 [Git](https://git-scm.com/downloads)。 +- 一个 TiDB 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 来创建本地集群。 -- 参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 +- 参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 -**如果你还没有 TiDB 集群，可以按照以下方式创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 -- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 来创建版本为 v8.4.0 或更高版本的本地集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建 v8.4.0 或更高版本的本地集群。 ## 运行示例应用 -你可以通过以下步骤快速了解如何将 TiDB Vector Search 与 peewee 集成。 +你可以按照以下步骤快速了解如何将 TiDB 向量检索与 peewee 集成。 -### 第 1 步：克隆仓库 +### 步骤 1. 克隆代码仓库 -将 [`tidb-vector-python`](https://github.com/pingcap/tidb-vector-python) 仓库克隆到你的本地机器： +将 [`tidb-vector-python`](https://github.com/pingcap/tidb-vector-python) 仓库克隆到本地： ```shell git clone https://github.com/pingcap/tidb-vector-python.git ``` -### 第 2 步：创建虚拟环境 +### 步骤 2. 创建虚拟环境 -为你的项目创建虚拟环境： +为你的项目创建一个虚拟环境： ```bash cd tidb-vector-python/examples/orm-peewee-quickstart @@ -74,60 +74,60 @@ python3 -m venv .venv source .venv/bin/activate ``` -### 第 3 步：安装依赖 +### 步骤 3. 安装所需依赖 -安装示例项目所需的依赖： +为示例项目安装所需依赖： ```bash pip install -r requirements.txt ``` -或者，你也可以单独安装以下包： +或者，你也可以为你的项目单独安装以下包： ```bash pip install peewee pymysql python-dotenv tidb-vector ``` -### 第 4 步：配置环境变量 +### 步骤 4. 配置环境变量 -根据你选择的 TiDB 部署方式，配置环境变量。 +根据你选择的 TiDB 部署方式配置环境变量。 -
+
-对于 {{{ .starter }}} 集群，按照以下步骤获取集群连接字符串并配置环境变量： +对于 TiDB Cloud Starter 集群，按以下步骤获取集群连接字符串并配置环境变量： -1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群的名称，进入其概览页面。 +1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群名称进入集群概览页。 2. 点击右上角的 **Connect**，弹出连接对话框。 -3. 确认连接对话框中的配置与你的操作环境一致。 +3. 确保连接对话框中的配置与你的操作环境一致。 - **Connection Type** 设置为 `Public`。 - **Branch** 设置为 `main`。 - **Connect With** 设置为 `General`。 - - **Operating System** 与你的环境匹配。 + - **Operating System** 与你的环境一致。 > **Tip:** > - > 如果你的程序在 Windows Subsystem for Linux (WSL) 中运行，切换到对应的 Linux 发行版。 + > 如果你的程序运行在 Windows Subsystem for Linux (WSL) 中，请切换到对应的 Linux 发行版。 -4. 从连接对话框复制连接参数。 +4. 从连接对话框中复制连接参数。 > **Tip:** > - > 如果还未设置密码，可以点击 **Generate Password** 生成随机密码。 + > 如果你还没有设置密码，可以点击 **Generate Password** 生成一个随机密码。 -5. 在你的 Python 项目的根目录下，创建 `.env` 文件，并将连接参数粘贴到对应的环境变量中。 +5. 在你的 Python 项目根目录下创建 `.env` 文件，并将连接参数粘贴到对应的环境变量中。 - - `TIDB_HOST`: TiDB 集群的主机地址。 - - `TIDB_PORT`: TiDB 集群的端口。 - - `TIDB_USERNAME`: 连接 TiDB 集群的用户名。 - - `TIDB_PASSWORD`: 连接 TiDB 集群的密码。 - - `TIDB_DATABASE`: 要连接的数据库名。 - - `TIDB_CA_PATH`: 根证书文件的路径。 + - `TIDB_HOST`：TiDB 集群的主机地址。 + - `TIDB_PORT`：TiDB 集群的端口。 + - `TIDB_USERNAME`：连接 TiDB 集群的用户名。 + - `TIDB_PASSWORD`：连接 TiDB 集群的密码。 + - `TIDB_DATABASE`：要连接的数据库名。 + - `TIDB_CA_PATH`：根证书文件的路径。 - 下面是 macOS 的示例： + 以下是 macOS 的示例： ```dotenv TIDB_HOST=gateway01.****.prod.aws.tidbcloud.com @@ -141,7 +141,7 @@ pip install peewee pymysql python-dotenv tidb-vector
-对于 TiDB Self-Managed 集群，在你的 Python 项目的根目录下创建 `.env` 文件。将以下内容复制到 `.env` 文件中，并根据你的 TiDB 集群连接参数修改环境变量的值： +对于 TiDB 自建集群，在你的 Python 项目根目录下创建 `.env` 文件。将以下内容复制到 `.env` 文件中，并根据你的 TiDB 集群连接参数修改环境变量的值： ```dotenv TIDB_HOST=127.0.0.1 @@ -151,21 +151,21 @@ TIDB_PASSWORD= TIDB_DATABASE=test ``` -如果你在本地运行 TiDB，`TIDB_HOST` 默认为 `127.0.0.1`。初次启动集群时，`TIDB_PASSWORD` 默认为空，可以省略此字段。 +如果你在本地运行 TiDB，`TIDB_HOST` 默认为 `127.0.0.1`。初始的 `TIDB_PASSWORD` 为空，因此如果你是首次启动集群，可以省略该字段。 -以下是各参数的说明： +各参数说明如下： -- `TIDB_HOST`: TiDB 集群的主机地址。 -- `TIDB_PORT`: TiDB 集群的端口。 -- `TIDB_USERNAME`: 连接 TiDB 集群的用户名。 -- `TIDB_PASSWORD`: 连接 TiDB 集群的密码。 -- `TIDB_DATABASE`: 你要连接的数据库名称。 +- `TIDB_HOST`：TiDB 集群的主机地址。 +- `TIDB_PORT`：TiDB 集群的端口。 +- `TIDB_USERNAME`：连接 TiDB 集群的用户名。 +- `TIDB_PASSWORD`：连接 TiDB 集群的密码。 +- `TIDB_DATABASE`：你要连接的数据库名称。
-### 第 5 步：运行示例 +### 步骤 5. 运行示例 ```bash python peewee-quickstart.py @@ -190,11 +190,11 @@ Get documents within a certain distance: ## 示例代码片段 -你可以参考以下示例代码片段，开发你的应用。 +你可以参考以下示例代码片段开发你的应用。 ### 创建向量表 -#### 连接到 TiDB 集群 +#### 连接 TiDB 集群 ```python import os @@ -205,17 +205,17 @@ from tidb_vector.peewee import VectorField dotenv.load_dotenv() -# 使用 `pymysql` 作为驱动 +# Using `pymysql` as the driver. connect_kwargs = { 'ssl_verify_cert': True, 'ssl_verify_identity': True, } -# 使用 `mysqlclient` 作为驱动 +# Using `mysqlclient` as the driver. # connect_kwargs = { # 'ssl_mode': 'VERIFY_IDENTITY', # 'ssl': { -# # 根证书默认路径 +# # Root certificate default path # # https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters/#root-certificate-default-path # 'ca': os.environ.get('TIDB_CA_PATH', '/path/to/ca.pem'), # }, @@ -233,7 +233,7 @@ db = MySQLDatabase( #### 定义向量列 -创建一个名为 `peewee_demo_documents` 的表，包含存储 3 维向量的列。 +创建一个包含名为 `peewee_demo_documents` 的表，并存储 3 维向量。 ```python class Document(Model): @@ -245,7 +245,7 @@ class Document(Model): embedding = VectorField(3) ``` -### 存储带有嵌入向量的文档 +### 存储带嵌入向量的文档 ```python Document.create(content='dog', embedding=[1, 2, 1]) @@ -253,18 +253,18 @@ Document.create(content='fish', embedding=[1, 2, 4]) Document.create(content='tree', embedding=[1, 0, 0]) ``` -### 搜索语义最接近的邻居文档 +### 检索最近邻文档 -根据余弦距离函数，搜索与查询向量 `[1, 2, 3]` 语义最接近的前 3 个文档。 +基于余弦距离函数，检索与查询向量 `[1, 2, 3]` 语义最接近的前 3 个文档。 ```python distance = Document.embedding.cosine_distance([1, 2, 3]).alias('distance') results = Document.select(Document, distance).order_by(distance).limit(3) ``` -### 搜索距离在一定范围内的文档 +### 检索距离在指定范围内的文档 -搜索与查询向量 `[1, 2, 3]` 的余弦距离小于 0.2 的文档。 +检索与查询向量 `[1, 2, 3]` 的余弦距离小于 0.2 的文档。 ```python distance_expression = Document.embedding.cosine_distance([1, 2, 3]) @@ -272,7 +272,7 @@ distance = distance_expression.alias('distance') results = Document.select(Document, distance).where(distance_expression < 0.2).order_by(distance).limit(3) ``` -## 相关链接 +## 参见 -- [Vector Data Types](/vector-search/vector-search-data-types.md) -- [Vector Search Index](/vector-search/vector-search-index.md) +- [向量数据类型](/vector-search/vector-search-data-types.md) +- [向量检索索引](/vector-search/vector-search-index.md) diff --git a/vector-search/vector-search-integrate-with-sqlalchemy.md b/vector-search/vector-search-integrate-with-sqlalchemy.md index aa221c671d06c..0ba6d42d78a2e 100644 --- a/vector-search/vector-search-integrate-with-sqlalchemy.md +++ b/vector-search/vector-search-integrate-with-sqlalchemy.md @@ -1,17 +1,17 @@ --- -title: 将 TiDB Vector Search 与 SQLAlchemy 集成 -summary: 学习如何将 TiDB Vector Search 与 SQLAlchemy 集成，用于存储嵌入向量和执行语义搜索。 +title: 集成 TiDB Vector Search 与 SQLAlchemy +summary: 学习如何将 TiDB Vector Search 与 SQLAlchemy 集成，以存储嵌入向量并执行语义搜索。 --- -# 将 TiDB Vector Search 与 SQLAlchemy 集成 +# 集成 TiDB Vector Search 与 SQLAlchemy -本教程将引导你如何使用 [SQLAlchemy](https://www.sqlalchemy.org/) 与 [TiDB Vector Search](/vector-search/vector-search-overview.md) 交互，存储嵌入向量，并执行向量搜索查询。 +本教程将指导你如何使用 [SQLAlchemy](https://www.sqlalchemy.org/) 与 [TiDB Vector Search](/vector-search/vector-search-overview.md) 进行交互，存储嵌入向量，并执行向量搜索查询。 > **Warning:** > -> 该向量搜索功能处于实验阶段。不建议在生产环境中使用。此功能可能会在不提前通知的情况下进行更改。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量搜索功能为实验性功能。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,52 +19,52 @@ summary: 学习如何将 TiDB Vector Search 与 SQLAlchemy 集成，用于存储 > **Note:** > -> 该向量搜索功能处于测试版，可能会在不提前通知的情况下进行更改。如果你发现 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 +> 向量搜索功能处于 beta 阶段，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> 该向量搜索功能在 TiDB Self-Managed、[{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) 上均可使用。对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 及以上（建议使用 v8.5.0 及以上版本）。 +> 向量搜索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 -## 前提条件 +## 前置条件 完成本教程，你需要： -- 安装 [Python 3.8 或更高版本](https://www.python.org/downloads/) -- 安装 [Git](https://git-scm.com/downloads) -- 一个 TiDB 集群 +- 已安装 [Python 3.8 或更高版本](https://www.python.org/downloads/)。 +- 已安装 [Git](https://git-scm.com/downloads)。 +- 一个 TiDB 集群。 -**如果你还没有 TiDB 集群，可以按照以下步骤创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 来创建本地集群。 -- 参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](/quick-start-with-tidb.md#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](/production-deployment-using-tiup.md) 创建本地集群。 +- 参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 -**如果你还没有 TiDB 集群，可以按照以下步骤创建：** +**如果你还没有 TiDB 集群，可以按如下方式创建：** -- （推荐）参考 [创建 {{{ .starter }}} 集群](/develop/dev-guide-build-cluster-in-cloud.md) 来创建你自己的 TiDB Cloud 集群。 -- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 来创建版本为 v8.4.0 或更高版本的本地集群。 +- （推荐）参考 [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md) 创建属于你自己的 TiDB Cloud 集群。 +- 参考 [部署本地测试 TiDB 集群](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb#deploy-a-local-test-cluster) 或 [部署生产环境 TiDB 集群](https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup) 创建 v8.4.0 或更高版本的本地集群。 ## 运行示例应用 -你可以通过以下步骤快速了解如何将 TiDB Vector Search 与 SQLAlchemy 集成。 +你可以按照以下步骤快速了解如何将 TiDB Vector Search 与 SQLAlchemy 集成。 -### 第 1 步：克隆仓库 +### 步骤 1. 克隆代码仓库 -将 `tidb-vector-python` 仓库克隆到你的本地机器： +将 `tidb-vector-python` 仓库克隆到本地： ```shell git clone https://github.com/pingcap/tidb-vector-python.git ``` -### 第 2 步：创建虚拟环境 +### 步骤 2. 创建虚拟环境 为你的项目创建一个虚拟环境： @@ -74,53 +74,53 @@ python3 -m venv .venv source .venv/bin/activate ``` -### 第 3 步：安装所需依赖 +### 步骤 3. 安装所需依赖 -安装示例项目所需的依赖： +为示例项目安装所需依赖： ```bash pip install -r requirements.txt ``` -或者，你也可以单独安装以下包： +或者，你也可以为你的项目单独安装以下包： ```bash pip install pymysql python-dotenv sqlalchemy tidb-vector ``` -### 第 4 步：配置环境变量 +### 步骤 4. 配置环境变量 -根据你选择的 TiDB 部署方式，配置环境变量。 +根据你选择的 TiDB 部署方式配置环境变量。 -
+
-对于 {{{ .starter }}} 集群，按照以下步骤获取集群连接字符串并配置环境变量： +对于 TiDB Cloud Starter 集群，请按照以下步骤获取集群连接字符串并配置环境变量： -1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群的名称，进入其概览页面。 +1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群名称进入集群概览页。 2. 点击右上角的 **Connect**，弹出连接对话框。 -3. 确认连接对话框中的配置与环境一致。 +3. 确保连接对话框中的配置与你的环境一致。 - **Connection Type** 设置为 `Public`。 - **Branch** 设置为 `main`。 - **Connect With** 设置为 `SQLAlchemy`。 - - **Operating System** 与你的环境匹配。 + - **Operating System** 与你的环境一致。 > **Tip:** > - > 如果你的程序在 Windows Subsystem for Linux (WSL) 中运行，切换到对应的 Linux 发行版。 + > 如果你的程序运行在 Windows Subsystem for Linux (WSL) 中，请切换到对应的 Linux 发行版。 -4. 点击 **PyMySQL** 标签页，复制连接字符串。 +4. 点击 **PyMySQL** 标签页并复制连接字符串。 > **Tip:** > - > 如果还没有设置密码，可以点击 **Generate Password** 生成随机密码。 + > 如果你还没有设置密码，可以点击 **Generate Password** 生成一个随机密码。 -5. 在你的 Python 项目的根目录下，创建 `.env` 文件，并将连接字符串粘贴进去。 +5. 在你的 Python 项目根目录下创建 `.env` 文件，并将连接字符串粘贴进去。 - 下面是 macOS 的示例： + 以下是 macOS 的示例： ```dotenv TIDB_DATABASE_URL="mysql+pymysql://.root:@gateway01..prod.aws.tidbcloud.com:4000/test?ssl_ca=/etc/ssl/cert.pem&ssl_verify_cert=true&ssl_verify_identity=true" @@ -129,28 +129,28 @@ pip install pymysql python-dotenv sqlalchemy tidb-vector
-对于 TiDB Self-Managed 集群，在你的 Python 项目的根目录下创建 `.env` 文件。将以下内容复制到 `.env` 文件中，并根据你的 TiDB 集群连接参数修改环境变量值： +对于 TiDB 自建集群，在你的 Python 项目根目录下创建 `.env` 文件。将以下内容复制到 `.env` 文件中，并根据你的 TiDB 集群连接参数修改环境变量的值： ```dotenv TIDB_DATABASE_URL="mysql+pymysql://:@:/" # 例如：TIDB_DATABASE_URL="mysql+pymysql://root@127.0.0.1:4000/test" ``` -如果你在本地运行 TiDB，`` 默认为 `127.0.0.1`。初次启动集群时，`` 默认为空，可以省略。 +如果你在本地运行 TiDB，`` 默认为 `127.0.0.1`。初始 `` 为空，因此如果你是首次启动集群，可以省略该字段。 -以下是各参数的说明： +各参数说明如下： - ``：连接 TiDB 集群的用户名。 - ``：连接 TiDB 集群的密码。 - ``：TiDB 集群的主机地址。 -- ``：TiDB 集群的端口。 +- ``：TiDB 集群的端口号。 - ``：你要连接的数据库名称。
-### 第 5 步：运行示例 +### 步骤 5. 运行示例 ```bash python sqlalchemy-quickstart.py @@ -175,11 +175,11 @@ Get documents within a certain distance: ## 示例代码片段 -你可以参考以下示例代码片段，开发你的应用。 +你可以参考以下示例代码片段开发你的应用。 ### 创建向量表 -#### 连接到 TiDB 集群 +#### 连接 TiDB 集群 ```python import os @@ -197,7 +197,7 @@ engine = create_engine(tidb_connection_string) #### 定义向量列 -创建一个表，包含名为 `embedding` 的列，用于存储 3 维向量。 +创建一个包含名为 `embedding` 的 3 维向量列的表。 ```python Base = declarative_base() @@ -209,7 +209,7 @@ class Document(Base): embedding = Column(VectorType(3)) ``` -### 存储带有嵌入向量的文档 +### 存储带嵌入向量的文档 ```python with Session(engine) as session: @@ -221,7 +221,7 @@ with Session(engine) as session: ### 搜索最近邻文档 -根据余弦距离函数，搜索与查询向量 `[1, 2, 3]` 语义最接近的前 3 个文档。 +基于余弦距离函数，搜索与查询向量 `[1, 2, 3]` 语义最接近的前 3 个文档。 ```python with Session(engine) as session: @@ -231,7 +231,7 @@ with Session(engine) as session: ).order_by(distance).limit(3).all() ``` -### 搜索距离在一定范围内的文档 +### 搜索距离在指定范围内的文档 搜索与查询向量 `[1, 2, 3]` 的余弦距离小于 0.2 的文档。 @@ -243,7 +243,7 @@ with Session(engine) as session: ).filter(distance < 0.2).order_by(distance).limit(3).all() ``` -## 相关链接 +## 参见 -- [Vector Data Types](/vector-search/vector-search-data-types.md) -- [Vector Search Index](/vector-search/vector-search-index.md) +- [向量数据类型](/vector-search/vector-search-data-types.md) +- [向量搜索索引](/vector-search/vector-search-index.md) diff --git a/vector-search/vector-search-integration-overview.md b/vector-search/vector-search-integration-overview.md index b56fc447c69fb..6bd7b006b4d14 100644 --- a/vector-search/vector-search-integration-overview.md +++ b/vector-search/vector-search-integration-overview.md @@ -1,17 +1,17 @@ --- -title: Vector Search Integration Overview -summary: 关于 TiDB 向量搜索集成的概述，包括支持的 AI 框架、嵌入模型和 ORM 库。 +title: 向量检索集成概览 +summary: TiDB 向量检索集成的概览，包括支持的 AI 框架、嵌入模型和 ORM 库。 --- -# Vector Search Integration Overview +# 向量检索集成概览 -本文档提供了 TiDB 向量搜索集成的概述，包括支持的 AI 框架、嵌入模型和对象关系映射（ORM）库。 +本文档提供了 TiDB 向量检索集成的概览，包括支持的 AI 框架、嵌入模型和对象关系映射（ORM）库。 > **Warning:** > -> The vector search feature is experimental. It is not recommended that you use it in the production environment. This feature might be changed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub. +> 向量检索功能为实验性功能。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,42 +19,42 @@ summary: 关于 TiDB 向量搜索集成的概述，包括支持的 AI 框架、 > **Note:** > -> The vector search feature is in beta. It might be changed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub. +> 向量检索功能处于 beta 阶段，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> The vector search feature is available on TiDB Self-Managed, [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless), and [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated). For TiDB Self-Managed and TiDB Cloud Dedicated, the TiDB 版本必须是 v8.4.0 或更高（建议 v8.5.0 或更高）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 及以上（推荐 v8.5.0 及以上）。 ## AI 框架 -TiDB 提供对以下 AI 框架的官方支持，方便你将基于这些框架开发的 AI 应用与 TiDB 向量搜索进行集成。 +TiDB 官方支持以下 AI 框架，帮助你轻松将基于这些框架开发的 AI 应用与 TiDB 向量检索集成。 -| AI 框架 | 教程 | -|---------|---------------------------------------------------------------------------------------------------| -| Langchain | [将向量搜索与 LangChain 集成](/vector-search/vector-search-integrate-with-langchain.md) | -| LlamaIndex | [将向量搜索与 LlamaIndex 集成](/vector-search/vector-search-integrate-with-llamaindex.md) | +| AI 框架 | 教程 | +|--------------|------------------------------------------------------------------------------------------------------| +| Langchain | [Integrate Vector Search with LangChain](/vector-search/vector-search-integrate-with-langchain.md) | +| LlamaIndex | [Integrate Vector Search with LlamaIndex](/vector-search/vector-search-integrate-with-llamaindex.md) | -此外，你还可以使用 TiDB 进行多种用途，例如文档存储和知识图谱存储，以支持 AI 应用。 +此外，你还可以将 TiDB 用于多种用途，例如作为 AI 应用的文档存储和知识图谱存储。 -## 嵌入模型和服务 +## 嵌入模型与服务 -TiDB 向量搜索支持存储最多 16383 维的向量，满足大部分嵌入模型的需求。 +TiDB 向量检索支持存储最多 16383 维的向量，能够满足大多数嵌入模型的需求。 -你可以使用自行部署的开源嵌入模型，或第三方嵌入提供商提供的 API 来生成向量。 +你可以选择自部署开源嵌入模型，或使用第三方嵌入服务商提供的嵌入 API 来生成向量。 -下表列出一些主流的嵌入服务提供商及对应的集成教程。 +下表列出了一些主流的嵌入服务商及其对应的集成教程。 -| 嵌入服务提供商 | 教程 | -|----------------|--------------------------------------------------------------------------------------------------------------| -| Jina AI | [将向量搜索与 Jina AI Embeddings API 集成](/vector-search/vector-search-integrate-with-jinaai-embedding.md) | +| 嵌入服务商 | 教程 | +|--------------|-------------------------------------------------------------------------------------------------------------------| +| Jina AI | [Integrate Vector Search with Jina AI Embeddings API](/vector-search/vector-search-integrate-with-jinaai-embedding.md) | ## 对象关系映射（ORM）库 -你可以将 TiDB 向量搜索与 ORM 库集成，以便与 TiDB 数据库交互。 +你可以将 TiDB 向量检索与 ORM 库集成，以便与 TiDB 数据库进行交互。 -下表列出支持的 ORM 库及对应的集成教程： +下表列出了支持的 ORM 库及其对应的集成教程： @@ -67,21 +67,21 @@ TiDB 向量搜索支持存储最多 16383 维的向量，满足大部分嵌入 - + - + - + - +
Python TiDB Vector Client pip install tidb-vector[client]使用 Python 开始向量搜索Get Started with Vector Search Using Python
SQLAlchemy pip install tidb-vector将 TiDB 向量搜索与 SQLAlchemy 集成Integrate TiDB Vector Search with SQLAlchemy
peewee pip install tidb-vector将 TiDB 向量搜索与 peewee 集成Integrate TiDB Vector Search with peewee
Django pip install django-tidb[vector]将 TiDB 向量搜索与 Django 集成Integrate TiDB Vector Search with Django
\ No newline at end of file diff --git a/vector-search/vector-search-limitations.md b/vector-search/vector-search-limitations.md index 63eb9076af32a..732cbda95df42 100644 --- a/vector-search/vector-search-limitations.md +++ b/vector-search/vector-search-limitations.md @@ -1,9 +1,9 @@ --- -title: 向量检索的限制 +title: 向量检索限制 summary: 了解 TiDB 向量检索的限制。 --- -# 向量检索的限制 +# 向量检索限制 本文档介绍了 TiDB 向量检索已知的限制。 @@ -25,9 +25,9 @@ summary: 了解 TiDB 向量检索的限制。 > **Note:** > -> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 及以上（推荐 v8.5.0 及以上）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 或更高（推荐使用 v8.5.0 或更高版本）。 -## 向量数据类型的限制 +## 向量数据类型限制 - 每个 [vector](/vector-search/vector-search-data-types.md) 最多支持 16383 维。 - 向量数据类型无法存储 `NaN`、`Infinity` 或 `-Infinity` 值。 @@ -37,7 +37,7 @@ summary: 了解 TiDB 向量检索的限制。 - 向量列不能作为分区键或分区键的一部分。 - 目前，TiDB 不支持将向量列修改为其他数据类型（如 `JSON` 和 `VARCHAR`）。 -## 向量索引的限制 +## 向量索引限制 参见 [向量检索限制](/vector-search/vector-search-index.md#restrictions)。 @@ -47,7 +47,7 @@ summary: 了解 TiDB 向量检索的限制。 - 请确保你使用的是 v8.4.0 或更高版本的 BR 进行数据备份和恢复。不支持将包含向量数据类型的表恢复到 v8.4.0 之前的 TiDB 集群。 - TiDB Data Migration (DM) 不支持将 MySQL 向量数据类型迁移或同步到 TiDB。 -- 当 TiCDC 将向量数据同步到不支持向量数据类型的下游时，会将向量数据类型转换为其他类型。更多信息请参见 [与向量数据类型的兼容性](/ticdc/ticdc-compatibility.md#compatibility-with-vector-data-types)。 +- 当 TiCDC 将向量数据同步到不支持向量数据类型的下游时，会将向量数据类型转换为其他类型。更多信息，参见 [与向量数据类型的兼容性](/ticdc/ticdc-compatibility.md#compatibility-with-vector-data-types)。 diff --git a/vector-search/vector-search-overview.md b/vector-search/vector-search-overview.md index d18f09856932e..f3271da76416e 100644 --- a/vector-search/vector-search-overview.md +++ b/vector-search/vector-search-overview.md @@ -1,17 +1,17 @@ --- -title: Vector Search 概览 -summary: 了解 TiDB 中的 Vector Search。该功能提供了一种先进的搜索解决方案，用于在各种数据类型（包括文档、图片、音频和视频）中执行语义相似性搜索。 +title: 向量检索概述 +summary: 了解 TiDB 中的向量检索功能。该功能为文档、图片、音频和视频等多种数据类型提供了先进的语义相似性检索解决方案。 --- -# Vector Search 概览 +# 向量检索概述 -Vector search 为跨多种数据类型（如文档、图片、音频和视频）提供了一种强大的语义相似性搜索解决方案。它允许开发者利用他们的 MySQL 专业知识，构建具有生成式 AI 功能的可扩展应用，简化了高级搜索功能的集成。 +向量检索为文档、图片、音频和视频等多种数据类型的语义相似性检索提供了强大的解决方案。它允许开发者利用 MySQL 的专业知识，构建具备生成式 AI 能力的可扩展应用，简化高级检索功能的集成。 > **Warning:** > -> The vector search feature is experimental. It is not recommended that you use it in the production environment. This feature might be changed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub. +> 向量检索功能为实验性功能。不建议在生产环境中使用。该功能可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 @@ -19,70 +19,70 @@ Vector search 为跨多种数据类型（如文档、图片、音频和视频） > **Note:** > -> The vector search feature is in beta. It might be changed without prior notice. If you find a bug, you can report an [issue](https://github.com/pingcap/tidb/issues) on GitHub. +> 向量检索功能处于 beta 阶段，可能会在没有提前通知的情况下发生变更。如果你发现了 bug，可以在 GitHub 上提交 [issue](https://github.com/pingcap/tidb/issues)。 > **Note:** > -> The vector search feature is available on TiDB Self-Managed, [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-serverless), and [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated). 对于 TiDB Self-Managed 和 TiDB Cloud Dedicated，TiDB 版本必须为 v8.4.0 或更高（建议 v8.5.0 或更高）。 +> 向量检索功能适用于 TiDB 自建版、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)、[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) 和 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)。对于 TiDB 自建版和 TiDB Cloud Dedicated，TiDB 版本需为 v8.4.0 或更高（推荐 v8.5.0 或更高）。 ## 概念 -Vector search 是一种以数据的语义为优先的搜索方法，旨在提供相关性更高的结果。 +向量检索是一种以数据语义为核心、返回相关结果的检索方法。 -不同于依赖精确关键词匹配和词频的传统全文搜索，vector search 将各种数据类型（如文本、图片或音频）转换为高维向量，并基于这些向量之间的相似性进行查询。这种搜索方式捕捉了数据的语义含义和上下文信息，从而实现对用户意图的更精准理解。 +与传统的全文检索依赖于精确的关键词匹配和词频不同，向量检索会将多种数据类型（如文本、图片或音频）转换为高维向量，并基于这些向量之间的相似性进行查询。这种检索方式能够捕捉数据的语义含义和上下文信息，从而更准确地理解用户意图。 -即使搜索词与数据库中的内容不完全匹配，vector search 仍能通过分析数据的语义，提供符合用户意图的结果。 +即使检索词与数据库中的内容并不完全匹配，向量检索也可以通过分析数据的语义，返回符合用户意图的结果。 -例如，全文搜索“a swimming animal” 只会返回包含这些关键词的结果。而 vector search 可以返回其他会游泳的动物，比如鱼或鸭子，即使这些结果不包含完全相同的关键词。 +例如，全文检索 “a swimming animal” 只会返回包含这些精确关键词的结果。而向量检索则可以返回其他游泳动物（如鱼或鸭子）的结果，即使这些结果中并不包含完全相同的关键词。 -### Vector embedding +### 向量嵌入 -Vector embedding，也称为 embedding，是一组用以表示现实世界对象的数字序列，存在于高维空间中。它捕捉非结构化数据（如文档、图片、音频和视频）的含义和上下文。 +向量嵌入（vector embedding），也称为 embedding，是一组数字序列，用于在高维空间中表示现实世界的对象。它能够捕捉非结构化数据（如文档、图片、音频和视频）的语义和上下文信息。 -Vector embedding 在机器学习中至关重要，是实现语义相似性搜索的基础。 +向量嵌入在机器学习中至关重要，是语义相似性检索的基础。 -TiDB 引入了 [Vector data types](/vector-search/vector-search-data-types.md) 和 [Vector search index](/vector-search/vector-search-index.md)，旨在优化向量 embedding 的存储与检索，增强其在 AI 应用中的使用效果。你可以在 TiDB 中存储 vector embedding，并通过这些数据类型执行 vector search 查询，以找到最相关的数据。 +TiDB 引入了 [向量数据类型](/vector-search/vector-search-data-types.md) 和 [向量检索索引](/vector-search/vector-search-index.md)，专为优化向量嵌入的存储与检索而设计，提升其在 AI 应用中的使用效率。你可以将向量嵌入存储在 TiDB 中，并通过这些数据类型执行向量检索查询，查找最相关的数据。 -### Embedding model +### 嵌入模型 -Embedding model 是将数据转换为 [vector embedding](#vector-embedding) 的算法。 +嵌入模型（embedding model）是一种将数据转换为 [向量嵌入](#vector-embedding) 的算法。 -选择合适的 embedding model 对确保语义搜索结果的准确性和相关性至关重要。对于非结构化文本数据，你可以在 [Massive Text Embedding Benchmark (MTEB) Leaderboard](https://huggingface.co/spaces/mteb/leaderboard) 上找到表现优异的文本 embedding 模型。 +选择合适的嵌入模型对于确保语义检索结果的准确性和相关性至关重要。对于非结构化文本数据，你可以在 [Massive Text Embedding Benchmark (MTEB) Leaderboard](https://huggingface.co/spaces/mteb/leaderboard) 上找到表现最优的文本嵌入模型。 -若要了解如何为你的特定数据类型生成 vector embedding，请参考集成教程或 embedding 模型的示例。 +如需了解如何为你的特定数据类型生成向量嵌入，请参考集成教程或嵌入模型的示例。 -## Vector search 的工作原理 +## 向量检索的工作原理 -将原始数据转换为 vector embedding 并存储在 TiDB 后，你的应用可以执行 vector search 查询，以找到与用户查询在语义或上下文上最相关的数据。 +在将原始数据转换为向量嵌入并存储到 TiDB 后，你的应用可以执行向量检索查询，查找与用户查询在语义或上下文上最相关的数据。 -TiDB 的 vector search 通过使用 [distance function](/vector-search/vector-search-functions-and-operators.md) 计算给定向量与数据库中存储的向量之间的距离，从而识别前 k 个最近邻（KNN）向量。距离最接近的向量代表在意义上最相似的数据。 +TiDB 向量检索通过使用 [距离函数](/vector-search/vector-search-functions-and-operators.md) 计算给定向量与数据库中已存向量之间的距离，从而识别出 top-k 最近邻（KNN）向量。与查询向量距离最近的向量，代表在语义上最相似的数据。 ![The Schematic TiDB Vector Search](/media/vector-search/embedding-search.png) -作为具有集成 vector search 功能的关系型数据库，TiDB 允许你将数据及其对应的向量表示（即 vector embedding）存储在同一数据库中。你可以选择以下存储方式： +作为一款集成了向量检索能力的关系型数据库，TiDB 允许你将数据及其对应的向量表示（即向量嵌入）一同存储在同一个数据库中。你可以选择以下任意一种存储方式： -- 将数据及其对应的 vector 表示存储在同一表的不同列中。 -- 将数据及其对应的 vector 表示存储在不同的表中。在这种情况下，检索数据时需要使用 `JOIN` 查询将表连接起来。 +- 在同一张表的不同列中存储数据及其对应的向量表示。 +- 在不同的表中分别存储数据及其对应的向量表示。此时，在检索数据时需要通过 `JOIN` 查询将表进行关联。 ## 应用场景 -### Retrieval-Augmented Generation (RAG) +### 检索增强生成（RAG） -Retrieval-Augmented Generation（RAG）是一种旨在优化大型语言模型（LLMs）输出的架构。通过使用 vector search，RAG 应用可以在数据库中存储 vector embedding，并在 LLM 生成响应时检索相关文档作为额外上下文，从而提升答案的质量和相关性。 +检索增强生成（Retrieval-Augmented Generation，RAG）是一种旨在优化大语言模型（LLM）输出的架构。通过向量检索，RAG 应用可以将向量嵌入存储在数据库中，并在 LLM 生成响应时检索相关文档作为额外上下文，从而提升答案的质量和相关性。 -### Semantic search +### 语义检索 -语义搜索是一种基于查询含义返回结果的搜索技术，而非仅仅匹配关键词。它利用 embedding 解释不同语言和各种数据类型（如文本、图片和音频）中的含义。然后，vector search 算法使用这些 embedding 来找到最符合用户查询的相关数据。 +语义检索是一种基于查询语义返回结果的检索技术，而不仅仅是简单的关键词匹配。它通过嵌入技术理解不同语言和多种数据类型（如文本、图片和音频）中的含义。向量检索算法随后利用这些嵌入，查找最能满足用户查询需求的相关数据。 -### Recommendation engine +### 推荐引擎 -推荐引擎是一种主动向用户推荐内容、产品或服务的系统。它通过创建代表用户行为和偏好的 embedding，帮助系统识别其他用户互动或感兴趣的类似项目。这增加了推荐的相关性和吸引力。 +推荐引擎是一种能够主动为用户推荐相关且个性化内容、产品或服务的系统。它通过创建表示用户行为和偏好的嵌入，帮助系统识别其他用户曾经互动或感兴趣的相似项目，从而提升推荐的相关性和吸引力。 -## 相关链接 +## 参见 -若要开始使用 TiDB Vector Search，请参考以下文档： +如需开始使用 TiDB 向量检索，请参阅以下文档： -- [Get started with vector search using Python](/vector-search/vector-search-get-started-using-python.md) -- [Get started with vector search using SQL](/vector-search/vector-search-get-started-using-sql.md) +- [使用 Python 快速上手向量检索](/vector-search/vector-search-get-started-using-python.md) +- [使用 SQL 快速上手向量检索](/vector-search/vector-search-get-started-using-sql.md) \ No newline at end of file