MySQL 8.0资源组非CPU限流，而是通过VCPU亲和性绑定线程到指定CPU核心，并设置THREAD_PRIORITY调度优先级（-20至19），控制“在哪跑、谁先跑”，不控制CPU使用率。
资源组不是CPU限流，而是VCPU亲和性 + 调度优先级
MySQL 8.0 的 RESOURCE GROUP 并不能像 cgroups 那样限制 CPU 使用率（比如“最多用 30%”），它只做两件事：绑定线程到指定 VCPU（即 CPU 核心/超线程）+ 设置 THREAD_PRIORITY（影响内核调度顺序）。换句话说，它不控制“用了多少”，而控制“在哪跑、谁先跑”。很多用户配完发现 CPU 占用没降，就是因为误以为这是“限频”功能。
常见错误现象：SET RESOURCE GROUP slow_rg FOR 12345 执行成功，但 top 里该线程仍占满一个核 —— 这完全正常，因为 MySQL 没有做时间片削峰，只是把它钉在某个核上，且给了低优先级，让其他高优线程能抢走 CPU 时间。
- VCPU 参数填的是逻辑 CPU ID 列表（如
0、2-3、0,2,4），不是百分比或权重 -
THREAD_PRIORITY是 Linuxnice值映射，范围-20（最高）到19（最低）；USER 组只能设0–19，SYSTEM 组才允许负值 - 必须提前给
mysqld进程授予CAP_SYS_NICE能力，否则THREAD_PRIORITY不生效：setcap cap_sys_nice+ep /usr/sbin/mysqld
创建资源组前必须确认的三件事
不检查就建，大概率后续 SET RESOURCE GROUP 报错 3661（“Resource group not found or not enabled”）或线程无法分配。
- 确认 MySQL 版本 ≥ 8.0.17（资源组功能在此版本 GA），执行
SELECT VERSION(); - 确认操作系统支持：仅 Linux（glibc ≥ 2.12），Windows/macOS 不支持；运行
getcap /usr/sbin/mysqld看是否含cap_sys_nice - 确认当前实例未启用
--skip-grant-tables或处于只读模式，否则CREATE RESOURCE GROUP会拒绝
示例创建语句（绑定到 CPU 3，最低调度优先级）：CREATE RESOURCE GROUP slow_sql TYPE = USER VCPU = 3 THREAD_PRIORITY = 19 ENABLE;
如何把慢 SQL 线程动态绑到资源组
不能靠 SQL 文本匹配自动绑定，必须手动查出 THREAD_ID 后显式分配。适合应急压制已知长耗时线程，不适合全自动策略。
- 查活跃慢线程（例如执行超 10 秒的 DML/DDL）：
SELECT THREAD_ID, PROCESSLIST_USER, PROCESSLIST_HOST, PROCESSLIST_INFO, PROCESSLIST_TIME FROM performance_schema.threads WHERE PROCESSLIST_TIME > 10 AND PROCESSLIST_INFO IS NOT NULL; - 分配线程到资源组：
SET RESOURCE GROUP slow_sql FOR 12345;（其中12345是上一步查到的THREAD_ID） - 验证是否生效：
SELECT THREAD_ID, RESOURCE_GROUP FROM performance_schema.threads WHERE THREAD_ID = 12345;，返回值应为slow_sql
注意：SET RESOURCE GROUP ... FOR thread_id 只对正在运行的线程有效；新连接默认走 USR_default，需配合应用层连接池设置 init_connect 或使用代理层路由。
DISABLE 和 FORCE 的真实作用容易被误解
ALTER RESOURCE GROUP slow_sql DISABLE 不等于“停用”，它只是让该资源组进入不可分配状态；已绑在此组的线程仍继续运行，只是新 SET 请求会失败。真正要立即释放线程，得用 FORCE：
-
ALTER RESOURCE GROUP slow_sql DISABLE;→ 后续SET RESOURCE GROUP slow_sql FOR ...报错 3661 -
ALTER RESOURCE GROUP slow_sql DISABLE FORCE;→ 强制将所有已分配到该组的线程，立刻移回USR_default组 - 恢复启用：
ALTER RESOURCE GROUP slow_sql ENABLE;，但不会自动重绑历史线程
最关键的细节：资源组配置不写 binlog，不复制到从库；所有操作仅对本机 mysqld 实例生效。多节点集群需逐台执行，且 CPU 核数不一致时（比如主库 16 核、从库 8 核），VCPU = 2-3 在从库可能越界报错 —— 这点极易在线上灰度时漏测。
