mysql 8.0资源组不能限制cpu使用率，仅支持vcpu绑定和thread_priority调度；必须显式指定type=user与真实vcpu范围才生效，且仅对select有效，dml完全绕过。
MySQL 8.0 的资源组不能限制 CPU 使用率，只能做 VCPU 绑定和调度优先级控制；试图靠它“压住百分比占用”会失败。
CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才真正生效
漏掉 TYPE = USER 或 VCPU 参数，语句能执行成功，但查 INFORMATION_SCHEMA.RESOURCE_GROUPS 会发现 VCPU_IDS 是 NULL 或 0-0，这种资源组绑给线程后毫无隔离效果。
-
TYPE只能是USER（用户线程）或SYSTEM（MySQL 内部线程），普通用户只能用USER -
VCPU必须填服务器真实存在的逻辑 CPU ID，例如 8 核机器是0-7；支持格式：3（单核）、2-5（连续）、0,2,4（离散），不能加引号、不能写-1或留空 - 务必预留至少 1–2 个核给
SYS_default等系统线程，否则mysqld可能卡死在 metadata lock 或 purge 上
SET RESOURCE GROUP 只影响下一条 SELECT，不中断当前执行
这是最常被误用的点：执行 SET RESOURCE GROUP slow_sql FOR 12345 后，线程 ID 12345 正在跑的那条慢 SQL 不会暂停、迁移或降速——它继续在原 CPU 上跑完。只有下一条语句才受新资源组约束。
- 想让限制“立即生效”，必须先
KILL QUERY 12345，再让应用重连，并确保连接后立刻执行SET RESOURCE GROUP - 查线程 ID 要用
performance_schema.threads.THREAD_ID，不是PROCESSLIST_ID；且需确认performance_schema已启用（默认关闭） - 目标线程状态不能是
Sleep，也不能处于Waiting for table metadata lock等不可中断状态，否则报错ERROR 3661 (HY000)
资源组只对 SELECT 生效，INSERT/UPDATE/DELETE 完全无效
这是硬限制，不是配置错误：哪怕你把 UPDATE 所在线程绑到最低优先级资源组，它仍会在所有 CPU 上自由调度，CPU 占用不受控。MySQL 8.0 的资源组仅作用于优化器选中的 SELECT 查询路径。
- 存储过程、触发器、事件中无法动态调用
SET RESOURCE GROUP，只能由客户端或 DBA 在会话层主动干预 - 连接池复用连接时，
THREAD_ID频繁变化，临时SET很容易绑错会话；建议优先用用户级绑定：ALTER USER 'report_user'@'%' RESOURCE GROUP = batch_low_priority -
THREAD_PRIORITY在 Linux 上需mysqld进程有CAP_SYS_NICE能力（setcap cap_sys_nice+ep /usr/sbin/mysqld），否则设了等于白设
真正需要压制 CPU 占用率，别只盯资源组——它不提供时间片配额，也不做削峰。写操作完全绕过，SELECT 的“限速”也依赖 OS 调度器响应，实际效果浮动很大。生产中更可靠的做法是组合 MAX_QUERIES_PER_HOUR + 外部 cgroups + 应用层查询超时控制。
