MySQL 8.0资源组仅限SELECT查询的CPU亲和性绑定与优先级调度，不支持CPU使用率限制；必须显式指定TYPE=USER和真实VCPU范围才有效，且对DML语句完全无效。
MySQL 8.0 的资源组（Resource Groups）不能“限CPU使用率”，只能做 CPU 亲和性绑定 + 调度优先级干预；不显式指定 TYPE 和 VCPU 的 CREATE RESOURCE GROUP 语句，创建成功但完全无效。
CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才算真正可用
漏掉任一关键参数，INFORMATION_SCHEMA.RESOURCE_GROUPS 里 VCPU 字段会是 NULL 或 0-0，这种组绑给线程后，CPU 隔离为零——查询照样跑满所有核。
-
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 batch_low_priority FOR 12345 后，线程 ID 12345 正在跑的那条慢 SQL 不会暂停、不会迁移、也不会降优先级——它继续在原 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 在会话层主动干预 - 如果业务中有大量写入型“烂 SQL”，光靠资源组无解，得配合
max_execution_time、连接级内存限制（connection_memory_limit）或外部 kill 脚本
THREAD_PRIORITY 对 CPU 占用率影响极小，别当“限速开关”用
THREAD_PRIORITY 不是 CPU 使用率上限，只是向操作系统传递调度偏好。设成 19 并不等于“最多用 5% CPU”，而是在争抢同一组 VCPU 时，大概率被排在后面——前提是真有多个线程在抢。
- 用户线程允许范围是
0–19（0最高，19最低），填-5直接报错ER_RESOURCE_GROUP_NO_ACCESS - 如果资源组已独占一组物理核（如
VCPU = 3），且无其他线程共用该核，THREAD_PRIORITY几乎没效果 - 要观察到明显差异，得让高低优先级组共享同一组
VCPU（如都设0-1），再拉高并发压测，否则看不出延迟变化 - Linux 下需 root 权限 +
CAP_SYS_NICE能力才真正生效；普通账号即使设了也等于白设
真正起隔离作用的是 VCPU 绑定的物理核划分，不是优先级数字；而一旦写操作占满 CPU，资源组就彻底失能——这点在设计报表账号或后台任务隔离策略时，最容易被忽略。
