MySQL 8.0资源组仅对SELECT生效，必须显式指定TYPE=USER和真实VCPU范围才具备CPU亲和性与优先级调度能力；漏填任一参数则无隔离效果，DML语句完全绕过。
CREATE RESOURCE GROUP 必须带 TYPE = USER 和真实 VCPU 才真正生效，否则查 INFORMATION_SCHEMA.RESOURCE_GROUPS 会发现 VCPU_IDS 是 NULL 或 0-0，绑了也白绑。
CREATE RESOURCE GROUP 语句必须指定 TYPE 和 VCPU
漏掉 TYPE 或 VCPU，语句能执行成功，但资源组不具备任何 CPU 隔离能力。常见错误写法：CREATE RESOURCE GROUP rg1;（缺参数）、CREATE RESOURCE GROUP rg1 TYPE = USER;（没给 VCPU）、CREATE RESOURCE GROUP rg1 VCPU = "0-3";（引号导致静默失败）。
VCPU 必须填服务器真实存在的逻辑 CPU ID，例如 8 核机器 ID 范围是 0–7：
-
VCPU = 0、VCPU = 2-5、VCPU = 0,2,4都合法 -
VCPU = 8-15越界，报错或失效 -
VCPU = ""或留空，VCPU_IDS显示为NULL - 务必预留至少 1–2 个核给
SYS_default，否则 purge 线程或 metadata lock 可能卡死 mysqld
SET RESOURCE GROUP FOR thread_id 只影响后续查询
执行 SET RESOURCE GROUP slow_rg FOR 12345 后，线程 ID 12345 正在运行的那条慢 SQL 不会暂停、迁移或降优先级——它继续在原 CPU 上跑完。只有下一条语句才受新资源组约束。
想让限制“立即”生效，得走两步：
- 先
KILL QUERY 12345中断当前执行 - 再让应用重连，并确保连接后立刻执行
SET RESOURCE GROUP slow_rg（或通过ALTER USER ... RESOURCE GROUP持久绑定）
注意：thread_id 是 performance_schema.threads.THREAD_ID，不是 PROCESSLIST_ID；且该线程状态不能是 Sleep，否则报错 ERROR 3661 (HY000)。
资源组只对 SELECT 生效，INSERT/UPDATE/DELETE 完全绕过
这是硬限制，不是配置问题。哪怕你把一个正在执行 UPDATE 的线程显式绑到低优先级资源组，它仍会在所有 CPU 上自由调度，CPU 占用不受控。
MySQL 8.0 的资源组仅作用于优化器选中的 SELECT 查询路径。验证是否生效，只能测纯读语句，比如：
SELECT SLEEP(10);
别拿 UPDATE t SET x=1 WHERE y=2; 去试——它永远不走资源组调度逻辑。
THREAD_PRIORITY 在 Linux 上需 CAP_SYS_NICE 权限才实际生效
THREAD_PRIORITY 是映射到 Linux nice 值的调度优先级（范围 0–19），但普通用户线程无法直接影响内核调度，除非 mysqld 进程被授予 CAP_SYS_NICE 能力：
- 执行：
setcap cap_sys_nice+ep /usr/sbin/mysqld - 验证：
getcap /usr/sbin/mysqld应输出/usr/sbin/mysqld = cap_sys_nice+ep - 没加能力时设
THREAD_PRIORITY = 19，等于没设
另外，USER 类型资源组只允许 0–19，填 -5 会直接报错；而 SYSTEM 组才支持负值，但用户线程根本绑不上。
VCPU 绑定 + THREAD_PRIORITY 组合带来的调度错峰，不是“限制 CPU 使用率”。如果负载以写为主，或你的 MySQL 运行在 Windows/macOS/phpEnv 等不支持环境里，资源组基本无效。 
