MySQL资源组不能限制慢查询CPU消耗，仅能将后续SELECT绑定至指定VCPU并调低调度优先级，不中断执行、不限制核数、不生效于DML；必须指定TYPE=USER和真实VCPU，否则无效。
MySQL资源组不能“限制恶意慢查询消耗CPU”，它只能让某些SELECT语句在指定VCPU上以更低优先级运行——不中断、不降频、不限核数，更对UPDATE/DELETE等写操作完全无效。
CREATE RESOURCE GROUP必须带TYPE=USER和真实VCPU
漏掉任一参数，资源组就只是个空壳：查INFORMATION_SCHEMA.RESOURCE_GROUPS会发现VCPU_IDS是NULL或0-0，绑了也白绑。
-
TYPE = USER是强制项，SYSTEM类型只留给MySQL内部线程，用户线程无法使用 -
VCPU必须填服务器真实逻辑CPU ID，比如8核机器可用0、2-5、0,2,4；写成"0-3"（带引号）或8-15会静默失败或报错 - 务必预留至少1–2个核给
SYS_default，否则purge线程或metadata lock可能卡死mysqld
SET RESOURCE GROUP只影响下一条SELECT语句
执行SET RESOURCE GROUP slow_rg FOR 12345后，线程ID 12345正在跑的那条慢SQL不会暂停、迁移或降优先级——它继续在原CPU上跑完。只有下一条新发起的语句才走新规则。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
thread_id必须是performance_schema.threads.THREAD_ID，不是PROCESSLIST_ID - 目标线程状态不能是
Sleep，否则报错ERROR 3661 (HY000) - 若线程卡在
Waiting for table metadata lock等不可中断状态，SET直接失败 - 想让限制“立即”生效，得先
KILL QUERY 12345，再让应用重连，并确保连接后立刻执行绑定
资源组只对SELECT生效，DML完全绕过
这是硬限制，不是配置问题。哪怕你把一个正在执行UPDATE的线程显式绑到低优先级资源组，它仍会在所有CPU上自由调度，CPU占用不受控。
- 验证是否生效，只能测纯读语句，例如
SELECT SLEEP(10)或复杂只读查询 -
INSERT/UPDATE/DELETE/ALTER TABLE这类写操作完全不走资源组调度逻辑 - 存储过程、触发器、事件中无法动态调用
SET RESOURCE GROUP - 如果负载以批量写入为主（如ETL），资源组对这部分CPU占用毫无约束力
THREAD_PRIORITY需CAP_SYS_NICE权限才实际生效
THREAD_PRIORITY映射到Linux的nice值（范围0–19），但普通用户线程无法直接影响内核调度，除非mysqld进程被授予CAP_SYS_NICE能力。
- 执行：
setcap cap_sys_nice+ep /usr/sbin/mysqld - 验证：
getcap /usr/sbin/mysqld应输出/usr/sbin/mysqld = cap_sys_nice+ep - 仅设
THREAD_PRIORITY而不配VCPU，效果极弱；两者必须同时生效才有实际调度差异
真正防CPU打满，得靠MAX_EXECUTION_TIME中断慢SELECT，再配合资源组做调度隔离；而写操作打满CPU时，你只能靠cgroups或代理层控制——资源组本身不提供任何CPU使用率限制能力。
