导读

资源隔离是数据库性能优化的重要环节， TiDB 在当前版本已经实现了从数据级隔离到流控隔离的全面升级 ，无论是多系统共享集群、复杂负载隔离，还是小型系统整合和 SQL 精细化控制，TiDB 都提供了灵活且高效的解决方案。

本文以实际案例为切入点，详细解读了 Placement Rules in SQL、Resource Control 等关键功能，以及 7.2+ 版本新增的 Runaway Queries 管理机制， 帮助各位开发者和管理员选择最适合自己的 TiDB 资源隔离方案。

---

你需要什么样的隔离？

时至今日，TiDB 提供的隔离能力愈发完善，上到不同系统、下到 SQL 语句，均能实现良好的隔离效果。本文旨在帮助大家了解：你需要什么层面的资源隔离，以及各种层面隔离如何使用。

基于数据的隔离方案

中大型系统之间隔离

在提及资源隔离时，大家往往想到的是：多个系统共用一套集群，如何限制每个系统所用的资源。在之前版本中，TiDB 提供了基于 K8s 的 Cloud TiDB 方案，但企业 DBA 很少同时具备 K8s 和数据库两种技能；另外企业中 K8S 大部分也非原生，不一定满足 Cloud TiDB 的部署需求。

从 6.5 版本开始，TiDB 提供了 Placement Rules in SQL 功能，一种基于 SQL 规则的数据放置策略，可以轻松实现数据级别的物理隔离，使得多个系统共用一套 TiDB 集群时，满足物理层面隔离的需求。

典型场景：多系统共用集群并完全独占资源

典型客户案例： TiDB x 云盛海宏丨加速精细化运营，云海零售系统的架构演进

示例： Placement Rules in SQL 规则（适合中大型系统）

create placement policy policy_order constraints="[+zone=order]"; 
create placement policy policy_inv constraints="[+zone=inventory]"; 
alter database retail_order placement policy policy_order;
alter database retail_inventory placement policy policy_inv;

典型场景：每个系统仅独占一个实例、单点故障时共享

典型客户案例： 某领先零售企业 TiDB 生产集群架构

示例： Placement Rules in SQL 规则（适合中型系统）

create placement policy policy_server1 leader_constraints="[+host=host1]"; 
create placement policy policy_server2 leader_constraints="[+host=host2]"; 
create placement policy policy_server3 leader_constraints="[+host=host3]"; 
alter database DB1 placement policy policy_server1;
alter database DB2 placement policy policy_server2;
alter database DB3 placement policy policy_server3;

系统内不同负载隔离

以上是多个系统之间的隔离，在一个业务系统内，同样也会有基于负载的隔离需求（如 OLTP 和 ETL/报表两种负载）；也就是过去常提及的读写分离，在一套数据库内，实现两种负载的隔离。

在使用 TiDB 时，由于一套集群已经由多台服务器组成，如再建设一套配置相同的备集群来实现，此时成本相对是比较高的。从 6.5 版本开始，也可以轻松使用 Placement Rule/Placement Rules in SQL + Follower 副本读取策略来实现，同时与传统主备/主从读写分离相比：TiDB 的只读区域（含 TiKV/TiFlash）可提供与联机完全一致的查询能力。

典型场景：联机事务处理 +ETL|BI 隔离

典型客户案例： HTAP 还可以这么玩？丨TiDB 在 IoT 智慧园区的应用

示例：

• Placement Rules in SQL 规则（针对业务数据，Leader 分布在前两台 TiKV）；

create placement policy policy_eyas leader_constraints="[-zone=zone3]"; 
alter database eyas placement policy policy_eyas;

• Placement Rules in SQL 规则（针对运营数据，Leader 分布在第三台 TiKV）；

create placement policy policy_bi leader_constraints="[+zone=zone3]" follower_constraints ='{"+zone=zone1": 1,"+zone=zone2": 1}';
alter database bi_eyas placement policy policy_bi;
alter database da_ping placement policy policy_bi;
alter database eyasbi placement policy policy_bi;

• 业务库+运营库均增加列存副本；
• TiDB 设置就近读。

set global tidb_replica_read = 'closest-replicas';

典型场景：联机事务处理+复杂查询隔离

典型案例： 2 机房双活+1 机房就近只读

注： zone 是 tikv 中一个 label 的定义，可以代表一个真实的机房，也可以单机房集群中设计一个 zone

示例：

• Placement Rule 规则（设置全局 Leader 和 Follower 分布策略）， 机房 q03 不分布任何 Leader，同时 q03 机房进行本地读取；

[{"group_id": "pd","id": "q01","start_key": "","end_key": "","role": "voter","count": 1,"label_constraints": [{"key": "zone", "op": "in", "values": ["q01"]}],"location_labels": ["host"]},{"group_id": "pd","id": "q02","start_key": "","end_key": "","role": "voter","count": 1,"label_constraints": [{"key": "zone", "op": "in", "values": ["q02"]}],"location_labels": ["host"]},{"group_id": "pd","id": "q03","start_key": "","end_key": "","role": "follower","count": 1,"label_constraints": [{"key": "zone", "op": "in", "values": ["q03"]}],"location_labels": ["host"]}
]

• TiDB 设置就近读。

set global tidb_replica_read='closest-replicas';

基于流控的的隔离方案

基于数据隔离的方案虽然能够有效地实现 CPU、内存、磁盘等资源的物理隔离，但也存在一定的灵活性问题：

• 数据需要与存储节点进行绑定（也就是资源的最小单位是节点），该方案仅适用于中大型系统之间的隔离，基本不适应于小型系统
• 在扩缩容时，该方案可能需要迁移底层数据，无法立即生效
• 如果集群中仅有一套库表供多个系统共享，此时基于数据的隔离方案便无法工作了

为了解决以上不足，TiDB 自 7.1 版本起引入了基于流控的隔离方案 - Resource Control，目的是简化分布式架构中资源管理的复杂度：

• 将 CPU、IO、网络等资源统一抽象为资源单位（RU），大幅简化对资源的定义
• 提供数据库用户、SQL 语句、后台任务等三个层面的资源隔离
• 在扩容或缩容时，资源调整可以秒级生效，无需迁移数据，提供了极致弹性能力

总的来说，Resource Control 是一种更灵活高效的资源管理方式，不仅能够实现多系统、多负载的隔离，还可以进行 SQL 语句和后台任务层面更精细化的控制。

数据库用户隔离

典型场景 - 小型系统整合

在我过去的经历中，我发现小型数据库系统普遍存在资源利用率较低的情况。实际上，我们在申请数据库资源时，往往基于直觉或者标准化配置来选择资源，背后可能并没有一个明确的依据。另外，多个系统通常负载峰值时间各不相同，在使用传统方案时也只能根据最大峰值+冗余的方式来申请资源，不可避免会出现较多资源闲置。

TiDB 的 Resource Control 方案，使得我们能够在较小的配置下实现更高效的资源利用率。将多个小型数据库系统整合到 TiDB 后，每个系统的资源分配可以根据其实际负载峰值、QPS 等需求进行精细化管理；如果在这些系统中存在一个消耗资源较高的系统，还可考虑分配单独的 TiDB 计算实例供其使用。

典型客户案例： TiDB 7.1 多租户在中泰证券中的应用

典型场景 - SaaS 场景

在以上第三种多租户架构中 ，多个租户共用一个库、同时共用一套表，表内通过分区来存储不同 SaaS 租户的数据，或直接使用单表（通过表内的 tenant_id 字段来区分 ），此时 TiDB Resource Control 可以轻松通过数据库用户来为不同租户进行资源控制。

而面对 SaaS 动辄数千个租户的需求，TiDB Resource Control 是极其有帮助的，无需划分 CPU/内存/节点数量，可创建数据库用户级别的资源组，轻松管理不同租户的资源需求和弹性需求：

示例：

• 假设租户 1 是体量非常大，可为其单独创建数据库用户 user1，并为该用户创建独立资源组，优先级高，且允许超用；

CREATE RESOURCE GROUP rg_tenant1 RU_PER_SEC = 1000000 PRIORITY = HIGH BURSTABLE;
alter user 'user1' RESOURCE GROUP rg_tenant1;

• 其他租户由于体量较小，共用一个资源池；

CREATE RESOURCE GROUP rg_tenant_default RU_PER_SEC = 500000 PRIORITY = MEDIUM;
alter user 'user_default' RESOURCE GROUP rg_tenant_default;

• 扩容。

ALTER RESOURCE GROUP rg_tenant_default RU_PER_SEC = 900000 PRIORITY = MEDIUM;

典型场景 - 系统内批量负载隔离

典型客户案例： MySQL 到 TiDB 迁移实践：云盛海宏零售业海量场景下 ToC 系统的选型思考与经验分享

在一个系统中往往会存在联机和批量两种负载，如联机的峰值在白天，到凌晨基本上是业务低峰期，此时可以安全的运行系统内的大型批量作业，进行大规模、高密度的读写，以尽快完成批量作业，进而不影响白天的联机业务。

但有些情况下，批量可能会跑到第二天业务高峰期，此时停止这个批量显然是不太合适的，但放任它继续消耗大量资源执行，显然也是不合适的。

在过去其实缺乏一些库内的管控手段的，只能在调度层、应用层进行有限控制。而 TiDB Resource Control 也可以轻松管理这种情况。

示例： 为批量作业单独创建用户，并绑定资源组：

CREATE USER 'USER_BATCH' IDENTIFIED BY '******';
CREATE RESOURCE GROUP rg_batch RU_PER_SEC = UNLIMITED PRIORITY = HIGH;
alter user 'USER_BATCH' RESOURCE GROUP rg_batch;-- 假设批量任务超时运行到第二天白天，只需执行如下 SQL 即可立即将其限速
ALTER RESOURCE GROUP rg_batch RU_PER_SEC = 100000 PRIORITY = LOW;

SQL 语句级别隔离

自 7.2 版本以来，TiDB Resource Control 引入了对 Runaway Queries（即执行时间或消耗资源超出预期的查询）的管理功能：

• QUERY_WATCH（手动处理）：对发现的 SQL 进行限流或熔断
• QUERY_LIMIT（自动处理）：当不符合预期的 SQL 出现时，数据库可自己识别、并自适应处理

典型场景 - SQL限流与熔断（QUERY_WATCH）

有一些 SQL 语句可能存在这种情况：编写不规范或需要查询大量数据（如抽数），它们在运行时可能会消耗大量的资源，我们希望它们跑慢一点没关系，但不要消耗太多资源影响正常业务请求。在 TiDB 中，可以轻松通过 Resource Control 来对它们进行限流：

-- 该 SQL 执行时，单独使用 rg1 资源组执行（rg1 是一个 100 RU 的资源）
SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t where is_delete=0 and create_time>='2023-01-01';-- 将 default 资源组中的这条 SQL 进行降低优先级，让其限速执行
QUERY WATCH ADD RESOURCE GROUP DEFAULT ACTION COOLDOWN SQL TEXT EXACT TO 'select * FROM t where is_delete=0 and create_time>='2023-01-01';

另外也可能存在一种情况，系统内突然出现一条之前从未运行过的大 SQL，它来历不明，我希望先直接将其熔断，不让其执行：

-- 根据 SQL DIGEST 维度进行拦截，并终止
QUERY WATCH ADD RESOURCE GROUP default ACTION KILL SQL DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57';-- 另外还可以使用 SQL TEXT 维度（可单独拦截某一特定条件值的 SQL）
-- 以及 PLAN DIGEST 维度（可拦截 SQL 中某一很差的计划出现）

典型场景 - 超出预期的查询自适应管理（QUERY_LIMIT）

基于 QUERY_WATCH 的限流和熔断方案，属于事中或事后的人工处理手段。从问题的出现、发现到最终解决，这一过程往往需要一定的时间；即便是经验丰富、对系统非常熟悉的管理员，在解决完问题时，往往已经过去了数分钟，甚至更长时间。这意味着，业务可能受的影响时间也会与之相关。

而 QUERY_LIMIT 则提供了更加灵活的自适应处理手段，让数据库可以自动发现异常并处理异常，我们只需要定义异常即可：

示例：

• 创建 rg_auto_cooldown 资源组，限额是 100000 RU，我们可以定义该资源组中执行时间超过 60 秒的查询为 Runaway Query，并让系统自动对 Runaway Query 进行降低优先级限流处理；

CREATE RESOURCE GROUP rg_auto_cooldown RU_PER_SEC = 100000 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN);

• 创 建 rg_over_10000 资源组，限额是 100000 RU，我们可以定义该资源组中每秒超过 10000 RU 的查询为 Runaway Query，并让系统自动对他们进行降低优先级限流处理；

CREATE RESOURCE GROUP rg_colldown RU_PER_SEC = 100000 QUERY_LIMIT=(RU=10000, ACTION=COOLDOWN);

• 还可以在当前资源组，将大型查询隔离到其他资源组执行：定义 default 资源组中处理数据行数超过 1000000 的查询为 Runaway Query，并让系统自动将他放到 rg_bigquery 资源组中执行，避免与当前资源组中的请求发生争用。

CREATE RESOURCE GROUP rg_bigquery RU_PER_SEC = 10000 PRIORITY = LOW;
-- 假设我当前资源组为 default
ALTER RESOURCE GROUP default QUERY_LIMIT=(PROCESSED_KEYS=1000000, ACTION=SWITCH_GROUP(rg_bigquery));

后台任务级别隔离

在日常运维过程中创建索引是一个常见的工作，虽然在 TiDB 中所有 DDL 均是在线的，但我们也不能忽视创建索引时资源消耗带来的风险。自 7.4 版本开始，TiDB Resource Control 引入了对后台任务的管理。

示例：

以创建索引这一 DDL 任务为例，可以设置 ddl 为后台任务，并且限制其最多可使用 TiKV 节点总资源的 30%。此时系统便会动态地限制该任务的资源使用，以尽量避免此类任务在执行时对其他前台任务的性能产生影响：

ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='ddl', UTILIZATION_LIMIT=30);

目前 TiDB 支持如下几种后台任务的类型：lightning、br、ddl、stats 等。

总结

通过本文的学习，相信大家对 TiDB 的资源隔离能力有了更全面的理解；大家可以根据不同的场景需求，选择合适的资源隔离方案。

如果您有新的资源隔离需求或场景，欢迎与我们联系。