MySQL 8.0资源组不能限制CPU使用率或约束DML操作，仅对新发起的SELECT线程做VCPU绑定和THREAD_PRIORITY调度干预；CREATE必须指定TYPE=USER和真实VCPU，SET RESOURCE GROUP仅影响下一条语句，且需CAP_SYS_NICE权限才能使优先级生效。
MySQL 8.0 的资源组（Resource Group）不能限制 CPU 使用率，也不能约束写操作（INSERT/UPDATE/DELETE），它只对新发起的 SELECT 线程做 CPU 核心绑定和内核调度优先级干预——这是你配置前必须接受的前提。
CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才生效
漏掉 TYPE = USER 或 VCPU，语句看似成功，但查 INFORMATION_SCHEMA.RESOURCE_GROUPS 会发现 VCPU_IDS 是 NULL 或 0-0，资源组就是个空壳。
-
TYPE只能是USER（用户线程）或SYSTEM（MySQL 内部线程），普通用户只能用USER -
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可能卡死在 metadata lock 或 purge 上
SET RESOURCE GROUP 只影响下一条 SELECT，不中断当前执行
这是最常踩的坑：执行 SET RESOURCE GROUP oltp_high_priority 后，当前正在跑的慢查询不会暂停、迁移或降速——它继续在原 CPU 上跑完。只有下一条语句才受新资源组约束。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 查线程 ID 必须用
performance_schema.threads.THREAD_ID（不是PROCESSLIST_ID），且确认performance_schema已启用（默认关闭） - 目标线程状态不能是
Sleep，否则报错ERROR 3661 (HY000)；也不能处于Waiting for table metadata lock等不可中断状态 - 想让限制“立即生效”，得先
KILL QUERY thread_id，再让应用重连，并确保连接后立刻执行SET RESOURCE GROUP - 连接池（如 HikariCP）复用连接时，
THREAD_ID频繁变化，临时SET极易绑错会话；建议优先用用户级绑定：ALTER USER 'report_user'@'%' RESOURCE GROUP = batch_low_priority
资源组只对 SELECT 生效，DML 完全绕过
哪怕你把 UPDATE 所在线程绑到最低优先级资源组，它仍会在所有 CPU 上自由调度，CPU 占用不受控。这不是 bug，是 MySQL 8.0 的硬限制——资源组只参与优化器选中的 SELECT 查询路径调度。
- 验证是否生效，只测
SELECT SLEEP(10)或复杂只读查询，别拿UPDATE WHERE去试 - 存储过程、触发器、事件中无法动态调用
SET RESOURCE GROUP，只能由客户端或 DBA 在会话层主动干预 - 如果负载以批量写入为主（如 ETL、日志归档），资源组对这部分 CPU 占用毫无约束力，此时应转向外部手段，如
cgroups或MAX_UPDATES_PER_HOUR -
THREAD_PRIORITY在 Linux 上需mysqld进程有CAP_SYS_NICE能力（setcap cap_sys_nice+ep /usr/sbin/mysqld），否则设了等于白设
真正需要压制 CPU 占用率，别只盯资源组——它不提供时间片配额，也不做削峰；VCPU 绑定 + 优先级只是“引导”而非“限制”，而 OLTP 与报表之间的隔离，本质仍是靠业务拆分、读写分离和外部资源管控来兜底。
