Resource Group 仅限制新发起 SELECT 的 CPU 调度，不中断慢查询、不限制内存与执行时间；真正拦截慢 SQL 需配合 max_execution_time。
Resource Group 不能限制慢 SQL 的执行资源——它只对后续新发起的 SELECT 语句生效，且仅干预 CPU 调度（VCPU 绑定 + 优先级），不中断、不终止、不限制内存或执行时间。
SET RESOURCE GROUP 只影响下一条语句，不中断当前运行的慢查询
你执行 SET RESOURCE GROUP rg_low 后，正在执行的那条 10 分钟 SELECT 不会暂停、迁移、降频或被 KILL。它继续在原 CPU 上跑完。只有下一条新发起的语句才走新组规则。
- 这是设计使然，不是 bug：MySQL 不做运行时线程迁移
- 若想让限制“立刻起效”，必须先
KILL QUERY thread_id，再让应用重试，并确保重试连接已绑定资源组（比如通过ALTER USER ... RESOURCE GROUP） - 查线程 ID 要用
performance_schema.threads.THREAD_ID，不是PROCESSLIST_ID；状态不能是Sleep，否则报错ERROR 3661 (HY000)
CREATE RESOURCE GROUP 必须带 TYPE=USER 和真实 VCPU 才有效
漏掉任一关键参数，语句能执行成功，但实际无效：
- 必须写
TYPE=USER：用户线程只能用USER类型；SYSTEM类型仅供 MySQL 内部线程使用，你绑不上 -
VCPU必须填服务器真实存在的逻辑 CPU ID：8 核机器是0-7，写VCPU=4-7有效，写VCPU="0-3"（带引号）或VCPU=8-15会静默失败或报错 - 支持格式只有三种：
0（单核）、2-5（连续）、0,2,4（离散），不能混用，也不能留空 - 务必预留至少 1–2 个核给
SYS_default，否则mysqld自身可能卡死在 purge 或 metadata lock 上
Resource Group 对 INSERT/UPDATE/DELETE 完全无效
这是硬限制，不是配置问题：
- 所有 DML 语句（
INSERT、UPDATE、DELETE、REPLACE、DO）完全绕过资源组调度逻辑 - 存储过程、触发器、事件中无法动态调用
SET RESOURCE GROUP - 想限制写操作的 CPU 占用，只能靠外部手段：Linux
cgroups、systemdservice limits，或代理层（如 ProxySQL + 自定义规则）
真正能拦住慢 SQL 的，是 max_execution_time，不是 Resource Group
Resource Group 不管执行时间，只管“在哪跑、谁先跑”。防慢查询打满 CPU，必须组合使用：
- 会话级：
SET SESSION max_execution_time = 3000—— 后续所有SELECT超过 3 秒自动被KILL QUERY - 语句级提示更精准：
SELECT /<em>+ MAX_EXECUTION_TIME(2000) </em>/ * FROM t WHERE ... - 注意：
max_execution_time对INSERT/UPDATE/DELETE无效，且 MySQL 5.7.8+ 才支持
真正复杂的地方在于：Resource Group 和 max_execution_time 是两个正交机制，一个管调度，一个管中断，缺一不可；而它们各自都有权限、系统前提、作用范围和静默失效的可能。
