Resource Groups 仅静默调整线程CPU调度，不记录日志、不限内存、不干预DML或执行计划；需查启用状态、VCPU配置、权限、线程绑定及OS级CPU亲和性验证是否生效。
Resource Groups 本身不记录“限制是否触发”，也没有执行日志或拒绝日志——它只是静默地调整线程调度策略。想确认是否生效，必须主动查状态、比对行为、排除常见失效路径。
查资源组是否已启用且配置正确
MySQL 启动时若未启用 Resource Groups，所有相关操作都无效。先确认基础就位：
- 执行
SELECT * FROM performance_schema.setup_actors WHERE RESOURCE_GROUP != 'YES';—— 若RESOURCE_GROUP列为DISABLED，说明没开；需在配置文件加resource_group_enabled=ON并重启 - 查已创建的组：
SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS;，重点看VCPU_IDS是否为有效范围（如0-3），若为NULL或0-0，说明CREATE RESOURCE GROUP漏了VCPU或写错格式（比如用了引号） - 确认用户有权限：
SHOW GRANTS FOR CURRENT_USER;中必须含RESOURCE_GROUP_ADMIN（建组）或RESOURCE_GROUP_USER（绑定）
验证线程是否真被绑到目标资源组
绑定是会话级或线程级的，且只影响后续新语句。不能靠“执行了 SET RESOURCE GROUP rg_low”就默认成功：
- 查当前会话绑定状态：
SELECT THREAD_ID, RESOURCE_GROUP, TYPE FROM performance_schema.threads WHERE PROCESSLIST_ID = CONNECTION_ID();—— 注意TYPE必须是FOREGROUND（用户线程），且RESOURCE_GROUP显示为你设的组名 - 若用
SET RESOURCE GROUP rg_low FOR thread_id绑定其他线程，thread_id必须来自performance_schema.threads.THREAD_ID（不是PROCESSLIST_ID），且该线程状态不能是Sleep，否则报错ERROR 3661 (HY000) - 连接池场景下，
THREAD_ID频繁变化，临时SET极易绑错；建议改用ALTER USER 'u'@'%' RESOURCE GROUP rg_low;做持久绑定
观察 CPU 行为是否符合预期
Resource Groups 不限内存、不杀慢查询、不改执行计划，唯一可观测效果是 CPU 调度变化：
- 执行目标
SELECT语句后，立刻运行：top -H -p $(pgrep mysqld)，找对应线程 PID（可用SELECT THREAD_OS_ID FROM performance_schema.threads WHERE THREAD_ID = ?;获取），看其 CPU 使用是否被约束在你指定的 VCPU 范围内（例如只跑在 CPU 0 和 1 上） - 对比同一语句在不同资源组下的
sys.schema_table_statistics中rows_examined和执行时间——Resource Groups 不影响扫描行数和逻辑耗时，若两者明显不同，说明实际执行路径或缓存状态变了，不是资源组在起作用 - 注意：INSERT/UPDATE/DELETE 完全绕过资源组，哪怕你给线程绑了低优先级组，这些语句仍自由抢占所有 CPU
为什么看起来“没限制”？最常踩的三个坑
现象是“绑了组，但 CPU 还是打满”，大概率掉进以下任一陷阱：
-
CREATE RESOURCE GROUP没写TYPE = USER或VCPU参数，语句能执行成功，但组无效（INFORMATION_SCHEMA.RESOURCE_GROUPS.VCPU_IDS为NULL） - 误以为能限制 DML 或备份进程——xtrabackup、mysqldump、ALTER TABLE 全部不受控，它们根本不在 Resource Groups 的调度路径上
- 期望“立即降级正在运行的 SQL”，但
SET RESOURCE GROUP只影响下一条语句；当前正在跑的那条 SELECT 会继续在原 CPU 上跑完，不会迁移或暂停
真正能反映 Resource Groups 是否起效的，只有线程 OS 级 CPU 亲和性变化。其他任何“变慢”“被拒”“内存下降”的感觉，基本都是误判——它本来就不是干这个的。
