MySQL 资源组怎样隔离报表查询的 CPU 使用

报表 SQL 和在线交易共用一个 MySQL 实例时，最难处理的通常不是“报表跑得慢”，而是它在扫描、排序和聚合期间占满 CPU，连带把下单、支付、库存更新等短事务拖慢。MySQL 8.4 的资源组可以把报表线程放进一个低优先级用户组，并限制它们只在指定虚拟 CPU 上运行。它不能给报表设置“最多使用 20% CPU”这类硬配额，但很适合做第一层调度隔离。

MySQL 8.4 官方文档：https://dev.mysql.com/doc/refman/8.4/en/resource-groups.html

我更倾向于把资源组理解为“给线程划分跑道”，而不是“给 SQL 限速”。VCPU 决定这组线程可以在哪些虚拟 CPU 上调度，THREAD_PRIORITY 决定用户线程的调度优先级。报表仍可能把自己的跑道跑满，所以索引优化、并发控制和只读副本仍然重要。

先判断资源组是否适合当前冲突

资源组最适合这样的场景：业务短查询延迟在报表运行时明显升高，实例 CPU 接近瓶颈，而报表连接能够被单独识别。比如 BI 平台有独立连接池、离线任务使用专门数据库账号，或者报表 SQL 可以统一加优化器提示。这样才能把报表流量稳定地送进同一个资源组。

如果瓶颈主要是磁盘吞吐、锁等待、临时表落盘或网络传输，仅调整 CPU 调度通常不会解决根因。资源组也不是所有环境都可用：MySQL 文档明确说明，线程池插件启用时不能使用资源组；macOS 不支持资源组；Linux 上若服务进程没有合适的 CAP_SYS_NICE 能力，线程优先级设置可能被忽略。上线前应先确认部署条件，而不是只看 SQL 能否执行。

创建一个低优先级报表资源组

假设数据库主机给在线业务保留 vCPU 0 到 5，把 vCPU 6 和 7 留给报表查询，可以创建一个用户资源组。下面的 CPU 编号只是示例，必须根据实际主机、容器配额和进程可见 CPU 调整。

-- 创建报表专用用户资源组，只允许使用指定虚拟 CPU，并降低调度优先级
CREATE RESOURCE GROUP reporting_low
  TYPE = USER
  VCPU = 6-7
  THREAD_PRIORITY = 10;

TYPE = USER 表示它管理普通用户线程。用户资源组的线程优先级范围是 0 到 19，数值越大，优先级越低，因此 10 是一个偏保守的起点。不要一开始就把优先级降到 19；先观察业务延迟是否改善，同时确认报表完成时间仍能接受。

创建和管理资源组通常需要 RESOURCE_GROUP_ADMIN 权限。仅把线程分配到已有资源组时，可以使用 RESOURCE_GROUP_ADMIN 或 RESOURCE_GROUP_USER。生产环境更适合把“创建资源组”和“报表账号使用资源组”拆开授权。

优先把报表连接池固定到资源组

最稳妥的做法是让报表连接建立后立即执行一次分配语句。这样连接池里的后续查询都继承同一归属，不需要在每条 SQL 里重复写提示。

-- 将当前报表会话放入低优先级资源组
SET RESOURCE GROUP reporting_low;

如果运维人员已经定位到某个正在运行的前台线程，也可以按线程 ID 分配：

-- 将指定 MySQL 线程放入报表资源组，12345 需替换为真实线程 ID
SET RESOURCE GROUP reporting_low FOR 12345;

第三种方式是只给一条语句指定资源组，适合无法拆分连接池、但能够改写报表 SQL 的系统：

-- 只让当前聚合查询使用报表资源组，不改变会话中其他语句的归属
SELECT /*+ RESOURCE_GROUP(reporting_low) */
       region, SUM(amount) AS total_amount
FROM sales_order
WHERE created_at >= '2026-10-01'
GROUP BY region;

三种方式里，我会优先选择独立连接池，其次是单条语句提示，最后才是人工按线程 ID 调整。线程 ID 会随连接重建而变化，适合临时处置，不适合作为长期自动化方案。

核对定义与线程归属

资源组创建成功不等于报表已经进入该组。至少要分别检查资源组定义和线程归属。前者来自 INFORMATION_SCHEMA.RESOURCE_GROUPS，后者来自 Performance Schema 的 threads 表。

-- 查看报表资源组是否启用，以及 CPU 范围和线程优先级
SELECT RESOURCE_GROUP_NAME,
       RESOURCE_GROUP_TYPE,
       RESOURCE_GROUP_ENABLED,
       VCPU_IDS,
       THREAD_PRIORITY
FROM INFORMATION_SCHEMA.RESOURCE_GROUPS
WHERE RESOURCE_GROUP_NAME = 'reporting_low';

-- 查看前台线程的连接 ID 与当前资源组，核对报表连接是否分配正确
SELECT THREAD_ID,
       PROCESSLIST_ID,
       RESOURCE_GROUP
FROM performance_schema.threads
WHERE TYPE = 'FOREGROUND';

观测时不要只看报表耗时，还要同时看在线业务的 P95 或 P99 延迟、CPU 使用、运行队列长度以及报表完成时间。资源组的目标是降低相互干扰，不一定让总 CPU 使用率下降。如果业务延迟改善、报表完成时间小幅增加，这通常是合理交换；如果报表积压严重，则需要调整 vCPU 范围或优先级。

高峰期可以继续收紧，但要保留回退

资源组参数可以在高峰期调整。例如只保留一个 vCPU，并把优先级降到最低：

-- 高峰期进一步收紧报表线程可用 CPU，并把用户线程优先级降到最低
ALTER RESOURCE GROUP reporting_low
  VCPU = 7
  THREAD_PRIORITY = 19;

如果调整后报表严重超时，应先把报表会话迁回默认用户资源组，再恢复或删除自定义资源组。MySQL 默认提供 USR_default 和 SYS_default；普通会话默认属于 USR_default。

-- 将当前会话迁回默认用户资源组，作为最小化回退操作
SET RESOURCE GROUP USR_default;

需要特别注意，资源组定义相关语句是服务器本地操作，不写入二进制日志，也不会自动复制到其他实例。因此主库、只读副本和灾备实例要分别配置，不能假设主库执行一次后其他节点会自动具备同名资源组。

资源组不能替代哪些方案

不能替代 SQL 与索引优化。 全表扫描、错误连接顺序和巨量排序仍会浪费 CPU，只是被限制在较小范围内运行。

不能替代只读副本。 当报表体量大、持续时间长，或者需要与交易业务彻底隔离时，把报表迁到只读副本通常更可靠。资源组更像同实例内的缓冲带。

不能替代并发治理。 十个低优先级报表同时启动，仍可能形成队列和内存压力。连接池最大并发、任务错峰和查询超时应一起设置。

不能提供 CPU 百分比硬上限。 VCPU 是 CPU 亲和范围，THREAD_PRIORITY 是调度优先级。它们不会保证报表只占固定百分比，也不会在所有操作系统上表现完全相同。

一个更稳妥的落地顺序

实际落地时，我会先从一个可识别的报表连接池开始，给它分配两个非核心 vCPU 和中等偏低优先级；在业务高峰运行同一批报表，比较业务尾延迟与报表完成时间；确认收益后，再逐步扩大到其他报表任务。若实例 CPU 已长期饱和，或者报表与交易在内存、磁盘方面也强烈竞争，则不再继续挤压资源组参数，而是转向只读副本或独立分析库。

一句话总结：MySQL 资源组能把报表线程放到更窄、优先级更低的 CPU 跑道上，减少它们与在线交易直接抢占调度机会；但要获得稳定结果，仍需配合清晰的连接池边界、性能观测、SQL 优化和可执行的回退方案。