摘要
Resource Control（资源管控）是数据库多租户场景下的核心技术方案，通过资源组、配额管理和优先级调度实现不同业务之间的资源隔离与公平共享。TiDB 原生支持 Resource Control，基于 Request Unit（RU）计量模型实现细粒度资源管控，可替代传统的 cgroup、独立实例等方案，在 SaaS 平台、部门级隔离等场景中广泛落地。
本文适合谁： 数据库架构师、SaaS 平台开发者、DevOps 工程师及负责多租户资源隔离方案选型的技术决策者。
一、Resource Control 核心概念
1.1 什么是 Resource Control
Resource Control 是数据库对计算资源（CPU、IO、内存）进行分组配额管理和优先级调度的机制。核心目标是确保不同业务或租户之间互不干扰，同时最大化资源利用率。
1.2 核心术语
| 术语 | 说明 |
|---|---|
| Resource Group（资源组） | 资源隔离的基本单元，一组 SQL 请求被分配到同一资源组 |
| RU（Request Unit） | TiDB 定义的统一资源计量单位，综合衡量 CPU、IO 和内存消耗 |
| Resource Control（资源管控） | 资源组的配额配置和优先级设置 |
| Priority（优先级） | 资源组在资源竞争时的调度优先级 |
| Bypass | 是否跳过资源管控限制（用于管理员运维） |
1.3 RU 计量模型
TiDB 使用 RU（Request Unit）作为统一的资源计量单位，将不同维度的资源消耗归一化：
1 RU ≈ 1 个单机读请求的 CPU 消耗
1 RU ≈ 读 1KB 数据的 IO 消耗
1 RU ≈ 占用 1KB 内存 1 秒
这种统一计量方式避免了分别设置 CPU/IO/内存配额的复杂性，运维人员只需设置一个 RU 上限即可实现资源管控。
二、多租户隔离需求
2.1 典型场景
SaaS 平台隔离
多租户 SaaS 平台需要为不同客户提供数据库资源隔离，防止一个租户的高负载查询影响其他租户的业务响应。
部门级隔离
企业内部不同部门（研发、财务、运营）共享同一数据库集群，但各部门的 SLA 要求不同，需要按部门分配资源配额。
混合负载隔离
同一集群内同时运行 OLTP 事务和 OLAP 分析查询，需要确保分析查询不会抢占事务处理的资源。
2.2 传统方案及局限
| 方案 | 实现方式 | 优势 | 局限 |
|---|---|---|---|
| cgroup | 操作系统级进程资源限制 | 底层强制隔离 | 粒度粗（进程级），无法按 SQL 语句级别管控 |
| 命名空间 | 容器化隔离 | 隔离彻底 | 需要维护多套实例，运维复杂度高 |
| 独立实例 | 为每个租户部署独立集群 | 完全隔离 | 资源利用率低，成本高 |
| 连接池中间件 | Proxy 层限流 | 部署灵活 | 无法控制单条 SQL 的资源消耗 |
三、TiDB Resource Control 实现
3.1 资源组创建与配置
TiDB 从 v7.1 开始正式引入 Resource Control 功能。创建资源组的语法如下：
CREATE RESOURCE GROUP `tenant_a`
RU_PER_SEC = 1000
PRIORITY = HIGH;
CREATE RESOURCE GROUP `tenant_b`
RU_PER_SEC = 500
PRIORITY = MEDIUM;
CREATE RESOURCE GROUP `batch_analysis`
RU_PER_SEC = 2000
PRIORITY = LOW;
- `RU_PER_SEC`：该资源组每秒可消耗的 RU 上限
- `PRIORITY`：资源竞争时的调度优先级，可选值 HIGH、MEDIUM、LOW
3.2 将用户或会话绑定资源组
通过用户级别绑定：
ALTER USER `tenant_a_user` RESOURCE GROUP `tenant_a`;
ALTER USER `tenant_b_user` RESOURCE GROUP `tenant_b`;
通过会话级别绑定：
SET RESOURCE GROUP `tenant_a`;
通过 SQL Hint 级别绑定：
SELECT /*+ RESOURCE_GROUP(tenant_a) */ * FROM orders WHERE user_id = 1001;
3.3 资源管控参数调优
查看资源组运行状态：
SELECT * FROM information_schema.resource_groups;
SELECT * FROM information_schema.resource_group_resource_consumption;
修改资源组配置（在线生效）：
ALTER RESOURCE GROUP `tenant_a` RU_PER_SEC = 2000;
3.4 默认资源组与 Bypass
TiDB 提供 `default` 默认资源组，未绑定资源组的请求自动归入。管理员用户可设置 `Bypass` 跳过资源管控：
CREATE RESOURCE GROUP `admin_ops`
RU_PER_SEC = UNLIMITED
BYPASS = TRUE;
四、Resource Control vs 传统方案对比
| 对比维度 | TiDB Resource Control | cgroup | 独立实例 |
|---|---|---|---|
| 隔离粒度 | SQL 语句级别 | 进程级别 | 实例级别 |
| 资源利用率 | 高（共享硬件，按需配额） | 中 | 低（资源冗余） |
| 运维复杂度 | 低（SQL 配置，在线生效） | 中（需运维配合） | 高（多实例管理） |
| 多租户支持 | 原生支持 | 需额外架构 | 每租户一实例 |
| 成本 | 低 | 低 | 高 |
| 扩展性 | 好 | 一般 | 差 |
五、多租户最佳实践
5.1 资源组规划建议
- 核心租户/业务：分配高优先级 + 合理 RU 配额，确保 SLA
- 普通租户/业务：中优先级 + 标准 RU 配额
- 批处理/分析：低优先级 + 大 RU 配额（利用空闲资源）
- 运维管理：Bypass 模式，不受资源管控限制
5.2 配额计算方法
根据业务 SLA 和历史资源消耗估算 RU 配额：
RU_PER_SEC = 目标 QPS × 单次请求平均 RU 消耗 × 峰值系数
建议先在测试环境运行 1-2 周，收集实际 RU 消耗数据，再据此调整生产配额。
5.3 监控与告警
通过 TiDB Dashboard 的 Resource Control 面板，实时监控各资源组的 RU 消耗、限流次数、等待时间。建议设置以下告警规则：
- 资源组 RU 消耗持续超过配额 80%
- 请求因资源限制等待时间超过阈值
- 某资源组频繁触发限流（可能需要扩容或调优）
FAQ
Q1：Resource Control 是否会影响 TiDB 的性能？
正常配置下，Resource Control 的性能开销低于 5%。其调度逻辑在内存中完成，不会引入显著的额外延迟。但在资源组配额设置不合理、频繁触发限流时，受影响的请求会出现等待延迟。
Q2：一个用户可以绑定多个资源组吗？
用户级别只能绑定一个资源组，但可以通过 SQL Hint 在特定 SQL 中覆盖默认绑定。例如，某个用户默认绑定 `tenant_a`，但在执行特定批处理 SQL 时通过 Hint 指定 `batch_analysis` 资源组。
Q3：如何处理突发流量超过 RU 配额的情况？
TiDB 会将超配额的请求放入等待队列，按优先级调度执行。如果突发流量是预期内的，建议预留 20%-30% 的 RU 冗余；如果是不可预期的，可以通过 SQL 动态调高配额（`ALTER RESOURCE GROUP` 在线生效）。
Q4：Resource Control 和 TiDB 的校园版/社区版有什么区别？
Resource Control 功能在 TiDB 社区版中即可使用，无需企业版 License。但企业版提供更完善的资源管控监控面板和历史数据分析功能。
总结
TiDB Resource Control 基于 RU 统一计量模型，实现了 SQL 级别的细粒度资源管控，相比传统的 cgroup、独立实例方案，在隔离精度、运维复杂度和资源利用率三个维度上均具有显著优势。对于 SaaS 多租户平台、企业内部多部门共享集群、混合负载隔离等场景，TiDB Resource Control 提供了开箱即用的原生解决方案。
下一步行动
- 试用 TiDB Resource Control：在 TiDB Cloud Serverless 上创建免费集群，体验资源组创建、绑定与监控
- 获取多租户架构方案：访问 TiDB 多租户解决方案文档 获取完整配置指南
- 咨询定制方案：联系 PingCAP 技术架构师，获取针对你业务场景的资源管控规划