diff --git a/TOC.md b/TOC.md
index 27c6bef70950..6813e45faf7b 100644
--- a/TOC.md
+++ b/TOC.md
@@ -257,7 +257,10 @@
     - [基于主备集群的容灾](/dr-secondary-cluster.md)
     - [基于多副本的单集群容灾](/dr-multi-replica.md)
     - [基于备份与恢复的容灾](/dr-backup-restore.md)
-  - [使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)
+  - 资源管控
+    - [使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)
+    - [管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control-runaway-queries.md)
+    - [限制后台任务资源使用](/tidb-resource-control-background-tasks.md)
   - [修改时区](/configure-time-zone.md)
   - [日常巡检](/daily-check.md)
   - [TiFlash 常用运维操作](/tiflash/maintain-tiflash.md)
diff --git a/basic-features.md b/basic-features.md
index 9a484e5acca9..5d43b9ab6c3d 100644
--- a/basic-features.md
+++ b/basic-features.md
@@ -256,9 +256,9 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0
 | [全局内存控制](/configure-memory-usage.md#如何配置-tidb-server-实例使用内存的阈值) | Y | Y | Y | Y | Y | N | N | N | N | N |
 | [RawKV 跨集群复制](/tikv-configuration-file.md#api-version-从-v610-版本开始引入) | E | E | E| E | E | N | N | N | N | N |
 | [Green GC](/system-variables.md#tidb_gc_scan_lock_mode-从-v50-版本开始引入) | E | E | E | E | E | E | E | E | E | E |
-| [资源管控 (Resource Control)](/tidb-resource-control.md) | Y | Y | Y | Y | N | N | N | N | N | N |
-| [Runaway Queries 自动管理](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries) | Y | Y | E | N | N | N | N | N | N | N |
-| [后台任务资源管控](/tidb-resource-control.md#管理后台任务) | E | E | E | N | N | N | N | N | N | N |
+| [资源管控 (Resource Control)](/tidb-resource-control-ru-groups.md) | Y | Y | Y | Y | N | N | N | N | N | N |
+| [Runaway Queries 自动管理](/tidb-resource-control-runaway-queries.md) | Y | Y | E | N | N | N | N | N | N | N |
+| [后台任务资源管控](/tidb-resource-control-background-tasks.md) | E | E | E | N | N | N | N | N | N | N |
 | [TiFlash 存算分离架构与 S3 支持](/tiflash/tiflash-disaggregated-and-s3.md) | Y | Y | Y | E | N | N | N | N | N | N |
 | [选择执行分布式执行框架任务的 TiDB 节点](/system-variables.md#tidb_service_scope-从-v740-版本开始引入) | Y | Y | Y | N | N | N | N | N | N | N |
 | 通过系统变量 [`tidb_enable_tso_follower_proxy`](/system-variables.md#tidb_enable_tso_follower_proxy-从-v530-版本开始引入) 控制 PD Follower Proxy 功能 | Y | Y | Y | Y | Y | Y | Y | Y | N | N |
diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md
index 798f67342805..b741813a0b16 100644
--- a/dashboard/dashboard-intro.md
+++ b/dashboard/dashboard-intro.md
@@ -62,7 +62,7 @@ TiDB Dashboard 在 GitHub 上[开源](https://github.com/pingcap-incubator/tidb-
 
 ## 预估资源管控容量
 
-为使用[资源管控 (Resource Control)](/tidb-resource-control.md) 特性实现资源隔离，集群管理员可以定义资源组 (Resource Group)，通过资源组限定配额。
+为使用[资源管控 (Resource Control)](/tidb-resource-control-ru-groups.md) 特性实现资源隔离，集群管理员可以定义资源组 (Resource Group)，通过资源组限定配额。
 
 在进行资源规划之前，你需要了解集群的整体容量。参阅[资源管控页面](/dashboard/dashboard-resource-manager.md)了解详情。
 
diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md
index 4e2f4157485a..b2154a2bf37f 100644
--- a/dashboard/dashboard-resource-manager.md
+++ b/dashboard/dashboard-resource-manager.md
@@ -5,7 +5,7 @@ summary: 介绍如何使用 TiDB Dashboard 的资源管控页面查看资源管
 
 # TiDB Dashboard 资源管控页面
 
-为使用[资源管控 (Resource Control)](/tidb-resource-control.md) 特性实现资源隔离，集群管理员可以定义资源组 (Resource Group)，通过资源组限定配额。在进行资源规划之前，你需要了解集群的整体容量。该页面可以帮助你查看资源管控相关信息，以便预估集群容量，更好地进行资源配置。
+为使用[资源管控 (Resource Control)](/tidb-resource-control-ru-groups.md) 特性实现资源隔离，集群管理员可以定义资源组 (Resource Group)，通过资源组限定配额。在进行资源规划之前，你需要了解集群的整体容量。该页面可以帮助你查看资源管控相关信息，以便预估集群容量，更好地进行资源配置。
 
 ## 访问方式
 
@@ -34,7 +34,7 @@ summary: 介绍如何使用 TiDB Dashboard 的资源管控页面查看资源管
 
 ## 容量估算
 
-在进行资源规划之前，你需要了解集群的整体容量。目前提供两种估算方式预估当前集群的 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru#什么是-request-unit-ru) 的容量：
+在进行资源规划之前，你需要了解集群的整体容量。目前提供两种估算方式预估当前集群的 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru#什么是-request-unit-ru) 的容量：
 
 - [基于硬件部署估算容量](/sql-statements/sql-statement-calibrate-resource.md#基于硬件部署估算容量) (Calibrate by Hardware)
     
diff --git a/error-codes.md b/error-codes.md
index b8e14a9ec9a8..a3d92b50bf7f 100644
--- a/error-codes.md
+++ b/error-codes.md
@@ -404,7 +404,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样
 
 * Error Number: 8249
 
-    资源组不存在。在修改或绑定不存在的资源组时返回该错误。请参考[创建资源组](/tidb-resource-control.md#创建资源组)。
+    资源组不存在。在修改或绑定不存在的资源组时返回该错误。请参考[创建资源组](/tidb-resource-control-ru-groups.md#创建资源组)。
 
 * Error Number: 8250
 
@@ -428,11 +428,11 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样
 
 * Error Number: 8253
 
-    查询终止，因为满足 Runaway Queries 的条件。请参考 [Runaway Queries](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。
+    查询终止，因为满足 Runaway Queries 的条件。请参考 [Runaway Queries](/tidb-resource-control-runaway-queries.md)。
 
 * Error Number: 8254
 
-    查询终止，因为被 Runaway Queries 免疫命中。请参考 [Runaway Queries](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。
+    查询终止，因为被 Runaway Queries 免疫命中。请参考 [Runaway Queries](/tidb-resource-control-runaway-queries.md)。
 
 * Error Number: 8260
 
diff --git a/faq/sql-faq.md b/faq/sql-faq.md
index bc30e62cf995..9532903c68c6 100644
--- a/faq/sql-faq.md
+++ b/faq/sql-faq.md
@@ -33,7 +33,7 @@ TiDB 包含一个基于成本的优化器。在大多数情况下，优化器会
 
 ## 如何阻止特定的 SQL 语句执行（或者将某个 SQL 语句加入黑名单）？
 
-对于 v7.5.0 及以上版本，你可以使用 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md) 语句将特定的 SQL 查询加入黑名单。具体使用方法参见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control.md#query-watch-语句说明)。
+对于 v7.5.0 及以上版本，你可以使用 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md) 语句将特定的 SQL 查询加入黑名单。具体使用方法参见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control-runaway-queries.md#query-watch-语句说明)。
 
 对于 v7.5.0 之前版本，你可以使用 [`MAX_EXECUTION_TIME`](/optimizer-hints.md#max_execution_timen) Hint 来创建 [SQL 绑定](/sql-plan-management.md#执行计划绑定-sql-binding)，将特定语句的执行时间限制为一个较小的值（例如 1ms）。这样，语句就会在超过限制时自动终止。
 
@@ -209,7 +209,7 @@ TiDB 支持改变[全局](/system-variables.md#tidb_force_priority)或单个语
 
 > **注意：**
 >
-> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
+> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
 
 以上两种参数可以结合 TiDB 的 DML 语言进行使用，使用方法举例如下：
 
diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md
index 8ff820badc69..272381048208 100644
--- a/functions-and-operators/tidb-functions.md
+++ b/functions-and-operators/tidb-functions.md
@@ -9,7 +9,7 @@ summary: 学习使用 TiDB 特有的函数。
 
 | 函数名 | 函数说明 |
 | :-------------- | :------------------------------------- |
-| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 用于查询当前连接绑定的资源组名。参见[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)。 |
+| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 用于查询当前连接绑定的资源组名。参见[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)。 |
 | [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指示 TiDB 在指定时间范围内读取尽可能新的数据。参见[使用 `AS OF TIMESTAMP` 语法读取历史数据](/as-of-timestamp.md)。 |
 | [`TIDB_CURRENT_TSO()`](#tidb_current_tso) | 返回当前的 [TimeStamp Oracle (TSO)](/tso.md)。 |
 | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | 用于解码以二进制格式编码的执行计划。 |
@@ -27,7 +27,7 @@ summary: 学习使用 TiDB 特有的函数。
 
 ## CURRENT_RESOURCE_GROUP
 
-`CURRENT_RESOURCE_GROUP()` 函数用于查询当前连接绑定的资源组名称。当开启[资源管控 (Resource Control)](/tidb-resource-control.md) 功能时，执行 SQL 语句对资源的占用会受到所绑定的资源组资源配置的限制。
+`CURRENT_RESOURCE_GROUP()` 函数用于查询当前连接绑定的资源组名称。当开启[资源管控 (Resource Control)](/tidb-resource-control-ru-groups.md) 功能时，执行 SQL 语句对资源的占用会受到所绑定的资源组资源配置的限制。
 
 在会话建立时，TiDB 默认会将连接绑定至登录用户绑定的资源组，如果用户没有绑定任何资源组，则会将连接绑定至 `default` 资源组。在会话建立之后，绑定的资源组默认不会发生变化，即使执行了[修改用户绑定的资源组](/sql-statements/sql-statement-alter-user.md#修改用户绑定的资源组)。如需修改当前会话绑定的资源组，可以使用 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 语句。
 
diff --git a/glossary.md b/glossary.md
index a7cca1ab7e7e..6f6dd5d9aef6 100644
--- a/glossary.md
+++ b/glossary.md
@@ -252,7 +252,7 @@ RPC（远程过程调用）是软件组件之间的一种通信方式。在 TiDB
 
 ### Request Unit (RU)
 
-RU 是 TiDB 中资源使用的统一抽象单位，用于在[资源管控](/tidb-resource-control.md)功能中衡量资源的使用情况。
+RU 是 TiDB 中资源使用的统一抽象单位，用于在[资源管控](/tidb-resource-control-ru-groups.md)功能中衡量资源的使用情况。
 
 ### Restore
 
diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md
index 68a9a9744ca7..f4afc2cd5aa6 100644
--- a/grafana-resource-control-dashboard.md
+++ b/grafana-resource-control-dashboard.md
@@ -9,7 +9,7 @@ summary: 了解资源管控 (Resource Control) 的 Grafana Dashboard 中所展
 
 目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node_exporter、Overview、Performance_overview 等。
 
-如果你的集群配置了 [Resource Control](/tidb-resource-control.md) ，通过观察 Resource Control 面板上的 Metrics，你可以了解当前集群整体的资源消耗状态。
+如果你的集群配置了 [Resource Control](/tidb-resource-control-ru-groups.md) ，通过观察 Resource Control 面板上的 Metrics，你可以了解当前集群整体的资源消耗状态。
 
 TiDB 使用[令牌桶算法](https://en.wikipedia.org/wiki/Token_bucket) 做流控，正如资源管控实现机制 ([RFC: Global Resource Control in TiDB](https://github.com/pingcap/tidb/blob/master/docs/design/2022-11-25-global-resource-control.md#distributed-token-buckets)) 中所描述：一个 TiDB 节点可能存在多个 Resource Group（资源组），将在 PD 端的 GAC（Global Admission Control）进行流控。每个 TiDB 节点中的本地令牌桶（Local Token Buckets）将定期（默认 5 秒）与 PD 端的 GAC 进行通信，以重新配置本地令牌。其中的本地令牌桶（Local Token Buckets）具体实现为 Resource Controller Client。
 
@@ -17,7 +17,7 @@ TiDB 使用[令牌桶算法](https://en.wikipedia.org/wiki/Token_bucket) 做流
 
 ## Request Unit 相关指标
 
-- RU：以 Resource Group（资源组）为单位进行实时统计的 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 消耗信息。`total` 为当前所有 Resource Group 消耗的 Request Unit 之和。每个 Resource Group 的 Request Unit 消耗等于其读消耗 (Read Request Unit) 和写消耗 (Write Request Unit) 之和。
+- RU：以 Resource Group（资源组）为单位进行实时统计的 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 消耗信息。`total` 为当前所有 Resource Group 消耗的 Request Unit 之和。每个 Resource Group 的 Request Unit 消耗等于其读消耗 (Read Request Unit) 和写消耗 (Write Request Unit) 之和。
 - RU Per Query：平均每个 SQL 语句消耗的 Request Unit 数量。计算方法是将前述 Request Unit 监控指标除以当前每秒执行的 SQL 语句数量。
 - RRU：以 Resource Group 为单位进行实时统计的读请求 Read Request Unit 消耗信息。`total` 为当前所有 Resource Group 消耗的 Read Request Unit 之和。
 - RRU Per Query：平均每个 SQL 语句消耗的 Read Request Unit 数量。计算方法是将前述 Read Request Unit 监控指标除以当前每秒执行的 SQL 语句数量。
diff --git a/information-schema/information-schema-resource-groups.md b/information-schema/information-schema-resource-groups.md
index 8751a0de4337..65ac6eee14e6 100644
--- a/information-schema/information-schema-resource-groups.md
+++ b/information-schema/information-schema-resource-groups.md
@@ -5,7 +5,7 @@ summary: 了解 information_schema 表 `RESOURCE_GROUPS`。
 
 # RESOURCE_GROUPS
 
-`RESOURCE_GROUPS` 表展示所有资源组 (resource group) 的信息，见[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)。
+`RESOURCE_GROUPS` 表展示所有资源组 (resource group) 的信息，见[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)。
 
 ```sql
 USE information_schema;
@@ -75,7 +75,7 @@ SELECT * FROM information_schema.resource_groups WHERE NAME = 'rg1'; -- 查看
 `RESOURCE_GROUPS` 表中列的含义如下：
 
 * `NAME`：资源组名称。
-* `RU_PER_SEC`：资源组的回填速度，单位为每秒回填的 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 数量。
+* `RU_PER_SEC`：资源组的回填速度，单位为每秒回填的 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 数量。
 * `PRIORITY`：任务在 TiKV 上处理的绝对优先级。不同的资源按照 `PRIORITY` 的设置进行调度，`PRIORITY` 高的任务会被优先调度。如果资源组的 `PRIORITY` 相同，则会根据 `RU_PER_SEC` 的配置按比例调度。如果不指定 `PRIORITY`，资源组的默认优先级为 `MEDIUM`。
 * `BURSTABLE`：是否允许此资源组超额使用剩余的系统资源。
 
diff --git a/information-schema/information-schema-runaway-watches.md b/information-schema/information-schema-runaway-watches.md
index a203f4b62606..ab0e0913c9d5 100644
--- a/information-schema/information-schema-runaway-watches.md
+++ b/information-schema/information-schema-runaway-watches.md
@@ -5,7 +5,7 @@ summary: 了解 INFORMATION_SCHEMA 表 `RUNAWAY_WATCHES`。
 
 # RUNAWAY_WATCHES
 
-`RUNAWAY_WATCHES` 表展示资源消耗超出预期的查询 Runaway Queries 监控列表，见 [Runaway Queries](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。
+`RUNAWAY_WATCHES` 表展示资源消耗超出预期的查询 Runaway Queries 监控列表，见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control-runaway-queries.md)。
 
 ```sql
 USE INFORMATION_SCHEMA;
diff --git a/optimizer-hints.md b/optimizer-hints.md
index 0199f8137503..45865c95dd3d 100644
--- a/optimizer-hints.md
+++ b/optimizer-hints.md
@@ -860,7 +860,7 @@ SELECT /*+ NTH_PLAN(3) */ count(*) from t where a > 5;
 
 ### RESOURCE_GROUP(resource_group_name)
 
-`RESOURCE_GROUP(resource_group_name)` 用于[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)。此 Hint 将临时使用指定的资源组执行当前的语句。如果指定的资源组不存在，则该 Hint 将被忽略。
+`RESOURCE_GROUP(resource_group_name)` 用于[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)。此 Hint 将临时使用指定的资源组执行当前的语句。如果指定的资源组不存在，则该 Hint 将被忽略。
 
 示例：
 
diff --git a/pd-configuration-file.md b/pd-configuration-file.md
index 853b2c9e93f9..14b908eb0b5f 100644
--- a/pd-configuration-file.md
+++ b/pd-configuration-file.md
@@ -498,7 +498,7 @@ Region 同步模式相关的配置项。更多详情，请参阅[启用自适应
 
 ## controller
 
-PD 中内置的 [Resource Control](/tidb-resource-control.md) 相关的配置项。
+PD 中内置的 [Resource Control](/tidb-resource-control-ru-groups.md) 相关的配置项。
 
 ### `degraded-mode-wait-duration`
 
@@ -508,7 +508,7 @@ PD 中内置的 [Resource Control](/tidb-resource-control.md) 相关的配置项
 
 ### `request-unit`
 
-下面是 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 相关的配置项。
+下面是 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 相关的配置项。
 
 #### `read-base-cost`
 
diff --git a/pd-control.md b/pd-control.md
index f3d167ceb2fd..532a82ea80cf 100644
--- a/pd-control.md
+++ b/pd-control.md
@@ -1262,7 +1262,7 @@ resource-manager config controller show
 }
 ```
 
-- `ltb-max-wait-duration`：本地令牌桶 (Local Token Bucket, LTB) 的最大等待时间。默认值为 `30s`，取值范围为 `[0, 24h]`。如果 SQL 请求预估消耗的 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 超过了当前 LTB 积累的 RU，则需要等待一定时间。如果预估等待时间超过了此最大等待时间，则会提前向应用返回错误 [`ERROR 8252 (HY000) : Exceeded resource group quota limitation`](/error-codes.md)。增大该值可以减少某些突发并发增加、大事务和大查询的情况下容易报错 `ERROR 8252` 的问题。
+- `ltb-max-wait-duration`：本地令牌桶 (Local Token Bucket, LTB) 的最大等待时间。默认值为 `30s`，取值范围为 `[0, 24h]`。如果 SQL 请求预估消耗的 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 超过了当前 LTB 积累的 RU，则需要等待一定时间。如果预估等待时间超过了此最大等待时间，则会提前向应用返回错误 [`ERROR 8252 (HY000) : Exceeded resource group quota limitation`](/error-codes.md)。增大该值可以减少某些突发并发增加、大事务和大查询的情况下容易报错 `ERROR 8252` 的问题。
 - `enable-controller-trace-log`：controller 诊断日志开关。
 
 #### 修改 Resource Control 的 controller 配置
diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md
index 5987c0ccef19..46d0e1e875eb 100644
--- a/releases/release-6.6.0.md
+++ b/releases/release-6.6.0.md
@@ -130,9 +130,9 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本)
 
   此外，合理利用资源管控特性可以减少集群数量，降低运维难度及管理成本。
 
-  在 v6.6.0 中，启用资源管控特性需要同时打开 TiDB 的全局变量 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 及 TiKV 的配置项 [`resource-control.enabled`](/tikv-configuration-file.md#resource-control)。当前支持的限额方式基于“[用量](/tidb-resource-control.md#什么是-request-unit-ru)”（Request Unit，即 RU），RU 是 TiDB 对 CPU、I/O 等系统资源的统一抽象单位。
+  在 v6.6.0 中，启用资源管控特性需要同时打开 TiDB 的全局变量 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 及 TiKV 的配置项 [`resource-control.enabled`](/tikv-configuration-file.md#resource-control)。当前支持的限额方式基于“[用量](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru)”（Request Unit，即 RU），RU 是 TiDB 对 CPU、I/O 等系统资源的统一抽象单位。
 
-  更多信息，请参考[用户文档](/tidb-resource-control.md)。
+  更多信息，请参考[用户文档](/tidb-resource-control-ru-groups.md)。
 
 * 绑定历史执行计划 GA [#39199](https://github.com/pingcap/tidb/issues/39199) @[fzzf678](https://github.com/fzzf678)
 
@@ -361,7 +361,7 @@ TiDB 版本：6.6.0-[DMR](/releases/versioning.md#开发里程碑版本)
 | [`tidb_enable_historical_stats_for_capture`](/system-variables.md#tidb_enable_historical_stats_for_capture) | 新增 | 这个变量用来控制 `PLAN REPLAYER CAPTURE` 抓取的内容是否默认带历史统计信息。默认值为 `OFF`，表示默认不带历史统计信息。 |
 | [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-从-v660-版本开始引入) | 新增 | 这个变量用来控制 Prepared Plan Cache 是否缓存 `Limit` 后带有 `COUNT` 的执行计划。默认值为 `ON`，表示默认缓存这样的执行计划。目前不支持缓存 `Limit` 后面的 `COUNT` 具体参数值大于 10000 的执行计划。 |
 | [`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture) | 新增 | 这个变量用来控制是否开启 [`PLAN REPLAYER CAPTURE`](/sql-plan-replayer.md#使用-plan-replayer-capture-抓取目标计划)。默认值 `OFF`，代表默认关闭 `PLAN REPLAYER CAPTURE`。 |
-| [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) | 新增  | 该变量是[资源管控特性](/tidb-resource-control.md)的开关。默认值为 `OFF`。该变量设置为 `ON` 后，集群支持应用按照资源组做资源隔离。 |
+| [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) | 新增  | 该变量是[资源管控特性](/tidb-resource-control-ru-groups.md)的开关。默认值为 `OFF`。该变量设置为 `ON` 后，集群支持应用按照资源组做资源隔离。 |
 | [`tidb_historical_stats_duration`](/system-variables.md#tidb_historical_stats_duration-从-v660-版本开始引入) | 新增 | 这个变量用来控制历史统计信息在存储中的保留时间，默认值为 7 天。 |
 | [`tidb_index_join_double_read_penalty_cost_rate`](/system-variables.md#tidb_index_join_double_read_penalty_cost_rate-从-v660-版本开始引入) | 新增 | 用于控制是否给 index join 增加一些惩罚性代价。默认值为 `0`，即不开启该功能。 |
 | [`tidb_pessimistic_txn_aggressive_locking`](https://docs.pingcap.com/zh/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-%E4%BB%8E-v660-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5) | 新增 | 是否对悲观锁启用加强的悲观锁唤醒模型。默认值为 `OFF`，表示默认不对悲观锁启用加强的悲观锁唤醒模型。 |
diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md
index 2afe91f638a9..cb2abcd39d71 100644
--- a/releases/release-7.0.0.md
+++ b/releases/release-7.0.0.md
@@ -162,7 +162,7 @@ TiDB 版本：7.0.0
     - 会话级别。通过 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) 设置当前会话的资源组。
     - 语句级别。通过 [`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name) 设置当前语句的资源组。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md)。
+    更多信息，请参考[用户文档](/tidb-resource-control-ru-groups.md)。
 
 * 支持 Fast Online DDL 的检查点机制，提升容错性和自动恢复能力 [#42164](https://github.com/pingcap/tidb/issues/42164) @[tangenta](https://github.com/tangenta)
 
@@ -356,12 +356,12 @@ TiDB 版本：7.0.0
 | TiKV | [`resolved-ts.advance-ts-interval`](/tikv-configuration-file.md#advance-ts-interval) | 修改 | 默认值由 `"1s"` 变更为 `"20s"`。该修改可以延长定期推进 Resolved TS 的时间间隔，从而减少 TiKV 节点之间的流量消耗。 |
 | TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 修改 | 默认值由 `false` 变更为 `true`。 |
 | TiKV | [`raft-engine.prefill-for-recycle`](/tikv-configuration-file.md#prefill-for-recycle-从-v700-版本开始引入) | 新增 | 控制 Raft Engine 是否自动生成空的日志文件用于日志回收。默认值为 `false`。|
-| PD         | [`degraded-mode-wait-duration`](/pd-configuration-file.md#degraded-mode-wait-duration)         | 新增 | PD 中内置的 [Resource Control](/tidb-resource-control.md) 相关配置项。用于配置触发降级模式需要等待的时间。默认值为 `"0s"`。|
-| PD         |  [`read-base-cost`](/pd-configuration-file.md#read-base-cost)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control.md) 相关配置项。用于设置每次读请求转换成 RU 的基准系数。默认值为 `0.25`。 |
-| PD         |  [`read-cost-per-byte`](/pd-configuration-file.md#read-cost-per-byte)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control.md) 相关配置项。用于设置读流量转换成 RU 的基准系数。默认值为 `1/(64 * 1024)`。 |
-| PD         |  [`read-cpu-ms-cost`](/pd-configuration-file.md#read-cpu-ms-cost)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control.md) 相关配置项。用于设置 CPU 转换成 RU 的基准系数。默认值为 `1/3`。 |
-| PD         |  [`write-base-cost`](/pd-configuration-file.md#write-base-cost)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control.md) 相关配置项。用于设置每次写请求转换成 RU 的基准系数。默认值为 `1`。 |
-| PD         |  [`write-cost-per-byte`](/pd-configuration-file.md#write-cost-per-byte)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control.md) 相关配置项。用于设置写流量转换成 RU 的基准系数。默认值为 `1/1024`。 |
+| PD         | [`degraded-mode-wait-duration`](/pd-configuration-file.md#degraded-mode-wait-duration)         | 新增 | PD 中内置的 [Resource Control](/tidb-resource-control-ru-groups.md) 相关配置项。用于配置触发降级模式需要等待的时间。默认值为 `"0s"`。|
+| PD         |  [`read-base-cost`](/pd-configuration-file.md#read-base-cost)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control-ru-groups.md) 相关配置项。用于设置每次读请求转换成 RU 的基准系数。默认值为 `0.25`。 |
+| PD         |  [`read-cost-per-byte`](/pd-configuration-file.md#read-cost-per-byte)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control-ru-groups.md) 相关配置项。用于设置读流量转换成 RU 的基准系数。默认值为 `1/(64 * 1024)`。 |
+| PD         |  [`read-cpu-ms-cost`](/pd-configuration-file.md#read-cpu-ms-cost)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control-ru-groups.md) 相关配置项。用于设置 CPU 转换成 RU 的基准系数。默认值为 `1/3`。 |
+| PD         |  [`write-base-cost`](/pd-configuration-file.md#write-base-cost)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control-ru-groups.md) 相关配置项。用于设置每次写请求转换成 RU 的基准系数。默认值为 `1`。 |
+| PD         |  [`write-cost-per-byte`](/pd-configuration-file.md#write-cost-per-byte)      | 新增         |  PD 中内置的 [Resource Control](/tidb-resource-control-ru-groups.md) 相关配置项。用于设置写流量转换成 RU 的基准系数。默认值为 `1/1024`。 |
 | TiFlash | [`mark_cache_size`](/tiflash/tiflash-configuration.md) |  修改  | TiFlash 中数据块元信息的内存 cache 上限，默认值从 `5368709120` 修改为 `1073741824`，以减少不必要的内存占用 |
 | TiFlash | [`minmax_index_cache_size`](/tiflash/tiflash-configuration.md) |  修改  | TiFlash 中数据块 min-max 索引的内存 cache 上限，默认值从 `5368709120` 修改为 `1073741824`，以减少不必要的内存占用  |
 | TiFlash | [`flash.disaggregated_mode`](/tiflash/tiflash-disaggregated-and-s3.md) |  新增  | 在 TiFlash 的存算分离架构中，表示此 TiFlash 节点是 Write Node 还是 Compute Node。可选值为 `tiflash_write` 或者 `tiflash_compute`。 |
diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md
index c4de625ad097..e7cfc20dc7b3 100644
--- a/releases/release-7.1.0.md
+++ b/releases/release-7.1.0.md
@@ -152,7 +152,7 @@ TiDB 7.1.0 为长期支持版本 (Long-Term Support Release, LTS)。
 
     为了更好的用户体验，TiDB Dashboard 增加了[资源管控的管理页面](/dashboard/dashboard-resource-manager.md)。你可以在该页面查看资源组配置，并通过可视化的方式进行容量预估，便于合理配置资源。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md)。
+    更多信息，请参考[用户文档](/tidb-resource-control-ru-groups.md)。
 
 * 支持 Fast Online DDL 的检查点机制，提升容错性和自动恢复能力 [#42164](https://github.com/pingcap/tidb/issues/42164) @[tangenta](https://github.com/tangenta)
 
diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md
index 810fe698ed8a..abd2dc0200d8 100644
--- a/releases/release-7.2.0.md
+++ b/releases/release-7.2.0.md
@@ -92,7 +92,7 @@ TiDB 版本：7.2.0
 
     对资源超出预期查询的自动管理能力，为你提供了有效的手段，快速应对突发的查询性能问题，降低对数据库整体性能的影响，从而提升数据库的稳定性。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。
+    更多信息，请参考[用户文档](/tidb-resource-control-runaway-queries.md)。
 
 * 增强根据历史执行计划创建绑定的能力 [#39199](https://github.com/pingcap/tidb/issues/39199) @[qw4990](https://github.com/qw4990)
 
diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md
index f6278fb4c810..70d340142eb1 100644
--- a/releases/release-7.3.0.md
+++ b/releases/release-7.3.0.md
@@ -96,7 +96,7 @@ v7.3.0 引入了以下主要功能。[功能详情](#功能详情)中列出的
 
     手动标记 Runaway Query 的功能为数据库中突发的性能问题提供了有效的干预手段。针对由查询引发的性能问题，在定位根本原因之前，该功能可以快速缓解其对整体性能的影响，从而提升系统服务质量。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md#query-watch-语句说明)。
+    更多信息，请参考[用户文档](/tidb-resource-control-runaway-queries.md#query-watch-语句说明)。
 
 ### SQL 功能
 
diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md
index 9d6361749521..3c6d824d4e88 100644
--- a/releases/release-7.4.0.md
+++ b/releases/release-7.4.0.md
@@ -154,7 +154,7 @@ TiDB 版本：7.4.0
 
     通过配置 TiFlash 参数 `enable_resource_control`，你可以控制是否开启 TiFlash 资源管控特性。开启后，TiFlash 将根据 TiDB 的资源组配置进行资源调度管理，确保整体资源的合理分配和使用。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md)。
+    更多信息，请参考[用户文档](/tidb-resource-control-ru-groups.md)。
 
 * TiFlash 支持 Pipeline 执行模型 (GA) [#6518](https://github.com/pingcap/tiflash/issues/6518) @[SeaRise](https://github.com/SeaRise)
 
@@ -183,7 +183,7 @@ TiDB 版本：7.4.0
 
   默认情况下，被标记为后台任务的任务类型为空，此时后台任务的管理功能处于关闭状态，其行为与 TiDB v7.4.0 之前版本保持一致。你需要手动修改 `default` 资源组的后台任务类型以开启后台任务管理。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md#管理后台任务)。
+    更多信息，请参考[用户文档](/tidb-resource-control-background-tasks.md)。
 
 * 锁定统计信息成为正式功能 (GA) [#46351](https://github.com/pingcap/tidb/issues/46351) @[hi-rustin](https://github.com/Rustin170506)
 
@@ -305,7 +305,7 @@ TiDB 版本：7.4.0
 | [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-从-v740-版本开始引入) | 新增 | 该变量用于指定[全局排序](/tidb-global-sort.md)中使用的云存储的 URI。 |
 | [`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-从-v656v712-和-v740-版本开始引入) | 新增 | 控制优化器是否会选择表的哈希连接。默认打开 (`ON`)。设置为 `OFF` 时，除非没有计划可用，否则优化器会避免选择表的哈希连接。 |
 | [`tidb_opt_objective`](/system-variables.md#tidb_opt_objective-从-v740-版本开始引入) | 新增 | 该变量用于设置优化器优化目标。`moderate` 维持旧版本的默认行为，优化器会利用更多信息尝试生成更优的计划；`determinate` 则倾向于保守，保持执行计划稳定。 |
-| [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-从-v740-版本开始引入) | 新增 | 该变量用于显式指定当前会话的任务类型，用于[资源管控](/tidb-resource-control.md)识别并控制。如 `SET @@tidb_request_source_type = "background"`。 |
+| [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-从-v740-版本开始引入) | 新增 | 该变量用于显式指定当前会话的任务类型，用于[资源管控](/tidb-resource-control-ru-groups.md)识别并控制。如 `SET @@tidb_request_source_type = "background"`。 |
 | [`tidb_schema_version_cache_limit`](/system-variables.md#tidb_schema_version_cache_limit-从-v740-版本开始引入) | 新增 | 该变量用于限制 TiDB 实例可以缓存多少个历史版本的表结构信息。默认值为 `16`，即默认缓存 16 个历史版本的表结构信息。|
 | [`tidb_service_scope`](/system-variables.md#tidb_service_scope-从-v740-版本开始引入) | 新增 | 该变量是一个实例级别的变量，用于控制 [TiDB 分布式执行框架](/tidb-distributed-execution-framework.md)下各 TiDB 节点的服务范围。当设置 TiDB 节点的 `tidb_service_scope` 为 `background` 时，分布式执行框架将调度该节点执行任务（如 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) 和 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)）。 |
 | [`tidb_session_alias`](/system-variables.md#tidb_session_alias-从-v740-版本开始引入) | 新增 | 用来自定义当前会话相关日志中 `session_alias` 列的值。 |
diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md
index e268fc4be061..b6063e09f0cf 100644
--- a/releases/release-7.5.1.md
+++ b/releases/release-7.5.1.md
@@ -32,7 +32,7 @@ TiDB 版本：7.5.1
 
         - [慢查询日志](/identify-slow-queries.md)增加资源组名称、RU 消耗、以及等待资源耗时。
         - [Statement Summary Tables](/statement-summary-tables.md) 增加资源组名称、RU 消耗、以及等待资源耗时。
-        - 在变量 [`tidb_last_query_info`](/system-variables.md#tidb_last_query_info-从-v4014-版本开始引入) 中增加了 SQL 的 [RU](/tidb-resource-control.md#什么是-request-unit-ru) 消耗信息 `ru_consumption`，你可以利用此变量获取会话中上一条语句的资源消耗。
+        - 在变量 [`tidb_last_query_info`](/system-variables.md#tidb_last_query_info-从-v4014-版本开始引入) 中增加了 SQL 的 [RU](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 消耗信息 `ru_consumption`，你可以利用此变量获取会话中上一条语句的资源消耗。
         - 增加基于[资源组的数据库指标](/grafana-resource-control-dashboard.md)：QPS/TPS、执行时间 (P999/P99/P95)、失败次数、连接数。
 
     - 将 `CANCEL IMPORT JOB` 命令调整为同步命令 [#48736](https://github.com/pingcap/tidb/issues/48736) @[D3Hunter](https://github.com/D3Hunter)
@@ -49,7 +49,7 @@ TiDB 版本：7.5.1
 
 + TiFlash
 
-    - 改进 [RU (Request Unit)](/tidb-resource-control.md#什么是-request-unit-ru) 计算方法，以提高 RU 值的稳定性 [#8391](https://github.com/pingcap/tiflash/issues/8391) @[guo-shaoge](https://github.com/guo-shaoge)
+    - 改进 [RU (Request Unit)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 计算方法，以提高 RU 值的稳定性 [#8391](https://github.com/pingcap/tiflash/issues/8391) @[guo-shaoge](https://github.com/guo-shaoge)
     - 降低磁盘性能抖动对读取延迟的影响 [#8583](https://github.com/pingcap/tiflash/issues/8583) @[JaySon-Huang](https://github.com/JaySon-Huang)
     - 减少后台数据 GC 任务对读、写任务延迟的影响 [#8650](https://github.com/pingcap/tiflash/issues/8650) @[JaySon-Huang](https://github.com/JaySon-Huang)
 
diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md
index 2e91c9479ecf..fc4e6a6ab230 100644
--- a/releases/release-7.6.0.md
+++ b/releases/release-7.6.0.md
@@ -220,7 +220,7 @@ TiDB 版本：7.6.0
 
     * [慢查询日志](/identify-slow-queries.md)增加资源组名称、RU 消耗、以及等待资源耗时。
     * [Statement Summary Tables](/statement-summary-tables.md) 增加资源组名称、RU 消耗、以及等待资源耗时。
-    * 在变量 [`tidb_last_query_info`](/system-variables.md#tidb_last_query_info-从-v4014-版本开始引入) 中增加了 SQL 的 [RU](/tidb-resource-control.md#什么是-request-unit-ru) 消耗信息 `ru_consumption`，你可以利用此变量获取会话中上一条语句的资源消耗。
+    * 在变量 [`tidb_last_query_info`](/system-variables.md#tidb_last_query_info-从-v4014-版本开始引入) 中增加了 SQL 的 [RU](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 消耗信息 `ru_consumption`，你可以利用此变量获取会话中上一条语句的资源消耗。
     * 增加基于[资源组的数据库指标](/grafana-resource-control-dashboard.md)：QPS/TPS、执行时间 (P999/P99/P95)、失败次数、连接数。
     * 增加系统表 [`request_unit_by_group`](/mysql-schema/mysql-schema.md#资源管控相关系统表) 记录资源组每天的历史资源消耗。
 
diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md
index 683bce3312e4..a247b6b5f252 100644
--- a/releases/release-8.1.0.md
+++ b/releases/release-8.1.0.md
@@ -103,7 +103,7 @@ TiDB 8.1.0 为长期支持版本 (Long-Term Support Release, LTS)。
 
     对资源消耗超出预期的查询的自动管理能力为用户提供了有效的手段，在根本原因被定位之前，该功能可以快速缓解查询问题对整体性能的影响，从而提升数据库的稳定性。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。
+    更多信息，请参考[用户文档](/tidb-resource-control-runaway-queries.md#管理资源消耗超出预期的查询-runaway-queries)。
 
 ### SQL 功能
 
diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md
index 73a3b2628978..9327aae13842 100644
--- a/releases/release-8.2.0.md
+++ b/releases/release-8.2.0.md
@@ -119,7 +119,7 @@ TiDB 版本：8.2.0
 
     为了维持兼容性，从旧版本升级到 v8.2.0 及之后版本的集群维持原行为不变。通过设置新增变量 [`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-从-v820-版本开始引入) 为 `ON`，来开启上述的增强权限控制。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md#绑定资源组)。
+    更多信息，请参考[用户文档](/tidb-resource-control-ru-groups.md#绑定资源组)。
 
 ### 可观测性
 
diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md
index 349e47f93a72..718a7e6f99a4 100644
--- a/releases/release-8.4.0.md
+++ b/releases/release-8.4.0.md
@@ -150,13 +150,13 @@ TiDB 版本：8.4.0
 
     可以观测 [Statement Summary Tables](/statement-summary-tables.md) 中的几个对应字段 (`RESOURCE_GROUP`、`MAX_REQUEST_UNIT_WRITE`、`MAX_REQUEST_UNIT_READ`、`MAX_PROCESSED_KEYS`)，根据历史执行情况决定条件值的大小。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。
+    更多信息，请参考[用户文档](/tidb-resource-control-runaway-queries.md#管理资源消耗超出预期的查询-runaway-queries)。
 
 * 超出预期的查询 (Runaway Queries) 支持切换资源组 [#54434](https://github.com/pingcap/tidb/issues/54434) @[JmPotato](https://github.com/JmPotato)
 
-    v8.4.0 新增支持将 Runaway Queries 切换到指定资源组。在降低优先级 (COOLDOWN) 仍旧无法有效降低资源消耗的情况下，你可以创建一个[资源组 (Resource Group)](/tidb-resource-control.md#创建资源组)并限制其资源上限，通过配置参数 `SWITCH_GROUP` 指定将识别到的查询切换到该资源组中，会话的后续查询仍在原资源组中执行。切换资源组的行为能够更精确地限制资源使用，对 Runaway Queries 的资源消耗做更加严格的控制。
+    v8.4.0 新增支持将 Runaway Queries 切换到指定资源组。在降低优先级 (COOLDOWN) 仍旧无法有效降低资源消耗的情况下，你可以创建一个[资源组 (Resource Group)](/tidb-resource-control-ru-groups.md#创建资源组)并限制其资源上限，通过配置参数 `SWITCH_GROUP` 指定将识别到的查询切换到该资源组中，会话的后续查询仍在原资源组中执行。切换资源组的行为能够更精确地限制资源使用，对 Runaway Queries 的资源消耗做更加严格的控制。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md#query_limit-参数说明)。
+    更多信息，请参考[用户文档](/tidb-resource-control-runaway-queries.md#query_limit-参数说明)。
 
 * 支持使用系统变量 `tidb_scatter_region` 设置集群级别的 Region 打散策略 [#55184](https://github.com/pingcap/tidb/issues/55184) @[D3Hunter](https://github.com/D3Hunter)
 
@@ -170,7 +170,7 @@ TiDB 版本：8.4.0
 
     TiDB 资源管控能够识别并降低后台任务的运行优先级。在部分场景下，即使有空闲资源，用户也希望后台任务消耗能够控制在很低的水平。从 v8.4.0 开始，你可以使用参数 `UTILIZATION_LIMIT` 为资源管控的后台任务设置最大可以使用的资源百分比，每个节点把所有后台任务的使用量控制在这个百分比以下。该功能可以让你精细控制后台任务的资源占用，进一步提升集群稳定性。
 
-    更多信息，请参考[用户文档](/tidb-resource-control.md#管理后台任务)。
+    更多信息，请参考[用户文档](/tidb-resource-control-background-tasks.md)。
 
 * 优化资源组资源分配策略 [#50831](https://github.com/pingcap/tidb/issues/50831) @[nolouch](https://github.com/nolouch)
 
diff --git a/sql-statements/sql-statement-alter-resource-group.md b/sql-statements/sql-statement-alter-resource-group.md
index 93e71f06d7fc..4cddfa61605e 100644
--- a/sql-statements/sql-statement-alter-resource-group.md
+++ b/sql-statements/sql-statement-alter-resource-group.md
@@ -74,15 +74,15 @@ DirectBackgroundOption ::=
 |   "UTILIZATION_LIMIT" EqOpt LengthNum
 ```
 
-TiDB 支持以下 `DirectResourceGroupOption`, 其中 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 是 TiDB 对 CPU、IO 等系统资源统一抽象的单位。
+TiDB 支持以下 `DirectResourceGroupOption`, 其中 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 是 TiDB 对 CPU、IO 等系统资源统一抽象的单位。
 
 | 参数            | 含义           | 举例                                   |
 |---------------|--------------|--------------------------------------|
 | `RU_PER_SEC`  | 每秒 RU 填充的速度 | `RU_PER_SEC = 500` 表示此资源组每秒回填 500 个 RU。 |
 | `PRIORITY`    | 任务在 TiKV 上处理的绝对优先级  | `PRIORITY = HIGH` 表示优先级高。若未指定则默认为 `MEDIUM`。 |
 | `BURSTABLE`   | 允许对应的资源组超出配额后使用空余的系统资源。 |
-| `QUERY_LIMIT` | 当查询执行满足该条件时，识别该查询为 Runaway Query 并执行相应的操作 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当执行时间超过 60 秒后识别为 Runaway Query，对该查询执行终止操作，并在 10 分钟内对同样的 SQL 直接执行终止操作。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 则表示不进行 Runaway 控制。具体参数介绍参见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。 ｜
-| `BACKGROUND`  | 后台任务相关的设置。具体参数介绍参见[管理后台任务](/tidb-resource-control.md#管理后台任务) | `BACKGROUND=(TASK_TYPES="br,stats", UTILIZATION_LIMIT=30)` 表示将备份恢复和收集统计信息相关的任务作为后台任务调度，并且后台任务最多可以使用 TiKV 30% 的资源。 |
+| `QUERY_LIMIT` | 当查询执行满足该条件时，识别该查询为 Runaway Query 并执行相应的操作 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当执行时间超过 60 秒后识别为 Runaway Query，对该查询执行终止操作，并在 10 分钟内对同样的 SQL 直接执行终止操作。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 则表示不进行 Runaway 控制。具体参数介绍参见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control-runaway-queries.md)。 ｜
+| `BACKGROUND`  | 后台任务相关的设置。具体参数介绍参见[管理后台任务](/tidb-resource-control-background-tasks.md) | `BACKGROUND=(TASK_TYPES="br,stats", UTILIZATION_LIMIT=30)` 表示将备份恢复和收集统计信息相关的任务作为后台任务调度，并且后台任务最多可以使用 TiKV 30% 的资源。 |
 
 > **注意：**
 >
@@ -180,4 +180,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.md#什么是-request-unit-ru)
+* [RU](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru)
diff --git a/sql-statements/sql-statement-calibrate-resource.md b/sql-statements/sql-statement-calibrate-resource.md
index 48fffda77207..573007ba1d43 100644
--- a/sql-statements/sql-statement-calibrate-resource.md
+++ b/sql-statements/sql-statement-calibrate-resource.md
@@ -5,7 +5,7 @@ summary: TiDB 数据库中 CALIBRATE RESOURCE 的使用概况。
 
 # `CALIBRATE RESOURCE`
 
-`CALIBRATE RESOURCE` 语句用于预估并输出当前集群的 [`Request Unit (RU)`](/tidb-resource-control.md#什么是-request-unit-ru) 的容量。
+`CALIBRATE RESOURCE` 语句用于预估并输出当前集群的 [`Request Unit (RU)`](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 的容量。
 
 ## 语法图
 
diff --git a/sql-statements/sql-statement-create-resource-group.md b/sql-statements/sql-statement-create-resource-group.md
index ba4d5662113d..dfd06d4343f2 100644
--- a/sql-statements/sql-statement-create-resource-group.md
+++ b/sql-statements/sql-statement-create-resource-group.md
@@ -71,14 +71,14 @@ ResourceGroupRunawayActionOption ::=
 
 资源组的 `ResourceGroupName` 是全局唯一的，不允许重复。
 
-TiDB 支持以下 `DirectResourceGroupOption`, 其中 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 是 TiDB 对 CPU、IO 等系统资源统一抽象的单位。
+TiDB 支持以下 `DirectResourceGroupOption`, 其中 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 是 TiDB 对 CPU、IO 等系统资源统一抽象的单位。
 
 | 参数            | 含义           | 举例                                   |
 |---------------|--------------|--------------------------------------|
 | `RU_PER_SEC`  | 每秒 RU 填充的速度 | `RU_PER_SEC = 500` 表示此资源组每秒回填 500 个 RU。 |
 | `PRIORITY`    | 任务在 TiKV 上处理的绝对优先级  | `PRIORITY = HIGH` 表示优先级高。若未指定，则默认为 `MEDIUM`。 |
 | `BURSTABLE`   | 允许对应的资源组超出配额后使用空余的系统资源。 | 
-| `QUERY_LIMIT` | 当查询执行满足该条件时，识别该查询为 Runaway Query 并进行相应的控制 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当执行时间超过 60 秒后识别为 Runaway Query，对该查询执行终止操作，并在 10 分钟内对同样的 SQL 直接执行终止操作。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 则表示不进行 Runaway 控制。具体参数介绍详见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)。 ｜
+| `QUERY_LIMIT` | 当查询执行满足该条件时，识别该查询为 Runaway Query 并进行相应的控制 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')` 表示当执行时间超过 60 秒后识别为 Runaway Query，对该查询执行终止操作，并在 10 分钟内对同样的 SQL 直接执行终止操作。`QUERY_LIMIT=()` 或 `QUERY_LIMIT=NULL` 则表示不进行 Runaway 控制。具体参数介绍详见[管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control-runaway-queries.md)。 ｜
 
 > **注意：**
 >
@@ -141,4 +141,4 @@ MySQL 也支持 [CREATE RESOURCE GROUP](https://dev.mysql.com/doc/refman/8.0/en/
 * [DROP RESOURCE GROUP](/sql-statements/sql-statement-drop-resource-group.md)
 * [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md)
 * [ALTER USER RESOURCE GROUP](/sql-statements/sql-statement-alter-user.md#修改用户绑定的资源组)
-* [RU](/tidb-resource-control.md#什么是-request-unit-ru)
+* [RU](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru)
diff --git a/sql-statements/sql-statement-drop-resource-group.md b/sql-statements/sql-statement-drop-resource-group.md
index 96f4cbb4c5e3..df0ca1459b21 100644
--- a/sql-statements/sql-statement-drop-resource-group.md
+++ b/sql-statements/sql-statement-drop-resource-group.md
@@ -83,4 +83,4 @@ MySQL 也支持 [DROP RESOURCE GROUP](https://dev.mysql.com/doc/refman/8.0/en/dr
 
 * [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md)
 * [CREATE RESOURCE GROUP](/sql-statements/sql-statement-create-resource-group.md)
-* [RU](/tidb-resource-control.md#什么是-request-unit-ru)
+* [RU](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru)
diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md
index f18b287f7377..e9be74efc9a3 100644
--- a/sql-statements/sql-statement-explain-analyze.md
+++ b/sql-statements/sql-statement-explain-analyze.md
@@ -284,7 +284,7 @@ commit_txn: {prewrite:48.564544ms, wait_prewrite_binlog:47.821579, get_commit_ts
 
 ### RU (Request Unit) 消耗
 
-[Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 是资源管控对系统资源统一抽象的计量单位。执行计划顶层算子的 `execution info` 会显示 SQL 整体的 RU 消耗。
+[Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 是资源管控对系统资源统一抽象的计量单位。执行计划顶层算子的 `execution info` 会显示 SQL 整体的 RU 消耗。
 
 ```
 RU:273.842670
diff --git a/sql-statements/sql-statement-insert.md b/sql-statements/sql-statement-insert.md
index 3be81155cb9f..6a4b28db28fb 100644
--- a/sql-statements/sql-statement-insert.md
+++ b/sql-statements/sql-statement-insert.md
@@ -44,7 +44,7 @@ OnDuplicateKeyUpdate ::=
 
 > **注意：**
 >
-> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PriorityOpt` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
+> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PriorityOpt` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
 
 ## 示例
 
diff --git a/sql-statements/sql-statement-overview.md b/sql-statements/sql-statement-overview.md
index aa1955e2992a..f41ec9bb6f56 100644
--- a/sql-statements/sql-statement-overview.md
+++ b/sql-statements/sql-statement-overview.md
@@ -137,7 +137,7 @@ TiDB 使用的 SQL 语句旨在遵循 ISO/IEC SQL 标准，并在必要时对 My
 | SQL 语句 | 描述 |
 |----------|------|
 | [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) | 修改资源组。 |
-| [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md) | 估算并输出当前集群的 [Request Unit (RU)](/tidb-resource-control.md#什么是-request-unit-ru) 容量。 |
+| [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md) | 估算并输出当前集群的 [Request Unit (RU)](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 容量。 |
 | [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) | 创建新的资源组。 |
 | [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md) | 删除资源组。 |
 | [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md) | 管理 Runaway Queries 监控列表。 |
diff --git a/sql-statements/sql-statement-query-watch.md b/sql-statements/sql-statement-query-watch.md
index 7486ff4004ea..66c1b3d99ca1 100644
--- a/sql-statements/sql-statement-query-watch.md
+++ b/sql-statements/sql-statement-query-watch.md
@@ -50,7 +50,7 @@ DropQueryWatchStmt ::=
 
 ## 参数说明
 
-详见 [`QUERY WATCH` 语句说明](/tidb-resource-control.md#query-watch-语句说明)。
+详见 [`QUERY WATCH` 语句说明](/tidb-resource-control-runaway-queries.md#query-watch-语句说明)。
 
 ## MySQL 兼容性
 
@@ -58,4 +58,4 @@ DropQueryWatchStmt ::=
 
 ## 另请参阅
 
-* [Runaway Queries](/tidb-resource-control.md#管理资源消耗超出预期的查询-runaway-queries)
+* [Runaway Queries](/tidb-resource-control-runaway-queries.md#管理资源消耗超出预期的查询-runaway-queries)
diff --git a/sql-statements/sql-statement-replace.md b/sql-statements/sql-statement-replace.md
index 0de3bdaeeb0d..e25e0b197228 100644
--- a/sql-statements/sql-statement-replace.md
+++ b/sql-statements/sql-statement-replace.md
@@ -37,7 +37,7 @@ InsertValues ::=
 
 > **注意：**
 >
-> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PriorityOpt` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
+> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PriorityOpt` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
 
 ## 示例
 
diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md
index 747e7b638623..b3acc6037dd5 100644
--- a/sql-statements/sql-statement-select.md
+++ b/sql-statements/sql-statement-select.md
@@ -107,7 +107,7 @@ TableSample ::=
 
 > **注意：**
 >
-> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`HIGH_PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
+> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`HIGH_PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
 
 ## 示例
 
diff --git a/sql-statements/sql-statement-set-resource-group.md b/sql-statements/sql-statement-set-resource-group.md
index d5236f7e0f38..be9a9dd188d4 100644
--- a/sql-statements/sql-statement-set-resource-group.md
+++ b/sql-statements/sql-statement-set-resource-group.md
@@ -93,4 +93,4 @@ MySQL 也支持 [SET RESOURCE GROUP](https://dev.mysql.com/doc/refman/8.0/en/set
 * [CREATE RESOURCE GROUP](/sql-statements/sql-statement-create-resource-group.md)
 * [DROP RESOURCE GROUP](/sql-statements/sql-statement-drop-resource-group.md)
 * [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md)
-* [使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)
+* [使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)
diff --git a/sql-statements/sql-statement-show-create-resource-group.md b/sql-statements/sql-statement-show-create-resource-group.md
index 805de071a147..de1aae904adb 100644
--- a/sql-statements/sql-statement-show-create-resource-group.md
+++ b/sql-statements/sql-statement-show-create-resource-group.md
@@ -44,7 +44,7 @@ SHOW CREATE RESOURCE GROUP rg1;
 
 ## 另请参阅
 
-* [TiDB RESOURCE CONTROL](/tidb-resource-control.md)
+* [TiDB RESOURCE CONTROL](/tidb-resource-control-ru-groups.md)
 * [CREATE RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md)
 * [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md)
 * [DROP RESOURCE GROUP](/sql-statements/sql-statement-drop-resource-group.md)
diff --git a/sql-statements/sql-statement-update.md b/sql-statements/sql-statement-update.md
index 79801ee53291..f033f5a58e83 100644
--- a/sql-statements/sql-statement-update.md
+++ b/sql-statements/sql-statement-update.md
@@ -29,7 +29,7 @@ TableRefs ::=
 
 > **注意：**
 >
-> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`LOW_PRIORITY` 或 `HIGH_PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
+> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`LOW_PRIORITY` 或 `HIGH_PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
 
 ## 示例
 
diff --git a/statement-summary-tables.md b/statement-summary-tables.md
index 73e66137ffcf..d86da48e97ba 100644
--- a/statement-summary-tables.md
+++ b/statement-summary-tables.md
@@ -80,7 +80,7 @@ select * from employee where id in (...) and salary between ? and ?;
 > **注意：**
 >
 > - 在 TiDB 中，statement summary tables 中字段的时间单位是纳秒 (ns)，而 MySQL 中的时间单位是皮秒 (ps)。
-> - 从 v7.5.1 和 v7.6.0 版本开始，对于开启[资源管控](/tidb-resource-control.md)的集群，`statements_summary` 会分资源组进行聚合，即在不同资源组执行的相同语句会被收集为不同的记录。
+> - 从 v7.5.1 和 v7.6.0 版本开始，对于开启[资源管控](/tidb-resource-control-ru-groups.md)的集群，`statements_summary` 会分资源组进行聚合，即在不同资源组执行的相同语句会被收集为不同的记录。
 
 ## `statements_summary_history`
 
diff --git a/system-variables.md b/system-variables.md
index 5eb7b555c69e..ecceb4537b4f 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -2327,7 +2327,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1;
 - 是否受 Hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value) 控制：否
 - 默认值：`ON`
 - 类型：布尔型
-- 该变量是[资源管控特性](/tidb-resource-control.md)的开关。该变量设置为 `ON` 时，集群支持应用按照资源组做资源隔离。
+- 该变量是[资源管控特性](/tidb-resource-control-ru-groups.md)的开关。该变量设置为 `ON` 时，集群支持应用按照资源组做资源隔离。
 
 ### `tidb_enable_reuse_chunk` <span class="version-mark">从 v6.4.0 版本开始引入</span>
 
@@ -2633,7 +2633,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告）
 
 > **注意：**
 >
-> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
+> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
 
 ### `tidb_gc_concurrency` <span class="version-mark">从 v5.0 版本开始引入</span>
 
@@ -3056,7 +3056,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告）
     - `start_ts`：事务开始的时间戳。
     - `for_update_ts`：先前执行的 DML 语句的 `for_update_ts` 信息。这是 TiDB 用于测试的内部术语。通常，你可以忽略此信息。
     - `error`：错误消息（如果有）。
-    - `ru_consumption`：执行语句的 [RU](/tidb-resource-control.md#什么是-request-unit-ru) 消耗。
+    - `ru_consumption`：执行语句的 [RU](/tidb-resource-control-ru-groups.md#什么是-request-unit-ru) 消耗。
 
 ### `tidb_last_txn_info` <span class="version-mark">从 v4.0.9 版本开始引入</span>
 
@@ -4524,7 +4524,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
 - 类型：字符串
 - 默认值：`""`
 - 可选值：`"ddl"`、`"stats"`、`"br"`、`"lightning"`、`"background"`
-- 显式指定当前会话的任务类型，用于[资源管控](/tidb-resource-control.md)识别并控制。如 `SET @@tidb_request_source_type = "background"`。
+- 显式指定当前会话的任务类型，用于[资源管控](/tidb-resource-control-ru-groups.md)识别并控制。如 `SET @@tidb_request_source_type = "background"`。
 
 ### `tidb_resource_control_strict_mode` <span class="version-mark">从 v8.2.0 版本开始引入</span>
 
diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md
index 74784ed7d113..e60f41e9537b 100644
--- a/tidb-configuration-file.md
+++ b/tidb-configuration-file.md
@@ -576,7 +576,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/
 
 > **注意：**
 >
-> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
+> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
 
 ### `distinct-agg-push-down`
 
@@ -933,7 +933,7 @@ TiDB 服务状态相关配置。
 
 > **注意：**
 >
-> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
+> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。
 
 ### `max_connections`
 
diff --git a/tidb-resource-control-background-tasks.md b/tidb-resource-control-background-tasks.md
new file mode 100644
index 000000000000..13de02a407f3
--- /dev/null
+++ b/tidb-resource-control-background-tasks.md
@@ -0,0 +1,79 @@
+---
+title: 使用资源管控 (Resource Control) 管理后台任务
+summary: 介绍如何通过资源管控 (Resource Control) 控制后台任务。
+---
+# 使用资源管控 (Resource Control) 管理后台任务
+
+> **警告：**
+>
+> - 该功能目前为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请[提交 issue](/support.md) 反馈。
+> - 资源管控的后台任务管理是基于 TiKV 的 CPU/IO 的资源利用率动态调整资源配额的，因此它依赖各个实例可用资源上限 (Quota)。如果在单个服务器混合部署多个组件或实例，需要通过 `cgroup` 为各个实例设置合适的资源上限 (Quota)。TiUP Playground 等共享资源的配置很难表现出预期效果。
+
+后台任务是指那些优先级不高但是需要消耗大量资源的任务，如数据备份和自动统计信息收集等。这些任务通常定期或不定期触发，在执行的时候会消耗大量资源，从而影响在线的高优先级任务的性能。
+
+自 v7.4.0 开始，[TiDB 资源管控](/tidb-resource-control-ru-groups.md)引入了对后台任务的管理。当一种任务被标记为后台任务时，TiKV 会动态地限制该任务的资源使用，以尽量避免此类任务在执行时对其他前台任务的性能产生影响。TiKV 通过实时地监测所有前台任务所消耗的 CPU 和 IO 等资源，并根据实例总的资源上限计算出后台任务可使用的资源阈值，所有后台任务在执行时会受此阈值的限制。
+
+## `BACKGROUND` 参数说明
+
+- `TASK_TYPES`：设置需要作为后台任务管理的任务类型，多个任务类型以 `,` 分隔。
+- `UTILIZATION_LIMIT`：限制每个 TiKV 节点上后台任务最大可以使用的资源百分比 (0-100)。默认情况下，TiKV 会根据节点的总资源以及当前前台任务所占用的资源，来计算后台任务的可用资源。如果设置此限制，则实际分配给后台任务的资源不会超过此限制的比例。
+
+目前 TiDB 支持如下几种后台任务的类型：
+
+- `lightning`：使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 执行导入任务。同时支持 TiDB Lightning 的物理和逻辑导入模式。
+- `br`：使用 [BR](/br/backup-and-restore-overview.md) 执行数据备份和恢复。目前不支持 PITR。
+- `ddl`：对于 Reorg DDL，控制批量数据回写阶段的资源使用。
+- `stats`：对应手动执行或系统自动触发的[收集统计信息](/statistics.md#收集统计信息)任务。
+- `background`：预留的任务类型，可使用 [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-从-v740-版本开始引入) 系统变量指定当前会话的任务类型为 `background`。
+
+默认情况下，被标记为后台任务的任务类型为 `""`，此时后台任务的管理功能处于关闭状态。如需开启后台任务管理功能，你需要手动修改 `default` 资源组的后台任务类型以开启后台任务管理。后台任务类型被识别匹配后，资源管控会自动进行，即当系统资源紧张时，后台任务会自动降为最低优先级，保证前台任务的执行。
+
+> **注意：**
+>
+> 目前，所有资源组的后台任务默认都会绑定到默认资源组 `default` 下进行管控，你可以通过 `default` 全局管控后台任务类型。暂不支持将后台任务绑定到其他资源组。
+
+## 示例
+
+1. 修改 `default` 资源组，将 `br` 和 `ddl` 标记为后台任务，并配置后台任务最多可使用 TiKV 节点总资源的 30%。
+
+    ```sql
+    ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='br,ddl', UTILIZATION_LIMIT=30);
+    ```
+
+2. 修改 `default` 资源组，将后台任务的类型还原为默认值。
+
+    ```sql
+    ALTER RESOURCE GROUP `default` BACKGROUND=NULL;
+    ```
+
+3. 修改 `default` 资源组，将后台任务的类型设置为空，此时此资源组的所有任务类型都不会作为后台任务处理。
+
+    ```sql
+    ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES="");
+    ```
+
+4. 查看 `default` 资源组的后台任务类型。
+
+    ```sql
+    SELECT * FROM information_schema.resource_groups WHERE NAME="default";
+    ```
+
+    输出结果如下：
+
+    ```
+    +---------+------------+----------+-----------+-------------+-------------------------------------------+
+    | NAME    | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND                                |
+    +---------+------------+----------+-----------+-------------+-------------------------------------------+
+    | default | UNLIMITED  | MEDIUM   | YES       | NULL        | TASK_TYPES='br,ddl', UTILIZATION_LIMIT=30 |
+    +---------+------------+----------+-----------+-------------+-------------------------------------------+
+    ```
+
+5. 如果希望将当前会话里的任务显式标记为后台类型，你可以使用 `tidb_request_source_type` 显式指定任务类型，如：
+
+    ``` sql
+    SET @@tidb_request_source_type="background";
+    /* 添加 background 任务类型 */
+    ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES="background");
+    /* 在当前会话中执行 LOAD DATA */
+    LOAD DATA INFILE "s3://resource-control/Lightning/test.customer.aaaa.csv"
+    ```
\ No newline at end of file
diff --git a/tidb-resource-control.md b/tidb-resource-control-ru-groups.md
similarity index 57%
rename from tidb-resource-control.md
rename to tidb-resource-control-ru-groups.md
index 541f80f2caba..9cceb5d8c578 100644
--- a/tidb-resource-control.md
+++ b/tidb-resource-control-ru-groups.md
@@ -1,9 +1,9 @@
 ---
-title: 使用资源管控 (Resource Control) 实现资源隔离
+title: 使用资源管控 (Resource Control) 实现资源组限制和流控
 summary: 介绍如何通过资源管控能力来实现对应用资源消耗的控制和有效调度。
 ---
 
-# 使用资源管控 (Resource Control) 实现资源隔离
+# 使用资源管控 (Resource Control) 实现资源组限制和流控
 
 使用资源管控特性，集群管理员可以定义资源组 (Resource Group)，通过资源组限定配额。
 
@@ -17,6 +17,11 @@ TiDB 资源管控特性提供了两层资源管理能力，包括在 TiDB 层的
 - TiFlash 流控：借助 [TiFlash Pipeline Model 执行模型](/tiflash/tiflash-pipeline-model.md)，可以更精确地获取不同查询的 CPU 消耗情况，并转换为 [Request Unit (RU)](#什么是-request-unit-ru) 进行扣除。流量控制通过令牌桶算法实现。
 - TiFlash 调度：当系统资源不足时，会根据优先级对多个资源组之间的 pipeline task 进行调度。具体逻辑是：首先判断资源组的优先级 `PRIORITY`，然后根据 CPU 使用情况，再结合 `RU_PER_SEC` 进行判断。最终效果是，如果 rg1 和 rg2 的 `PRIORITY` 一样，但是 rg2 的 `RU_PER_SEC` 是 rg1 的两倍，那么 rg2 可使用的 CPU 时间是 rg1 的两倍。
 
+关于如何管控后台任务和管理资源消耗超出预期的查询 (Runaway Queries) 的内容，请参考以下文档：
+
+- [使用资源管控 (Resource Control) 管理后台任务](/tidb-resource-control-background-tasks.md)
+- [管理资源消耗超出预期的查询 (Runaway Queries)](/tidb-resource-control-runaway-queries.md)
+
 ## 使用场景
 
 资源管控特性的引入对 TiDB 具有里程碑的意义。它能够将一个分布式数据库集群划分成多个逻辑单元，即使个别单元对资源过度使用，也不会挤占其他单元所需的资源。利用该特性：
@@ -208,242 +213,6 @@ SET RESOURCE GROUP rg1;
 SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10;
 ```
 
-### 管理资源消耗超出预期的查询 (Runaway Queries)
-
-Runaway Query 是指执行时间或消耗资源超出预期的查询（仅指 `SELECT` 语句）。下面使用 **Runaway Queries** 表示管理 Runaway Query 这一功能。
-
-- 自 v7.2.0 起，TiDB 资源管控引入了对 Runaway Queries 的管理。你可以针对某个资源组设置条件来识别 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 起，TiDB 资源管控引入了手动管理 Runaway Queries 监控列表的功能，将给定的 SQL 或者 Digest 添加到隔离监控列表，从而实现快速隔离 Runaway Queries。你可以执行语句 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)，手动管理资源组中的 Runaway Queries 监控列表。
-
-#### `QUERY_LIMIT` 参数说明
-
-如果查询超过以下任一限制，就会被识别为 Runaway Query：
-
-- `EXEC_ELAPSED`：检测查询执行的时间是否超限
-- `PROCESSED_KEYS`：检测 Coprocessor 处理的 key 的数量是否超限
-- `RU`：检测执行语句消耗的总读写 RU 是否超限
-
-支持的应对操作 (`ACTION`)：
-
-- `DRYRUN`：对执行 Query 不做任何操作，仅记录识别的 Runaway Query。主要用于观测设置条件是否合理。
-- `COOLDOWN`：将查询的执行优先级降到最低，查询仍旧会以低优先级继续执行，不占用其他操作的资源。
-- `KILL`：识别到的查询将被自动终止，报错 `Query execution was interrupted, identified as runaway query`。
-- `SWITCH_GROUP`：从 v8.4.0 开始引入，将识别到的查询切换到指定的资源组继续执行。该查询执行结束后，后续 SQL 仍保持在原资源组中执行。如果指定的资源组不存在，则不做任何动作。
-
-为了避免并发的 Runaway Query 过多导致系统资源耗尽，资源管控引入了 Runaway Query 监控机制，能够快速识别并隔离 Runaway Query。该功能通过 `WATCH` 子句实现，当某一个查询被识别为 Runaway Query 之后，会提取这个查询的匹配特征（由 `WATCH` 后的匹配方式参数决定），在接下来的一段时间里（由 `DURATION` 定义），这个 Runaway Query 的匹配特征会被加入到监控列表，TiDB 实例会将查询和监控列表进行匹配，匹配到的查询直接标记为 Runaway Query，而不再等待其被条件识别，并按照当前应对操作进行隔离。其中 `KILL` 会终止该查询，并报错 `Quarantined and interrupted because of being in runaway watch list`。
-
-`WATCH` 有三种匹配方式：
-
-- `EXACT` 表示完全相同的 SQL 才会被快速识别
-- `SIMILAR` 表示会忽略字面值 (Literal)，通过 SQL Digest 匹配所有模式 (Pattern) 相同的 SQL
-- `PLAN` 表示通过 Plan Digest 匹配所有模式 (Pattern) 相同的 SQL
-
-`WATCH` 中的 `DURATION` 选项，用于表示此识别项的持续时间，默认为无限长。
-
-添加监控项后，匹配特征和 `ACTION` 都不会随着 `QUERY_LIMIT` 配置的修改或删除而改变或删除。可以使用 `QUERY WATCH REMOVE` 来删除监控项。
-
-`QUERY_LIMIT` 具体格式如下：
-
-| 参数            | 含义           | 备注                                   |
-|---------------|--------------|--------------------------------------|
-| `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`。 |
-
-> **注意：**
->
-> 如果你想把 Runaway Queries 严格限制在一个资源组内，推荐将 `SWITCH_GROUP` 和 [`QUERY WATCH`](/tidb-resource-control.md#query-watch-语句说明) 语句一起搭配使用。因为 `QUERY_LIMIT` 只有在查询达到预设条件时才会触发，所以 `SWITCH_GROUP` 在此类场景下可能会出现无法及时将查询切换到目标资源组的情况。
-
-#### 示例
-
-1. 创建 `rg1` 资源组，限额是每秒 500 RU，并且定义超过 60 秒为 Runaway Query，并对 Runaway Query 降低优先级执行。
-
-    ```sql
-    CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN);
-    ```
-
-2. 修改 `rg1` 资源组，对 Runaway Query 直接终止，并且在接下来的 10 分钟里，把相同模式的查询直接标记为 Runaway Query。
-
-    ```sql
-    ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m');
-    ```
-
-3. 修改 `rg1` 资源组，取消 Runaway Queries 检查。
-
-    ```sql
-    ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL;
-    ```
-
-#### `QUERY WATCH` 语句说明
-
-语法详见 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)。
-
-参数说明如下：
-
-- `RESOURCE GROUP` 用于指定资源组。此语句添加的 Runaway Queries 监控特征将添加到该资源组的监控列表中。此参数可以省略，省略时作用于 `default` 资源组。
-- `ACTION` 的含义与 `QUERY LIMIT` 相同。此参数可以省略，省略时表示识别后的对应操作采用此时资源组中 `QUERY LIMIT` 配置的 `ACTION`，且不会随着 `QUERY LIMIT` 配置的改变而改变。如果资源组没有配置 `ACTION`，会报错。
-- `QueryWatchTextOption` 参数有 `SQL DIGEST`、`PLAN DIGEST`、`SQL TEXT` 三种类型。
-    - `SQL DIGEST` 的含义与 `QUERY LIMIT` `WATCH` 类型中的 `SIMILAR` 相同，后面紧跟的参数可以是字符串、用户自定义变量以及其他计算结果为字符串的表达式。字符串长度必须为 64，与 TiDB 中关于 Digest 的定义一致。
-    - `PLAN DIGEST` 的含义与 `PLAN` 相同。输入参数为 Digest 字符串。
-    - `SQL TEXT` 可以根据后面紧跟的参数，将输入的 SQL 的原始字符串（使用 `EXACT` 选项）作为模式匹配项，或者经过解析和编译转化为 `SQL DIGEST`（使用 `SIMILAR` 选项）、`PLAN DIGEST`（使用 `PLAN` 选项）来作为模式匹配项。
-
-- 为默认资源组的 Runaway Queries 监控列表添加监控匹配特征（需要提前为默认资源组设置 `QUERY LIMIT`）。
-
-    ```sql
-    QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2';
-    ```
-
-- 通过将 SQL 解析成 SQL Digest，为 `rg1` 资源组的 Runaway Queries 监控列表添加监控匹配特征。未指定 `ACTION` 时，使用 `rg1` 资源组已配置的 `ACTION`。
-
-    ```sql
-    QUERY WATCH ADD RESOURCE GROUP rg1 SQL TEXT SIMILAR TO 'select * from test.t2';
-    ```
-
-- 通过将 SQL 解析成 SQL Digest，为 `rg1` 资源组的 Runaway Queries 监控列表添加监控匹配特征，并指定 `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 Queries 监控列表添加监控匹配特征，并指定 `ACTION` 为 `KILL`。
-
-    ```sql
-    QUERY WATCH ADD RESOURCE GROUP rg1 ACTION KILL PLAN DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57';
-    ```
-
-- 通过查询 `INFORMATION_SCHEMA.RUNAWAY_WATCHES` 获取监控项 ID，删除该监控项。
-
-    ```sql
-    SELECT * FROM INFORMATION_SCHEMA.RUNAWAY_WATCHES ORDER BY id\G
-    ```
-
-    ```sql
-    *************************** 1. row ***************************
-                     ID: 1
-    RESOURCE_GROUP_NAME: default
-             START_TIME: 2024-09-09 03:35:31
-               END_TIME: 2024-09-09 03:45:31
-                  WATCH: Exact
-            WATCH_TEXT: SELECT variable_name, variable_value FROM mysql.global_variables
-                 SOURCE: 127.0.0.1:4000
-                ACTION: Kill
-                RULE: ProcessedKeys = 666(10)
-    1 row in set (0.00 sec)
-    ```
-
-    ```sql
-    QUERY WATCH REMOVE 1;
-    ```
-
-#### 可观测性
-
-可以通过以下系统表和 `INFORMATION_SCHEMA` 表获得 Runaway 相关的更多信息：
-
-+ `mysql.tidb_runaway_queries` 表中包含了过去 7 天内所有识别到的 Runaway Queries 的历史记录。以其中一行为例：
-
-    ```sql
-    MySQL [(none)]> SELECT * FROM mysql.tidb_runaway_queries LIMIT 1\G
-    *************************** 1. row ***************************
-    resource_group_name: default
-         start_time: 2024-09-09 17:43:42
-            repeats: 2
-         match_type: watch
-             action: kill
-         sample_sql: select sleep(2) from t
-         sql_digest: 4adbc838b86c573265d4b39a3979d0a362b5f0336c91c26930c83ab187701a55
-        plan_digest: 5d094f78efbce44b2923733b74e1d09233cb446318293492901c5e5d92e27dbc
-        tidb_server: 127.0.0.1:4000
-    ```
-
-    字段解释：
-
-    - `start_time` 为该 Runaway Query 被识别的时间。
-    - `repeats` 为该 Runaway Query 从 `start_time` 开始后被识别的次数。
-    - `match_type` 为该 Runaway Query 的来源，其值如下：
-        - `identify` 表示命中条件。
-        - `watch` 表示被快速识别机制命中。
-
-+ `information_schema.runaway_watches` 表中包含了 Runaway Queries 的快速识别规则记录。详见 [`RUNAWAY_WATCHES`](/information-schema/information-schema-runaway-watches.md)。
-
-### 管理后台任务
-
-> **警告：**
->
-> 该功能目前为实验特性，不建议在生产环境中使用。该功能可能会在未事先通知的情况下发生变化或删除。如果发现 bug，请[提交 issue](/support.md) 反馈。
->
-> 资源管控的后台任务管理是基于 TiKV 的 CPU/IO 的资源利用率动态调整资源配额的，因此它依赖各个实例可用资源上限 (Quota)。如果在单个服务器混合部署多个组件或实例，需要通过 cgroup 为各个实例设置合适的资源上限 (Quota)。TiUP Playground 这类共享资源的配置很难表现出预期效果。
-
-后台任务是指那些优先级不高但是需要消耗大量资源的任务，如数据备份和自动统计信息收集等。这些任务通常定期或不定期触发，在执行的时候会消耗大量资源，从而影响在线的高优先级任务的性能。
-
-自 v7.4.0 开始，TiDB 资源管控引入了对后台任务的管理。当一种任务被标记为后台任务时，TiKV 会动态地限制该任务的资源使用，以尽量避免此类任务在执行时对其他前台任务的性能产生影响。TiKV 通过实时地监测所有前台任务所消耗的 CPU 和 IO 等资源，并根据实例总的资源上限计算出后台任务可使用的资源阈值，所有后台任务在执行时会受此阈值的限制。
-
-#### `BACKGROUND` 参数说明
-
-- `TASK_TYPES`：设置需要作为后台任务管理的任务类型，多个任务类型以 `,` 分隔。
-- `UTILIZATION_LIMIT`：限制每个 TiKV 节点上后台任务最大可以使用的资源百分比 (0-100)。默认情况下，TiKV 会根据节点的总资源以及当前前台任务所占用的资源，来计算后台任务的可用资源。如果设置此限制，则实际分配给后台任务的资源不会超过此限制的比例。
-
-目前 TiDB 支持如下几种后台任务的类型：
-
-- `lightning`：使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 执行导入任务。同时支持 TiDB Lightning 的物理和逻辑导入模式。
-- `br`：使用 [BR](/br/backup-and-restore-overview.md) 执行数据备份和恢复。目前不支持 PITR。
-- `ddl`：对于 Reorg DDL，控制批量数据回写阶段的资源使用。
-- `stats`：对应手动执行或系统自动触发的[收集统计信息](/statistics.md#收集统计信息)任务。
-- `background`：预留的任务类型，可使用 [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-从-v740-版本开始引入) 系统变量指定当前会话的任务类型为 `background`。
-
-默认情况下，被标记为后台任务的任务类型为 `""`，此时后台任务的管理功能处于关闭状态。如需开启后台任务管理功能，你需要手动修改 `default` 资源组的后台任务类型以开启后台任务管理。后台任务类型被识别匹配后，资源管控会自动进行，即当系统资源紧张时，后台任务会自动降为最低优先级，保证前台任务的执行。
-
-> **注意：**
->
-> 目前，所有资源组的后台任务默认都会绑定到默认资源组 `default` 下进行管控，你可以通过 `default` 全局管控后台任务类型。暂不支持将后台任务绑定到其他资源组。
-
-#### 示例
-
-1. 修改 `default` 资源组，将 `br` 和 `ddl` 标记为后台任务，并配置后台任务最多可使用 TiKV 节点总资源的 30%。
-
-    ```sql
-    ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='br,ddl', UTILIZATION_LIMIT=30);
-    ```
-
-2. 修改 `default` 资源组，将后台任务的类型还原为默认值。
-
-    ```sql
-    ALTER RESOURCE GROUP `default` BACKGROUND=NULL;
-    ```
-
-3. 修改 `default` 资源组，将后台任务的类型设置为空，此时此资源组的所有任务类型都不会作为后台任务处理。
-
-    ```sql
-    ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES="");
-    ```
-
-4. 查看 `default` 资源组的后台任务类型。
-
-    ```sql
-    SELECT * FROM information_schema.resource_groups WHERE NAME="default";
-    ```
-
-    输出结果如下：
-
-    ```
-    +---------+------------+----------+-----------+-------------+-------------------------------------------+
-    | NAME    | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND                                |
-    +---------+------------+----------+-----------+-------------+-------------------------------------------+
-    | default | UNLIMITED  | MEDIUM   | YES       | NULL        | TASK_TYPES='br,ddl', UTILIZATION_LIMIT=30 |
-    +---------+------------+----------+-----------+-------------+-------------------------------------------+
-    ```
-
-5. 如果希望将当前会话里的任务显式标记为后台类型，你可以使用 `tidb_request_source_type` 显式指定任务类型，如：
-
-    ``` sql
-    SET @@tidb_request_source_type="background";
-    /* 添加 background 任务类型 */
-    ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES="background");
-    /* 在当前会话中执行 LOAD DATA */
-    LOAD DATA INFILE "s3://resource-control/Lightning/test.customer.aaaa.csv"
-    ```
-
 ## 关闭资源管控特性
 
 1. 执行以下命令关闭资源管控特性：
diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md
new file mode 100644
index 000000000000..ce68a5236446
--- /dev/null
+++ b/tidb-resource-control-runaway-queries.md
@@ -0,0 +1,165 @@
+---
+title: 管理资源消耗超出预期的查询 (Runaway Queries)
+summary: 介绍如何通过资源管控能力来实现对资源消耗超出预期的语句 (Runaway Queries) 进行控制和降级。
+---
+
+# 管理资源消耗超出预期的查询 (Runaway Queries)
+
+Runaway Query 是指执行时间或消耗资源超出预期的语句。下面使用 **Runaway Queries** 表示管理 Runaway Query 这一功能。
+
+- 自 v7.2.0 起，TiDB 资源管控引入了对 Runaway Queries 的管理。你可以针对某个资源组设置条件来识别 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 起，TiDB 资源管控引入了手动管理 Runaway Queries 监控列表的功能，将给定的 SQL 或者 Digest 添加到隔离监控列表，从而实现快速隔离 Runaway Queries。你可以执行语句 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)，手动管理资源组中的 Runaway Queries 监控列表。
+
+更多关于资源管控的信息，请参考[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md#相关参数)。
+
+## `QUERY_LIMIT` 参数说明
+
+如果查询超过以下任一限制，就会被识别为 Runaway Query：
+
+- `EXEC_ELAPSED`：检测查询执行的时间是否超限, 该规则适用于读写 DML。
+- `PROCESSED_KEYS`：检测 Coprocessor 处理的 key 的数量是否超限，该规则只适用于查询语句。
+- `RU`：检测执行语句消耗的总读写 RU 是否超限，该规则只适用于查询语句。
+
+支持的应对操作 (`ACTION`)：
+
+- `DRYRUN`：对执行 Query 不做任何操作，仅记录识别的 Runaway Query。主要用于观测设置条件是否合理。
+- `COOLDOWN`：将查询的执行优先级降到最低，查询仍旧会以低优先级继续执行，不占用其他操作的资源。
+- `KILL`：识别到的查询将被自动终止，报错 `Query execution was interrupted, identified as runaway query`。
+- `SWITCH_GROUP`：从 v8.4.0 开始引入，将识别到的查询切换到指定的资源组继续执行。该查询执行结束后，后续 SQL 仍保持在原资源组中执行。如果指定的资源组不存在，则不做任何动作。
+
+为了避免并发的 Runaway Query 过多导致系统资源耗尽，资源管控引入了 Runaway Query 监控机制，能够快速识别并隔离 Runaway Query。该功能通过 `WATCH` 子句实现，当某一个查询被识别为 Runaway Query 之后，会提取这个查询的匹配特征（由 `WATCH` 后的匹配方式参数决定），在接下来的一段时间里（由 `DURATION` 定义），这个 Runaway Query 的匹配特征会被加入到监控列表，TiDB 实例会将查询和监控列表进行匹配，匹配到的查询直接标记为 Runaway Query，而不再等待其被条件识别，并按照当前应对操作进行隔离。其中 `KILL` 会终止该查询，并报错 `Quarantined and interrupted because of being in runaway watch list`。
+
+`WATCH` 有三种匹配方式：
+
+- `EXACT` 表示完全相同的 SQL 才会被快速识别
+- `SIMILAR` 表示会忽略字面值 (Literal)，通过 SQL Digest 匹配所有模式 (Pattern) 相同的 SQL
+- `PLAN` 表示通过 Plan Digest 匹配所有模式 (Pattern) 相同的 SQL
+
+`WATCH` 中的 `DURATION` 选项，用于表示此识别项的持续时间，默认为无限长。
+
+添加监控项后，匹配特征和 `ACTION` 都不会随着 `QUERY_LIMIT` 配置的修改或删除而改变或删除。可以使用 `QUERY WATCH REMOVE` 来删除监控项。
+
+`QUERY_LIMIT` 具体格式如下：
+
+| 参数            | 含义           | 备注                                   |
+|---------------|--------------|--------------------------------------|
+| `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`。 |
+
+> **注意：**
+>
+> 如果你想把 Runaway Queries 严格限制在一个资源组内，推荐将 `SWITCH_GROUP` 和 [`QUERY WATCH`](#query-watch-语句说明) 语句一起搭配使用。因为 `QUERY_LIMIT` 只有在查询达到预设条件时才会触发，所以 `SWITCH_GROUP` 在此类场景下可能会出现无法及时将查询切换到目标资源组的情况。
+
+## 示例
+
+1. 创建 `rg1` 资源组，限额是每秒 500 RU，并且定义超过 60 秒为 Runaway Query，并对 Runaway Query 降低优先级执行。
+
+    ```sql
+    CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN);
+    ```
+
+2. 修改 `rg1` 资源组，对 Runaway Query 直接终止，并且在接下来的 10 分钟里，把相同模式的查询直接标记为 Runaway Query。
+
+    ```sql
+    ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m');
+    ```
+
+3. 修改 `rg1` 资源组，取消 Runaway Queries 检查。
+
+    ```sql
+    ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL;
+    ```
+
+## `QUERY WATCH` 语句说明
+
+语法详见 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)。
+
+参数说明如下：
+
+- `RESOURCE GROUP` 用于指定资源组。此语句添加的 Runaway Queries 监控特征将添加到该资源组的监控列表中。此参数可以省略，省略时作用于 `default` 资源组。
+- `ACTION` 的含义与 `QUERY LIMIT` 相同。此参数可以省略，省略时表示识别后的对应操作采用此时资源组中 `QUERY LIMIT` 配置的 `ACTION`，且不会随着 `QUERY LIMIT` 配置的改变而改变。如果资源组没有配置 `ACTION`，会报错。
+- `QueryWatchTextOption` 参数有 `SQL DIGEST`、`PLAN DIGEST`、`SQL TEXT` 三种类型。
+    - `SQL DIGEST` 的含义与 `QUERY LIMIT` `WATCH` 类型中的 `SIMILAR` 相同，后面紧跟的参数可以是字符串、用户自定义变量以及其他计算结果为字符串的表达式。字符串长度必须为 64，与 TiDB 中关于 Digest 的定义一致。
+    - `PLAN DIGEST` 的含义与 `PLAN` 相同。输入参数为 Digest 字符串。
+    - `SQL TEXT` 可以根据后面紧跟的参数，将输入的 SQL 的原始字符串（使用 `EXACT` 选项）作为模式匹配项，或者经过解析和编译转化为 `SQL DIGEST`（使用 `SIMILAR` 选项）、`PLAN DIGEST`（使用 `PLAN` 选项）来作为模式匹配项。
+
+- 为默认资源组的 Runaway Queries 监控列表添加监控匹配特征（需要提前为默认资源组设置 `QUERY LIMIT`）。
+
+    ```sql
+    QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2';
+    ```
+
+- 通过将 SQL 解析成 SQL Digest，为 `rg1` 资源组的 Runaway Queries 监控列表添加监控匹配特征。未指定 `ACTION` 时，使用 `rg1` 资源组已配置的 `ACTION`。
+
+    ```sql
+    QUERY WATCH ADD RESOURCE GROUP rg1 SQL TEXT SIMILAR TO 'select * from test.t2';
+    ```
+
+- 通过将 SQL 解析成 SQL Digest，为 `rg1` 资源组的 Runaway Queries 监控列表添加监控匹配特征，并指定 `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 Queries 监控列表添加监控匹配特征，并指定 `ACTION` 为 `KILL`。
+
+    ```sql
+    QUERY WATCH ADD RESOURCE GROUP rg1 ACTION KILL PLAN DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57';
+    ```
+
+- 通过查询 `INFORMATION_SCHEMA.RUNAWAY_WATCHES` 获取监控项 ID，删除该监控项。
+
+    ```sql
+    SELECT * FROM INFORMATION_SCHEMA.RUNAWAY_WATCHES ORDER BY id\G
+    ```
+
+    ```sql
+    *************************** 1. row ***************************
+                     ID: 1
+    RESOURCE_GROUP_NAME: default
+             START_TIME: 2024-09-09 03:35:31
+               END_TIME: 2024-09-09 03:45:31
+                  WATCH: Exact
+            WATCH_TEXT: SELECT variable_name, variable_value FROM mysql.global_variables
+                 SOURCE: 127.0.0.1:4000
+                ACTION: Kill
+                RULE: ProcessedKeys = 666(10)
+    1 row in set (0.00 sec)
+    ```
+
+    ```sql
+    QUERY WATCH REMOVE 1;
+    ```
+
+## 可观测性
+
+可以通过以下系统表和 `INFORMATION_SCHEMA` 表获得 Runaway 相关的更多信息：
+
++ `mysql.tidb_runaway_queries` 表中包含了过去 7 天内所有识别到的 Runaway Queries 的历史记录。以其中一行为例：
+
+    ```sql
+    MySQL [(none)]> SELECT * FROM mysql.tidb_runaway_queries LIMIT 1\G
+    *************************** 1. row ***************************
+    resource_group_name: default
+         start_time: 2024-09-09 17:43:42
+            repeats: 2
+         match_type: watch
+             action: kill
+         sample_sql: select sleep(2) from t
+         sql_digest: 4adbc838b86c573265d4b39a3979d0a362b5f0336c91c26930c83ab187701a55
+        plan_digest: 5d094f78efbce44b2923733b74e1d09233cb446318293492901c5e5d92e27dbc
+        tidb_server: 127.0.0.1:4000
+    ```
+
+    字段解释：
+
+    - `start_time` 为该 Runaway Query 被识别的时间。
+    - `repeats` 为该 Runaway Query 从 `start_time` 开始后被识别的次数。
+    - `match_type` 为该 Runaway Query 的来源，其值如下：
+        - `identify` 表示命中条件。
+        - `watch` 表示被快速识别机制命中。
+
++ `information_schema.runaway_watches` 表中包含了 Runaway Queries 的快速识别规则记录。详见 [`RUNAWAY_WATCHES`](/information-schema/information-schema-runaway-watches.md)。
\ No newline at end of file
diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md
index 7912ea973472..986b6bb15210 100644
--- a/tiflash/tiflash-pipeline-model.md
+++ b/tiflash/tiflash-pipeline-model.md
@@ -10,7 +10,7 @@ summary: 介绍 TiFlash 新的执行模型 Pipeline Model。
 从 v7.2.0 起，TiFlash 支持新的执行模型 Pipeline Model。
 
 - v7.2.0 和 v7.3.0：TiFlash Pipeline Model 为实验特性，使用 [`tidb_enable_tiflash_pipeline_model`](https://docs.pingcap.com/zh/tidb/v7.2/system-variables#tidb_enable_tiflash_pipeline_model-从-v720-版本开始引入) 控制。
-- v7.4.0 及之后版本：Pipeline Model 成为正式功能。Pipeline Model 属于 TiFlash 内部特性，并且与 TiFlash 资源管控功能绑定，开启 TiFlash 资源管控功能时，Pipeline Model 模型将自动启用。关于 TiFlash 资源管控功能的使用方式，参考[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md#相关参数)。同时，从 v7.4.0 开始，变量 `tidb_enable_tiflash_pipeline_model` 被废弃。
+- v7.4.0 及之后版本：Pipeline Model 成为正式功能。Pipeline Model 属于 TiFlash 内部特性，并且与 TiFlash 资源管控功能绑定，开启 TiFlash 资源管控功能时，Pipeline Model 模型将自动启用。关于 TiFlash 资源管控功能的使用方式，参考[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md#相关参数)。同时，从 v7.4.0 开始，变量 `tidb_enable_tiflash_pipeline_model` 被废弃。
 
 Pipeline Model 主要借鉴了 [Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework for the Many-Core Age](https://dl.acm.org/doi/10.1145/2588555.2610507) 这篇论文，提供了一个精细的任务调度模型，有别于传统的线程调度模型，减少了操作系统申请和调度线程的开销以及提供精细的调度机制。
 
diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md
index 966d2daef630..3fbf03463239 100644
--- a/tikv-configuration-file.md
+++ b/tikv-configuration-file.md
@@ -2452,7 +2452,7 @@ Raft Engine 相关的配置项。
 
 ### `enabled` <span class="version-mark">从 v6.6.0 版本开始引入</span>
 
-+ 是否支持对用户前台的读写请求按照对应的资源组配额做优先级调度。有关 TiDB 资源组和资源管控的信息，请参考 [TiDB 资源管控](/tidb-resource-control.md)
++ 是否支持对用户前台的读写请求按照对应的资源组配额做优先级调度。有关 TiDB 资源组和资源管控的信息，请参考[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)
 + 在 TiDB 侧开启 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-从-v660-版本开始引入) 全局变量的情况下，开启这个配置项才有意义。此配置参数开启后，TiKV 会使用优先级队列对排队的用户前台读写请求做调度，调度的优先级和请求所在资源组已经消费的资源量反相关，和对应资源组的配额正相关。
 + 默认值：true（即开启按照资源组配额调度）
 
diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md
index 37350cdb215f..7e80f65c1530 100644
--- a/tiproxy/tiproxy-load-balance.md
+++ b/tiproxy/tiproxy-load-balance.md
@@ -40,7 +40,7 @@ TiProxy 定时通过 SQL 端口和状态端口检查 TiDB 是否已下线或正
 1. 在 TiProxy 上配置 [`balance.label-name`](/tiproxy/tiproxy-configuration.md#label-name) 为 `"app"`，表示将按照标签名 `"app"` 匹配 TiDB server，并将连接路由到相同标签值的 TiDB server 上。
 2. 配置 2 台 TiProxy 实例，分别为配置项 [`labels`](/tiproxy/tiproxy-configuration.md#labels) 加上 `"app"="Order"` 和 `"app"="BI"`。
 3. 将 TiDB 实例分为 2 组，分别为配置项 [`labels`](/tidb-configuration-file.md#labels) 加上 `"app"="Order"` 和 `"app"="BI"`。 
-4. 如果需要同时隔离存储层的资源，可配置 [Placement Rules](/configure-placement-rules.md) 或[资源管控](/tidb-resource-control.md)。
+4. 如果需要同时隔离存储层的资源，可配置 [Placement Rules](/configure-placement-rules.md) 或[资源管控 (Resource Control)](/tidb-resource-control-ru-groups.md)。
 5. 交易和 BI 业务的客户端分别连接到 2 台 TiProxy 的地址。
 
 <img src="https://download.pingcap.com/images/docs-cn/tiproxy/tiproxy-balance-label.png" alt="基于标签的负载均衡" width="600" />
diff --git a/tiproxy/tiproxy-traffic-replay.md b/tiproxy/tiproxy-traffic-replay.md
index ade5e33e2bc3..85ec7e636e1d 100644
--- a/tiproxy/tiproxy-traffic-replay.md
+++ b/tiproxy/tiproxy-traffic-replay.md
@@ -185,7 +185,7 @@ tiproxyctl traffic cancel --host 10.0.1.10 --port 3080
 
 - TiProxy 仅支持回放 TiProxy 捕获的流量文件，不支持其他文件格式，因此生产集群必须先使用 TiProxy 捕获流量。
 - TiProxy 不支持过滤 SQL 类型，DML 和 DDL 语句也会被回放，因此重新回放前需要将集群数据恢复到回放前的状态。
-- 由于 TiProxy 使用同一个用户名回放流量，因此无法测试[资源管控](/tidb-resource-control.md)和[权限管理](/privilege-management.md)。
+- 由于 TiProxy 使用同一个用户名回放流量，因此无法测试[资源管控 (Resource Control)](/tidb-resource-control-ru-groups.md) 和[权限管理](/privilege-management.md)。
 - 不支持回放 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) 语句。
 
 ## 资源
diff --git a/user-account-management.md b/user-account-management.md
index 995960d98904..29e3e5677d1a 100644
--- a/user-account-management.md
+++ b/user-account-management.md
@@ -149,7 +149,7 @@ TiDB 在数据库初始化时会生成一个 `'root'@'%'` 的默认账户。
 
 ## 设置资源限制
 
-TiDB 可以利用资源组对用户消耗的资源进行限制，详情参见[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)。
+TiDB 可以利用资源组对用户消耗的资源进行限制，详情参见[使用资源管控 (Resource Control) 实现资源组限制和流控](/tidb-resource-control-ru-groups.md)。
 
 ## 设置密码