mysql 8.0资源组（resource groups）专为隔离多租户/混合负载下的cpu争用而设计，通过vcpu绑定和线程优先级调控实现关键事务与低优先级sql（如报表、etl）的调度隔离，不分配资源池，不干预内存、io、查询计划。
Resource Group 不是为“分配 CPU”而设计的通用资源调度器，而是为解决一个具体且高频的生产痛点：多租户或混合负载下，低优先级 SQL（如报表、ETL）抢占 CPU 导致关键事务响应抖动甚至超时。
MySQL 是单进程多线程模型，所有用户线程共享同一进程的调度权重。8.0 之前，DBA 没法让一条 SELECT COUNT(*) FROM sales_2024 GROUP BY region 主动让出 CPU 给正在执行的支付事务——只能靠 kill、限流中间件，或硬等业务低峰期。这在主库跑批、实时分析与 OLTP 共存的场景里特别脆弱。
Resource Group 的引入，本质是把 Linux cgroups v1 的 cpuset 和 cpu 子系统能力，以 SQL 接口暴露给 DBA，只做一件事：绑定线程到指定逻辑 CPU 并调整其 CFS 调度优先级。它不碰内存、IO、锁、网络，也不改查询计划——这点必须明确，否则后续所有配置都会走偏。
CREATE RESOURCE GROUP 的真实作用不是“分配”，而是“隔离”
- 它创建的不是资源池，而是一个带亲和性（
VCPU）和优先级（THREAD_PRIORITY）的线程调度策略模板 -
VCPU=2-3表示“只允许在这个范围内的逻辑核上运行”，不是“最多用 2 个核”；若机器只有 2 核却设VCPU=4-7，组会静默失效（查performance_schema.resource_groups中ACTIVE_THREADS始终为 0） -
THREAD_PRIORITY影响的是 CFS 的vruntime计算，-20 到 19，负值越高越优先（注意：不是 nice 值，不能直接用 top 看）
SET RESOURCE GROUP 生效的前提非常苛刻
- 必须由有
RESOURCE_GROUP_ADMIN权限的用户执行（GRANT RESOURCE_GROUP_ADMIN ON <em>.</em> TO 'user'@'%'） - MySQL 启动参数必须含
resource_group_enabled=ON，且performance_schema.setup_actors中对应行的RESOURCE_GROUP列为ENABLED - 仅对后续新发起的语句生效，已执行中的语句、预编译缓存里的语句、连接池复用的连接，都不受控
- 不支持 DDL（
CREATE TABLE）、管理命令（SHOW PROCESSLIST）、存储过程内嵌语句（除非显式在过程中SET）
容易被忽略的三个现实约束
- 它无法限制“慢”，只能限制“快不起来”：一条没索引的全表扫描，在低优先级组里依然会扫完，只是更慢、更不影响别人
- VCPU 绑定可能适得其反：4 核机器上把所有后台任务绑到
VCPU=0-1，反而造成这两个核争抢严重，而 2、3 核空闲——应先用top -H -p $(pgrep mysqld)观察线程实际分布再配 - 它不是替代
max_execution_time或innodb_buffer_pool_size的方案：想杀长查询，用前者；想防内存爆满，调后者；Resource Group只管 CPU 时间片怎么切
真正起效的关键，从来不是建几个组，而是清楚知道：哪类 SQL 需要降权、它们在线程堆栈里真实跑在哪几个核上、以及应用层能否保证每次执行前都重置 SET RESOURCE GROUP。
