mysql 8.0资源组不限制cpu使用率，仅通过vcpu亲和性与thread_priority影响线程调度；必须指定type=user和真实vcpu范围，且仅对后续select语句生效，insert/update/delete完全绕过。
MySQL 8.0 的资源组并不能限制 CPU 消耗（即使用率百分比），它只是通过操作系统级调度机制，控制“在哪跑”和“谁先跑”，而非“跑多快”或“跑多久”。
真正起作用的是两个底层机制：VCPU 亲和性绑定 + THREAD_PRIORITY 调度优先级干预。它们共同影响线程在 Linux 内核调度器中的行为，但不改变 MySQL 自身的执行逻辑或资源占用强度。
CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才生效
CREATE RESOURCE GROUP 语句漏掉 TYPE 或 VCPU，看起来成功，实则无效：
- 查
INFORMATION_SCHEMA.RESOURCE_GROUPS会发现VCPU_IDS是NULL或0-0 - 这种组绑给线程后，查询仍会在所有 CPU 上自由调度，毫无隔离效果
-
TYPE = USER是强制项；SYSTEM类型只供 MySQL 内部线程（如io_thread）用，用户无法绑定 -
VCPU必须填服务器真实存在的逻辑 CPU ID，例如 8 核机器 ID 范围是0-7：- ✅ 支持格式：
3、2-5、0,2,4 - ❌ 错误写法：
"0-3"（带引号）、8-15（越界）、VCPU = ""（空）
- ✅ 支持格式：
务必预留至少 1–2 个核给 SYS_default，否则 purge 线程或 metadata lock 等系统操作可能卡死。
SET RESOURCE GROUP FOR thread_id 只影响后续查询
这是最常被误用的点：
- 执行
SET RESOURCE GROUP slow_rg FOR 12345后，线程12345正在运行的那条 SQL 不会中断、迁移或降优先级 - 它继续在原 CPU 上跑完；只有下一条语句开始才受新资源组约束
- 若想让限制“立即生效”，必须：
- 先
KILL QUERY 12345 - 让应用重连，并确保连接建立后立刻执行
SET RESOURCE GROUP或已通过ALTER USER ... RESOURCE GROUP预设
- 先
查线程 ID 必须用 performance_schema.threads.THREAD_ID（不是 PROCESSLIST_ID），且需确认 performance_schema 已启用（默认关闭）。
目标线程状态不能是 Sleep，否则报错 ERROR 3661 (HY000)；也不能处于 Waiting for table metadata lock 等不可中断状态。
资源组只对 SELECT 生效，INSERT/UPDATE/DELETE 完全绕过
这是硬限制，不是配置问题：
- 即使你把
UPDATE所在线程显式绑到低优先级资源组，它仍会在所有 CPU 上自由调度，CPU 占用不受控 - 资源组仅作用于优化器选中的
SELECT查询路径；所有写操作类语句（INSERT、UPDATE、DELETE、ALTER TABLE）完全绕过资源组调度逻辑 - 存储过程、触发器、事件中无法动态调用
SET RESOURCE GROUP，只能由客户端或 DBA 在会话层主动干预
验证是否生效，只测 SELECT SLEEP(10) 这类纯读语句；别拿 UPDATE 去试——结果必然是“没效果”。
THREAD_PRIORITY 在 Linux 上需 CAP_SYS_NICE 权限才生效
THREAD_PRIORITY 是 Linux nice 值映射（范围 -20 到 19），但：
- 用户线程只能设 0–19；设负值会直接报错
ER_RESOURCE_GROUP_NO_ACCESS - 必须提前给
mysqld进程授予CAP_SYS_NICE能力：setcap cap_sys_nice+ep /usr/sbin/mysqld - 没开能力时，无论怎么设
THREAD_PRIORITY，都等于白设 -
THREAD_PRIORITY对 CPU 占用率影响很有限：它不削峰、不限时，只影响调度器“倾向性”；当所有线程优先级都低时，照样抢满 CPU
真正起隔离作用的是 VCPU 的物理划分——比如 OLTP 用 0-1，报表用 2-3；混用同一组核心（如都设 0-3）基本等于没绑。
复杂点在于：你以为在“限 CPU”，其实只是在做线程调度提示；你以为绑了就生效，其实只对下一条语句有效；你以为能管住所有 SQL，结果写操作全绕过。这些边界条件不厘清，配置再多也压不住负载。
