MySQL 8.0 的 RESOURCE GROUP 仅支持 VCPU 绑定和线程优先级调度，无法限制 CPU 使用率百分比；不控制写操作、备份、存储过程等，且 SET RESOURCE GROUP 仅对下一条 SELECT 生效。
Resource Group 不是 CPU 限频器，只做亲和性+优先级调度
MySQL 8.0 的 RESOURCE GROUP 不能限制 CPU 使用率百分比（比如“最多用 30%”），它不提供时间片配额、不削峰、不压频。真正起作用的只有两件事：VCPU 绑定（决定线程能在哪些逻辑核上运行）和 THREAD_PRIORITY（影响 Linux 内核调度器对线程的响应顺序）。你配完看到慢查询仍占满一个核，完全正常——这不是失效，而是设计如此。
常见误判场景：
- 用
top -H看 mysqld 进程下某个线程 CPU 占用 95%，就以为资源组没生效 —— 实际它可能已成功绑到指定 VCPU，只是该核上没其他高优竞争者 - 期望通过资源组把批量
UPDATE的 CPU 压下来 —— 但这类写操作完全绕过资源组调度，查performance_schema.threads会发现其RESOURCE_GROUP字段始终为default - 在容器环境里未给
mysqld进程加CAP_SYS_NICE能力（setcap cap_sys_nice+ep /usr/sbin/mysqld），导致THREAD_PRIORITY设置静默无效
CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才真生效
漏掉任一关键参数，语句能执行成功，但资源组就是空壳。查 INFORMATION_SCHEMA.RESOURCE_GROUPS 会发现 VCPU_IDS 是 NULL 或 0-0，绑定后毫无隔离效果。
必须满足的硬条件：
-
TYPE只能是USER（用户线程）或SYSTEM（MySQL 内部线程），普通用户只能用USER -
VCPU必须填服务器真实存在的逻辑 CPU ID，例如 8 核机器 ID 是0–7；支持格式：3（单核）、2-5（连续）、0,2,4（离散），不能加引号、不能越界、不能留空 - 务必预留至少 1–2 个核给
SYS_default等系统线程，否则 mysqld 可能卡死在metadata lock或 purge 阶段
SET RESOURCE GROUP 只影响下一条 SELECT，不中断当前执行
这是最常被踩坑的点：执行 SET RESOURCE GROUP low_prio FOR 12345 后，线程 ID 12345 正在跑的那条慢 SELECT 不会暂停、不会迁移、也不会降速——它继续在原 CPU 上跑完。只有下一条新发起的 SELECT 才受约束。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
要让它“看起来立即生效”，得配合这些动作：
- 先
KILL QUERY 12345中断当前语句 - 确认目标线程状态不是
Sleep（否则报ERROR 3661 (HY000)），也不能处于Waiting for table metadata lock等不可中断状态 - 查线程 ID 必须用
performance_schema.threads.THREAD_ID（不是PROCESSLIST_ID），且确保performance_schema已启用（默认关闭） - 连接池场景下，
THREAD_ID复用频繁，临时SET极易错位，建议改用ALTER USER 'report_user'@'%' RESOURCE GROUP = batch_low_priority做用户级绑定
备份、写操作、存储过程全都不受 Resource Group 控制
所有脱离 MySQL 查询优化器路径的操作，资源组一律不干预：
-
xtrabackup、mysqldump等工具运行在 mysqld 进程之外，其 CPU 消耗不受任何影响；mysqlbackup的--read-threads参数才真正起作用 -
INSERT/UPDATE/DELETE/ALTER TABLE完全绕过资源组——哪怕你把线程绑到最低优先级组，写操作照样在所有核上自由调度 - 存储过程、触发器、事件中无法动态调用
SET RESOURCE GROUP；函数内联执行也不受控 -
SHOW、EXPLAIN、SET等管理命令不被资源组识别，即使语法允许，实际也不生效
真正需要压制 CPU 占用率时，别只盯资源组。它不提供硬隔离，也没法覆盖写链路。复杂点在于：你得先分清负载类型（纯读？混合？含备份？），再决定是用 cgroups v2 做进程级控制，还是靠 cpulimit + ionice 组合拳，或者干脆从应用层限流。
