MySQL 资源组怎么限流：从 RESOURCE_GROUP 到单条 SQL 的 CPU 边界

夜间报表和在线接口共用一台 MySQL 时，最难受的不是报表偶尔变慢，而是它把 CPU 长时间吃满，连正常的订单查询也被拖住。MySQL 资源组提供了一层清晰的治理边界：可以把线程放进指定 CPU 资源组，也可以只给某一条语句加 RESOURCE_GROUP 优化器提示，让重任务先在受控范围内运行。

资源组适合做 CPU 争用隔离，不是 SQL 并发数限制器；上线前先确认线程类型、CPU 范围和权限，再用单条语句验证，最后保留恢复默认资源组的回滚命令。

先判断资源组解决的是哪一种争用

资源组针对的是线程获得 CPU 时间的优先级与可用 CPU 范围。它比较适合报表、数据修复、批量导入这类可延后任务；如果瓶颈在锁等待、磁盘吞吐、连接数或临时表空间，单纯创建资源组不会自动修复根因。

创建一个可回滚的 CPU 资源组

下面的示例把报表线程放到两个 CPU 上，并设置较低的优先级。CPU 编号必须以目标实例实际可用的范围为准，生产环境不要直接照抄。

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

SELECT RESOURCE_GROUP_NAME, RESOURCE_GROUP_TYPE,
       VCPU_START, VCPU_END, THREAD_PRIORITY
FROM INFORMATION_SCHEMA.RESOURCE_GROUPS
WHERE RESOURCE_GROUP_NAME = 'report_batch';

普通用户线程使用 TYPE = USER；系统线程资源组与用户线程不是同一个边界。创建成功后先查 INFORMATION_SCHEMA.RESOURCE_GROUPS，确认名称、CPU 起止编号和优先级都符合预期，再绑定真实业务线程。

先用单条 SQL 验证提示是否生效

如果只是想观察一条报表 SQL，不必先改变连接线程的长期归属。可以在语句上加资源组提示：

SELECT /*+ RESOURCE_GROUP(report_batch) */
       customer_id, SUM(amount) AS total_amount
FROM order_archive
WHERE created_at >= '2026-08-01'
GROUP BY customer_id;

这条提示只对当前语句生效。它适合做灰度验证：观察 CPU、耗时和在线请求延迟是否变化，再决定是否把报表连接长期切到资源组。提示拼写错误、资源组不存在或账号没有使用权限时，应把错误当作发布门禁，而不是静默忽略。

需要长期隔离时再绑定线程

在已经确认资源组边界合理后，可以把当前线程切换到该组：

SET RESOURCE GROUP report_batch;

SELECT THREAD_ID, NAME, TYPE, RESOURCE_GROUP
FROM performance_schema.threads
WHERE THREAD_ID = PS_CURRENT_THREAD_ID();

这里要注意线程范围：命令影响的是当前会话，不会自动把连接池里其他连接一起迁移。应用侧如果要长期使用，应在报表连接建立后执行一次，并在连接回收、重连和故障恢复路径中再次确认。

权限、监控与回滚要一起设计

资源组相关操作需要专门权限。管理员可以创建、修改和删除资源组；普通用户是否能把自己的线程或语句放入某个组，要按实例版本和授权结果实测。不要为了让示例跑通而给业务账号永久授予最高权限。

回滚先恢复当前线程的默认组，再删除自定义组：

SET RESOURCE GROUP SYS_default;
DROP RESOURCE GROUP report_batch;

回滚前要确认没有仍在运行的报表任务依赖该组，并保存 CPU 使用率、平均查询耗时、P95 延迟和错误数。资源组只改变调度边界，不能让一个扫描数十亿行的查询变成好查询。

常见问题

资源组能限制 SQL 同时运行的数量吗？

不能。它主要处理 CPU 资源与线程优先级，连接数和并发数仍应由连接池、队列或应用限流控制。

给一条 SQL 加提示后会永久绑定连接吗？

不会。语句级提示只影响带有该提示的语句；需要长期隔离时才考虑切换当前线程。

资源组 CPU 编号可以随便写吗？

不可以。应以目标实例可用 CPU 范围和部署环境为准，先查询资源组状态，再在低风险任务上验证。

删除资源组前为什么要先回滚？

仍绑定该组的线程或语句可能失败。先把线程恢复到默认组，再确认没有依赖关系，回滚路径才完整。

把资源组当成隔离阀，而不是性能魔法

资源组的价值是给 CPU 争用提供一个可观察、可撤回的隔离阀：先用单条语句验证，再决定是否绑定报表线程，同时把权限、连接池和监控纳入同一张变更单。真正上线前，还要用实际负载证明在线请求没有被牺牲，才值得保留这条治理规则。