RESOURCE GROUP不能控制后台任务CPU占用，仅对TYPE=USER的SELECT查询生效；SYSTEM类型后台线程（如purge、io_thread）固定归属SYS_default，无法绑定或限制，需用cgroups等系统级手段管控。

RESOURCE GROUP 不能控制后台任务的 CPU 占用——MySQL 8.0 的资源组只对用户线程（TYPE = USER）生效，且仅约束 SELECT 查询；所有后台线程（如 purge、io_thread、binlog_dump）都属于 SYSTEM 类型，无法被用户创建或绑定的资源组干预。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

---

CREATE RESOURCE GROUP 必须指定 TYPE = USER，否则无效

• SYSTEM 类型资源组是 MySQL 内置的（如 SYS_default），用户不能创建、修改或显式绑定任何线程到自定义 SYSTEM 组
• 写 CREATE RESOURCE GROUP rg1 TYPE = SYSTEM VCPU = 0 会报错：ERROR 3660 (HY000): Invalid resource group type
• 漏掉 TYPE 参数（如 CREATE RESOURCE GROUP rg1 VCPU = 0）语句能执行，但查 INFORMATION_SCHEMA.RESOURCE_GROUPS 会发现 VCPU_IDS 是 NULL，实际无约束力

---

后台任务（purge/io_thread/replication）完全绕过资源组调度

• 这些线程由 MySQL 内核启动，固定归属 SYS_default 或其他内部组，不响应 SET RESOURCE GROUP
• 即使你给某个连接绑了低优先级资源组，它发起的 INSERT 触发的 purge 线程仍跑在默认 CPU 上，不受限
• 常见误判：看到 top -H -p $(pgrep mysqld) 里有高 CPU 的线程 ID，试图用 SET RESOURCE GROUP FOR thread_id 绑定——失败，因为该 thread_id 来自 performance_schema.threads 中 TYPE = 'BACKGROUND'，不支持绑定

---

想压住 purge 或复制线程的 CPU，得换手段

• innodb_purge_threads 可设为 1（默认 4），减少并发 purge 线程数，间接降 CPU
• 复制线程（sql_thread, io_thread）无法通过资源组限频，但可用系统级工具：
  • cgroups v2（推荐）：把整个 mysqld 进程放入 cpu.max 限制的 cgroup
  • cpulimit：临时压制特定线程 PID（不持久，重启失效）
• 若用 Docker，直接配 --cpus="1.5" 和 --memory-swap=1G，比在 MySQL 内部折腾资源组更可靠

---

真正容易被忽略的一点：资源组不是“CPU 限频器”，它不阻止线程跑满所绑定的核；它只是把线程钉在某些核上 + 调整内核调度顺序。后台任务本身就不走这套逻辑，硬要塞进去只会浪费调试时间。