MySQL 8.0 Resource Group不能限制CPU使用率，仅能绑定SELECT语句到指定逻辑核并调低调度优先级；CREATE必须指定TYPE=USER和真实VCPU范围，SET RESOURCE GROUP仅对下一条SELECT生效，DML语句完全绕过。
MySQL 8.0 的 Resource Group 不能“限制慢查询的 CPU 使用率”，只能把它钉到特定逻辑核上并调低调度优先级；它不会中断、降频或削峰，更不适用于 INSERT/UPDATE/DELETE。
CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才生效
漏掉 TYPE=USER 或 VCPU，语句能执行成功，但查 INFORMATION_SCHEMA.RESOURCE_GROUPS 会发现 VCPU_IDS 是 NULL 或 0-0，绑定后毫无效果。
-
TYPE只能是USER（用户线程）或SYSTEM（内部线程），普通用户只能用USER -
VCPU必须填服务器真实存在的逻辑 CPU ID，比如 8 核机器 ID 范围是0-7；写VCPU=4-7有效，写VCPU="0-3"（带引号）或VCPU=8-15会静默失败或报错 - 支持格式：单核
0、连续范围2-5、离散列表0,2,4；不能混用，也不能留空 - 务必预留至少 1–2 个核给
SYS_default，否则mysqld自身 purge 线程或元数据锁可能卡死
SET RESOURCE GROUP 只影响下一条 SELECT
执行 SET RESOURCE GROUP rg_low FOR 12345 后，线程 12345 正在跑的那条慢 SELECT 不会暂停、迁移或降优先级——它继续在原 CPU 上跑完。只有下一条新发起的 SELECT 才受约束。
- 查线程 ID 必须用
performance_schema.threads.THREAD_ID，不是PROCESSLIST_ID - 目标线程状态不能是
Sleep，否则报错ERROR 3661 (HY000) - 若想让限制“看起来立即生效”，得先
KILL QUERY 12345，再让应用重试，并确保重试连接已绑定资源组 - 连接池场景下
THREAD_ID频繁变化，临时SET容易绑错，建议优先用ALTER USER 'u'@'%' RESOURCE GROUP rg_low做用户级绑定
为什么你的慢查询还是打满 CPU？
Resource Group 不是 cgroups，它不做时间片控制，也不限制 CPU 百分比。你看到某个线程持续占满一个核，这完全正常——它只是被固定在那个核上跑了，没被“压低使用率”。
- 只对
SELECT生效：INSERT/UPDATE/DELETE/ALTER TABLE全部绕过，哪怕线程已绑定，照样全速跑 - 真正能中断慢
SELECT的只有max_execution_time：会话级设SET SESSION max_execution_time = 3000，或语句级加提示SELECT /*+ MAX_EXECUTION_TIME(2000) */ ... - Linux 下需给
mysqld进程加CAP_SYS_NICE权限：setcap cap_sys_nice+ep /usr/sbin/mysqld，否则THREAD_PRIORITY设了也白设 - 如果负载以写操作为主（如 ETL、日志归档），Resource Group 对这部分 CPU 占用完全无效，得靠
MAX_UPDATES_PER_HOUR或外部 cgroups 控制
最容易被忽略的一点：Resource Group 不是“限 CPU”，而是“挑 CPU + 排队顺序”。想靠它防住高成本写操作或压住整体 CPU 使用率，方向就错了。该用 max_execution_time 拦 SELECT，该用 cgroups 或代理层控写入，别把 Resource Group 当万能开关。
