MySQL 8.0资源组必须显式指定TYPE=USER和真实VCPU才生效，仅对SELECT生效，写操作完全绕过；SET RESOURCE GROUP只影响后续查询，不中断运行中语句。
不能靠资源组“自动分流”或“限CPU使用率”，必须手动建组 + 显式绑定 + 区分SELECT与写操作，否则建了也白建。
CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才真正生效
迁移后新建资源组却没效果？大概率是漏写了关键参数。MySQL 8.0.19+ 的 CREATE RESOURCE GROUP 语句表面成功，但若没指定 TYPE 和 VCPU，该组实际无法隔离 CPU。
-
TYPE = USER是强制项，用户线程只能用这个类型；SYSTEM仅限 MySQL 内部线程（如log_flusher） -
VCPU必须填服务器真实存在的逻辑核 ID，比如 8 线程机器可用0-3、4,6,7，不能写"0-3"（带引号）、8-15（越界）或留空 - 查确认是否生效：执行
SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS WHERE RESOURCE_GROUP_NAME = 'your_rg';，若VCPU_IDS为NULL或0-0，说明绑定失败 - 务必预留至少 1–2 个核给
SYS_default，否则 purge、metadata lock 等系统线程可能卡死
SET RESOURCE GROUP FOR thread_id 只影响后续查询，不中断当前执行
发现某报表查询把 CPU 打满，想立刻降权？直接 SET RESOURCE GROUP low_prio FOR 12345 没用——它只对下一条 SELECT 生效，正在跑的那条 SQL 完全不受影响。
- 查线程 ID 必须用
performance_schema.threads.THREAD_ID（不是PROCESSLIST_ID），且需先开performance_schema（默认关闭） - 目标线程状态不能是
Sleep，否则报错ERROR 3661 (HY000)；也不能处于Waiting for table metadata lock等不可中断状态 - 真要立即生效，得先
KILL QUERY 12345，再让应用重试，并确保重试连接已绑定资源组（比如通过ALTER USER） - 连接池环境下，
THREAD_ID复用频繁，临时SET极易绑错会话，建议优先用用户级绑定
资源组只对 SELECT 生效，INSERT/UPDATE/DELETE 完全绕过
迁移后负载含大量 ETL 导入或日志归档？别指望资源组能压住这部分 CPU —— 所有写操作类语句（INSERT、UPDATE、DELETE、ALTER TABLE）完全不走资源组调度逻辑。
- 哪怕你把
UPDATE所在线程显式绑到低优先级资源组，它仍会在所有 CPU 上自由调度 - 资源组只作用于优化器选中的
SELECT查询路径；存储过程、触发器、事件中也无法动态调用SET RESOURCE GROUP - 若写操作是瓶颈，得换外部手段：
cgroups控制mysqld进程整体 CPU/内存，或在 ProxySQL 层做限流 - 对
log_flusher等关键内部线程，可用TYPE = SYSTEM资源组绑定（如VCPU = 0-1+THREAD_PRIORITY = -20），但需提前授CAP_SYS_NICE权限
最易被忽略的点：资源组不是“限频”，而是“钉核 + 调度优先级”。即使绑成功了，top 里看到某个线程仍占满一个核，这完全正常——它只是被固定在那个核上运行，且优先级更低，让其他高优线程能抢走时间片。
