create resource group 必须同时指定 type 和 vcpu 才生效，否则 vcpu_ids 为 null 或 0-0；type 必须为 user（用户线程）或 system（系统线程），vcpu 需填真实逻辑 cpu id，且仅对 select 语句生效。
CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才真正生效，否则查 INFORMATION_SCHEMA.RESOURCE_GROUPS 会看到 VCPU_IDS 是 NULL 或 0-0，绑了也白绑。
CREATE RESOURCE GROUP 语句必须显式指定 TYPE 和 VCPU
漏掉任一参数，资源组就只是个空壳。MySQL 8.0 不会报错，但后续 SET RESOURCE GROUP FOR thread_id 完全无效。
-
TYPE = USER是强制项，用户线程只能用USER类型；SYSTEM类型仅供 MySQL 内部线程（如io_thread），你无法绑定 -
VCPU必须填服务器真实存在的逻辑 CPU ID，比如 8 线程机器 ID 是0–7，写VCPU = 4-7有效，写VCPU = 8-15或"0-3"（带引号）直接失败或静默失效 - 支持三种格式：
0（单核）、2-5（连续）、0,2,4（离散），不能混用，也不能留空 - 务必预留至少 1–2 个核给系统线程（如
SYS_default），否则 MySQL 自身可能卡死在 metadata lock 或 purge 上
SET RESOURCE GROUP FOR thread_id 只影响后续查询
执行 SET RESOURCE GROUP slow_rg FOR 12345 后，线程 ID 12345 正在跑的那条慢 SELECT 不会暂停、不会迁移、也不会降优先级——它继续在原 CPU 上跑完。只有下一条语句才受新资源组约束。
- 查线程 ID 要用
performance_schema.threads.THREAD_ID，不是PROCESSLIST_ID；且需确保performance_schema已启用（默认关闭） - 目标线程状态不能是
Sleep，否则报错ERROR 3661 (HY000)；也不能处于Waiting for table metadata lock等不可中断状态 - 若想立即生效，必须先
KILL QUERY 12345，再让应用重试，并确保重试连接已绑定资源组（比如通过ALTER USER ... RESOURCE GROUP） - 连接池复用连接时，
THREAD_ID频繁变化，临时SET很容易绑错会话，建议优先用用户级绑定而非运行时绑定
资源组只对 SELECT 生效，INSERT/UPDATE/DELETE 完全无视
这是硬限制，文档没明说但实测如此：哪怕你把 UPDATE 语句所在的线程绑到低优先级资源组，它仍会在所有 CPU 上自由调度，CPU 占用不受控。MySQL 8.0 的资源组仅作用于优化器选中的 SELECT 查询路径。
- 写操作类语句（
INSERT、UPDATE、DELETE、ALTER TABLE）完全绕过资源组调度逻辑 - 存储过程、触发器、事件中无法动态调用
SET RESOURCE GROUP，只能由客户端或 DBA 在会话层主动干预 - 验证是否生效，只测
SELECT SLEEP(10)这类纯读语句，别拿UPDATE WHERE去试 - 如果负载以写为主，资源组基本无效；此时应转向
MAX_UPDATES_PER_HOUR或外部cgroups
THREAD_PRIORITY 在 Linux 上需 CAP_SYS_NICE 才真正生效
THREAD_PRIORITY 是 Linux nice 值映射，范围 -20（最高）到 19（最低）。但普通用户线程只能设 0–19，且必须提前给 mysqld 进程授予权限：
- 执行
setcap cap_sys_nice+ep /usr/sbin/mysqld，再用getcap /usr/sbin/mysqld确认是否含cap_sys_nice - 没开能力时设了
THREAD_PRIORITY也等于没设 - 用户资源组允许的优先级范围是
0–19，填-5会直接报错ER_RESOURCE_GROUP_NO_ACCESS - 优先级差异只有在多线程争抢同一组
VCPU时才明显；如果VCPU隔离彻底（比如 OLTP 用0-1，报表用2-3），优先级影响反而变小
VCPU 绑定 + THREAD_PRIORITY 组合策略，而不是“限制 CPU 使用率”。很多管理员配完发现 top 里线程仍占满一个核，是因为资源组不削时间片，只做亲和性与调度提示——它控制“在哪跑、谁先跑”，不控制“跑多快”。
