MySQL 8.0资源组不提供CPU使用率百分比限制，仅通过VCPU绑定和THREAD_PRIORITY向内核透传调度优先级，由操作系统决定线程获得CPU时间的概率，非MySQL内核限流。
Resource Groups 的 THREAD_PRIORITY 不是 MySQL 自己调度的“权重”
MySQL 8.0 的资源组不干预线程执行逻辑，也不做时间片切分或 CPU 使用率限流。它只是把 THREAD_PRIORITY 值透传给操作系统（Linux 的 sched_setparam），由内核调度器决定线程获得 CPU 时间的概率。所谓“分配更多资源”，本质是让高优先级线程在竞争时更大概率被选中运行，尤其在 CPU 饱和时效果明显。
常见误解是以为设了 THREAD_PRIORITY = -10 就能抢到 70% 的 CPU——实际没有这种保障，它只影响调度顺序，不保证带宽。
- 用户线程的
THREAD_PRIORITY合法范围是0到19（数字越小，优先级越高）；设-10会报错ER_RESOURCE_GROUP_NO_ACCESS - 系统线程（如
io_thread）可用-20到0，但普通 DBA 无法修改它们的资源组归属 - 优先级差值要够大：比如核心业务用
0，跑批任务用15，差 15 级才能在负载高时观察到响应延迟差异
VCPU 绑定不是硬隔离，但能降低跨核调度开销
设置 VCPU = 0-1 并不等于“锁死在这两个核上”，它只是建议内核将线程尽量调度到这些逻辑 CPU 上。如果 0-1 全忙而 2-3 空闲，线程仍可能被迁移到其他核——这取决于内核的 sched_migration_cost 和当前负载策略。
但它确实有实际价值：
- 减少 cache line bouncing：线程固定在少数核上，L3 cache 局部性更好，对 OLTP 类短查询延迟更友好
- 避免与系统线程争抢：例如把报表任务绑定到物理上远离主库 IO 线程的核（如超线程配对中的次核），可降低干扰
- 混用 VCPU（如所有资源组都设
0-3）基本无效；必须错开，比如oltp_group用0-1，batch_group用2-3
必须显式绑定线程才生效，用户级绑定 vs 运行时绑定
建好资源组后，线程默认仍在 USR_default 里，不会自动归入新组。必须通过以下两种方式之一指定：
- 用户级绑定：
ALTER USER 'app_user'@'%' RESOURCE GROUP = oltp_high_priority，新连接自动归属，适合长期稳定业务 - 运行时绑定：
SET RESOURCE GROUP oltp_high_priority FOR 12345，其中12345是performance_schema.threads.THREAD_ID（不是PROCESSLIST_ID），适合临时干预慢查询 - 执行者需有
RESOURCE_GROUP_USER权限；目标线程不能是SYSTEM类型（如purge_thread） - 切换后不影响当前正在执行的语句，只对后续新语句生效；想立即生效得
KILL后重连
容易忽略的权限与启动限制
即使语法全对，THREAD_PRIORITY 也可能静默失效：
- MySQL 必须以
root或具备CAP_SYS_NICE能力的用户启动，否则内核拒绝提升优先级，只记录 warning - 非 super 用户创建的资源组，
THREAD_PRIORITY只能设为0到19；设0实际等于没调，因为USR_default默认就是0 -
INFORMATION_SCHEMA.RESOURCE_GROUPS中的RESOURCE_GROUP_ENABLED = 0表示该组被禁用，SET RESOURCE GROUP会失败，需先ALTER RESOURCE GROUP ... ENABLE
真正起作用的从来不是单个参数，而是 VCPU 错开 + THREAD_PRIORITY 拉开差距 + 连接/线程显式归属 —— 少一个环节，就只是看起来配置了。
