TiDB 7.1.0 LTS 特性解读丨关于资源管控 (Resource Control) 应该知道的 6 件事

TiDB 7.1.0 LTS 在前段时间发布，相信很多同学都已经抢先使用了起来，甚至都已然经过一系列验证推向了生产环境。面对 TiDB 7.1 若干重要特性，新 GA 的资源管控 (Resource Control) 是必须要充分理解、测试的一个重量级特性。对于常年奋斗在一线 DBA 岗位的我来说，学术方面的精进已经力不从心，大部分的时间都在强化“术”的方面，所以 TiDB 每更（新）必追，每个新 GA 的特性都要熟悉，这样当生产环境 TiDB 升级到目标版本后，才不至于手忙脚乱，新建 TiDB 集群后才能对新特性驾轻就熟。相信本文会给读者朋友们带来一些实质性的收获。言归正传，本文将围绕“资源管控”主题，详细说说关于 “资源管控” 您应该知道的 6 件事。

从用户场景出发，看特性如何使用

从 200+ 的国产数据库中脱颖而出，其有效、完备的文档当属“功不可没”。在 TiDB 7.1 的文档中是这样描述 使用场景 的：

资源管控特性的引入对 TiDB 具有里程碑的意义。它能够将一个分布式数据库集群划分成多个逻辑单元，即使个别单元对资源过度使用，也不会挤占其他单元所需的资源。利用该特性：

○ 你可以将多个来自不同系统的中小型应用合入一个 TiDB 集群中，个别应用的负载升高，不会影响其他业务的正常运行。而在系统负载较低的时候，繁忙的应用即使超过设定的读写配额，也仍然可以被分配到所需的系统资源，达到资源的最大化利用。

○ 你可以选择将所有测试环境合入一个集群，或者将消耗较大的批量任务编入一个单独的资源组，在保证重要应用获得必要资源的同时，提升硬件利用率，降低运行成本。

○ 当系统中存在多种业务负载时，可以将不同的负载分别放入各自的资源组。利用资源管控技术，确保交易类业务的响应时间不受数据分析或批量业务的影响。

○ 当集群遇到突发的 SQL 性能问题，可以结合 SQL Binding 和资源组，临时限制某个 SQL 的资源消耗。

那么，从务实的 DBA 角度来看这段话，可能会是下面这个样子：

资源管控，这一新特性，将数据库中的用户、会话、SQL 等日常行为的性能指标做了更加细致的量化处理。引入了 “Request Unit (RU)” 这一量化概念，目前包括了 CPU, IOPS, IO 带宽 三个重要指标，未来还会增加内存、网络等指标。

○ 可以将若干 MySQL 数据库合并进一个 TiDB 集群，比如读写峰值常出现于日间的 OA 系统，读写峰值常出现于夜间的 Batch 系统，以及 24 小时运行但负载持续稳定的数据采集系统，这种“三合一”的方式，使得各系统“错峰出行”，借助资源管控的能力“按需分配”，以此达到降低综合成本的目标。

○ 在一个 TiDB 集群，为不同测试环境 (Env) 创建不同测试用户 (User)，然后依据测试所需资源规格创建不同资源组 (Resource Group)，并将用户与对应的资源组做绑定。如此做到了不同用户的资源隔离，由于是测试环境，可将资源组设置为 超限 ( BURSTABLE ) ，或者理解为“超卖”，某个或某几个用户使用的资源超过了资源组规定的限制，依旧可以正常使用，而不影响测试，可以最大化利用硬件资源。不过，这里的测试应该理解为业务测试，而非标准的性能测试，不然需要更加严谨的考虑资源分配以及 超限 ( BURSTABLE ) 的使用。

○ 类似于第一节中的描述，三个系统分别对应三个资源组，且 BURSTABLE 的设定为 NO，那么三个系统使用的资源将是隔离的，不受彼此影响。也就是说，在当前 TiDB 集群中，即使 TP、AP 业务同时运行，由于使用了资源控制特性，此时 TP 业务并不会受到 AP 业务的干扰。

○ 业务是不断变化的，“Bad SQL” 问题随时可能发生，如果某条 SQL 占用资源 (RU) 过高，影响该用户的其他 SQL 性能。此时，可以新建一个资源组，并可以使用 执行计划绑定(SQL Binding)功能 ，将该 SQL 语句绑定到新建的资源组上，以起到限制 SQL 资源消耗，甚至拒绝 SQL 执行的目的。测试 SQL 如下：

CREATE RESOURCE GROUP rg1 RU_per_SEC=1;
​
CREATE GLOBAL BINDING FOR
  SELECT COUNT(*) FROM t1 t JOIN t1 t2 USING (uid) 
USING
  SELECT /*+ resource_group(rg1) */ COUNT(*) FROM t1 t JOIN t1 t2 USING (uid);
​
EXPLAIN ANALYZE FORMAT = 'verbose' SELECT COUNT(*) FROM t t1 JOIN t1 t2 USING (uid);

为了实现上述场景，TiDB 实现了若干 SQL 语法，接下来看看如何具体操作。

“资源控制”相关SQL，用这些就够了

研究 TiDB 的人还有不知道 AskTUG [1] 的么？半年前，@社区小助手 整理了一篇极具实用价值的帖子 -- 【社区智慧合集】TiDB 相关 SQL 脚本大全 [2] ， 内含 38 条实用 SQL，是 TiDBer 们必收藏的帖子之一。

彼时“资源控制”功能尚未“问世”，所以帖子里并不包含该特性相关 SQL，下面我将“资源控制”相关的精华 SQL 贴出，以供参考。

1) 增删改查 -- 资源组 (Resource Group)

• 增：

-- 创建 `rg1` 资源组，限额是每秒 `500 RU`，优先级为 `HIGH`，允许这个资源组的超额 (`BURSTABLE`) 占用资源。
CREATE RESOURCE GROUP IF NOT EXISTS rg1 
  RU_PER_SEC = 100
  PRIORITY = HIGH
  BURSTABLE;
​
-- 创建 `rg2` 资源组，限额是每秒 `500 RU`，其他选项为默认值。
CREATE RESOURCE GROUP rg2 RU_PER_SEC = 200;

• 删：

-- 删除资源组
DROP RESOURCE GROUP rg2;

• 改：

-- 修改资源组资源配置
ALTER RESOURCE GROUP rg2 ru_per_sec = 2000;

• 查：

-- 通过 I_S 表查看
SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS;

需要注意的是，创建、修改、删除资源组，需要拥有 SUPER 或者 RESOURCE_GROUP_ADMIN 权限，否则会遇到报错：

ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or RESOURCE_GROUP_ADMIN privilege(s) for this operation

2) 绑定用户到 Resource Group

• 将某个用户绑定到资源组

将用户和资源组绑定很简单，其实就是修改用户的属性。如果是已创建的用户，可以用 ALTER USER ，如果是新建用户，则可用 CREATE USER 。

-- CREATE
CREATE USER u3 RESOURCE GROUP rg3;
-- ALTER
ALTER USER u2 RESOURCE GROUP rg2;

• 查看某个用户绑定到资源组

这里有两种方法和二个问题，两种方法是分别通过 mysql 库和 INFORMATION_SCHEMA 库进行查询。

mysql> SELECT User, JSON_EXTRACT(User_attributes, "$.resource_group") AS RG FROM mysql.user ;
+------+-----------+
| User | RG        |
+------+-----------+
| root | NULL      |
| u1   | "default" |
| u2   | "rg2"     |
| u3   | ""        |
+------+-----------+
4 rows in set (0.00 sec)

问题一：Resource Group 的 ** 和 default 等同**

从上面的查询结果来看，除了普通用户 u2 绑定的资源组 rg2 之外，其余三个用户其实都使用的是默认资源组，即 default 。只是这里出现了空 (``)，可能会造成稍许疑虑，经与官方同学确认， “空和 default 在行为上面是一样的” 。交流帖子参见： resource control，default resource group 文档勘误 [3]

问题二：通过 INFORMATION_SCHEMA.USER_ATTRIBUTES 暂无法查询用户绑定的资源组

普通用户是无权通过 mysql 库查询哪些用户绑定了哪些资源组的，包括当前用户，但是每个用户都可以通过 I_S 库查询自己应该可以获取的信息。所以方法二，是指普通用户通过查询 I_S 库来获取相关信息，SQL 如下：

SELECT * FROM INFORMATION_SCHEMA.U