MySQL 8.4 RESOURCE GROUP 如何限制后台查询：线程优先级与会话绑定

夜间报表和在线查询共用一台 MySQL 服务器时，最容易出现的不是 SQL 写错，而是后台会话把 CPU 争满，前台请求只能排队。MySQL 8.4 的 RESOURCE GROUP 可以把这类批处理会话放进单独的用户资源组，用 VCPU 范围和 THREAD_PRIORITY 表达“后台让路”的意图，再用 Performance Schema 或 INFORMATION_SCHEMA 核对绑定结果。

RESOURCE GROUP 适合做数据库服务器内的 CPU 资源边界，不是查询限时器，也不会替代索引、连接池和批任务拆分。

后台查询为什么需要独立的 CPU 边界

先把问题限定清楚：RESOURCE GROUP 管的是 MySQL 服务器线程的 CPU 归属和优先级，典型对象是可延后的报表、批量清理或离线汇总。它不改变 InnoDB 锁等待，也不会替一个缺索引的查询减少扫描行数。

没有资源组时，后台连接通常和在线请求一起落在默认用户组。此时 DBA 只能靠错峰、限并发或应用层排队缓解争用；这些办法仍然有价值，但没有把“哪些线程可以让路”写进数据库的管理面。

先创建 Batch 资源组，再绑定后台会话

下面的例子假设服务器至少有 4 个可用虚拟 CPU，并且账号具有 RESOURCE_GROUP_ADMIN 权限。用户资源组使用 0 到 19 的线程优先级，示例把后台组放在较低优先级一侧。

CREATE RESOURCE GROUP Batch
  TYPE = USER
  VCPU = 2-3
  THREAD_PRIORITY = 10;

这里的 Batch 是组名，VCPU = 2-3 是 CPU 亲和范围，THREAD_PRIORITY = 10 是用户线程优先级。组创建后并不会自动接管所有后台连接，仍要显式绑定线程或会话。

SET RESOURCE GROUP 的两种绑定方式

后台任务连接建立后，最小写法是让当前会话（current session）加入 Batch：

SET RESOURCE GROUP Batch;

不带 FOR 时，语句只作用于当前会话线程。如果 DBA 已经从 Performance Schema 的 threads 表拿到线程 ID，也可以指定多个线程：

SET RESOURCE GROUP Batch FOR 14, 78, 4;

第二种写法适合处理已经运行的后台连接，但要确认线程 ID 没有过期，且不要把系统线程误放进用户资源组。给单条语句分配资源组还可以使用 RESOURCE_GROUP 优化器提示，边界比改变整个会话更窄。

用 RESOURCE_GROUPS 和 threads 做结果核对

创建或修改后，先确认资源组定义：

SELECT RESOURCE_GROUP_NAME,
       RESOURCE_GROUP_TYPE,
       RESOURCE_GROUP_ENABLED,
       VCPU_IDS,
       THREAD_PRIORITY
FROM INFORMATION_SCHEMA.RESOURCE_GROUPS
WHERE RESOURCE_GROUP_NAME = 'Batch';

结果应能看到 Batch、USER、启用状态、VCPU_IDS 和 THREAD_PRIORITY。若要确认某个线程的归属，可以查看 Performance Schema：

SELECT THREAD_ID, PROCESSLIST_ID, RESOURCE_GROUP
FROM performance_schema.threads
WHERE PROCESSLIST_ID = CONNECTION_ID();

这一步只证明线程当前的资源组标签，不代表查询已经变快。应把它和 CPU 使用率、前台请求延迟、后台任务完成时间一起观察。

修改、停用与回滚的边界

业务高峰到来时，可以降低 Batch 的优先级或收紧 CPU 范围：

ALTER RESOURCE GROUP Batch
  VCPU = 3
  THREAD_PRIORITY = 19;

需要停用组时，DISABLE 不带 FORCE 会让已有线程继续运行，但不再允许新线程加入；DISABLE FORCE 会把现有线程移回各自默认组。确认组中没有需要保留的线程后，再考虑：

DROP RESOURCE GROUP Batch;

资源组管理是本机行为，不写入二进制日志，也不随复制链路传播。主库和副本若都需要同样的边界，应分别配置并分别核验。

平台限制别被 THREAD_PRIORITY 误导

资源组并不是所有部署形态都等价。线程池插件安装后资源组不可用；macOS 不支持资源组；FreeBSD 和 Solaris 会忽略线程优先级。Linux 上还要关注 CAP_SYS_NICE，没有对应能力时，线程优先级可能保持默认值。先看 RESOURCE_GROUPS.THREAD_PRIORITY 和告警，再判断配置是否生效。

另外，资源组需要管理权限。把 RESOURCE_GROUP_ADMIN 直接授予普通业务账号，会扩大它修改其他线程资源边界的能力；更稳妥的做法是由受控运维账号执行组管理，应用账号只负责在自己的连接中使用已经批准的组。

常见问题

RESOURCE GROUP 能解决慢查询吗？

它只能缓解 CPU 争用，不能修复全表扫描、锁等待或网络传输问题。先用执行计划和 Performance Schema 找出真正瓶颈。

SET RESOURCE GROUP Batch 会影响所有连接吗？

不会。不带 FOR 时只影响执行语句的当前会话线程；批量指定线程时也只影响列出的线程。

为什么 THREAD_PRIORITY 改了但效果不明显？

先核对平台限制、线程池插件和 Linux 的 CAP_SYS_NICE，再看 VCPU_IDS、前台负载与后台并发。优先级不是绝对的 CPU 配额。

资源组配置会复制到副本吗？

不会。资源组管理在本机生效，相关语句不写入二进制日志，需要在每台服务器分别配置。

把资源组当作最后一道边界

一个可维护的落地顺序是：先降低批处理并发，再确认 SQL 和索引，再为剩余 CPU 争用建立 Batch 资源组，最后用 RESOURCE_GROUPS 与 threads 的结果核对。只要保留 DISABLE FORCE 的回退路径，并把主库、副本和平台差异写进运维记录，这项能力才不会变成一条无人能解释的配置。