MySQL 8.0资源组完全无法限制备份进程CPU资源，因xtrabackup、mysqldump等工具运行在MySQL服务进程之外，其CPU消耗不受内部线程调度控制；必须通过OS级cgroups、工具参数（如--throttle、ionice、cpulimit）或mysqlbackup内置选项实现限流。
MySQL 8.0 的资源组（RESOURCE GROUP）完全无法限制备份进程的 CPU 资源——这不是配置问题，而是机制层面的不可行。
备份工具如 xtrabackup、mysqldump、mysqlbackup 都运行在 MySQL 服务进程之外，它们的 CPU 消耗不受 MySQL 内部线程调度控制。你看到的“备份线程”在 performance_schema.threads 里要么不存在，要么只是短命的客户端会话线程，绑了也白绑。
SET RESOURCE GROUP FOR thread_id 对备份无效的典型表现
- 执行
SET RESOURCE GROUP low_prio FOR 12345后，xtrabackup进程的 CPU 使用率毫无变化 - 查
INFORMATION_SCHEMA.RESOURCE_GROUPS发现目标组VCPU_IDS是NULL或0-0，说明创建时漏了TYPE=USER或真实VCPU - 即使成功绑定，
mysqldump的大部分开销在客户端压缩、网络传输、本地磁盘写入，MySQL 服务器端只承担少量SELECT，而资源组只影响这部分（且仅限下一条语句） -
ERROR 3661 (HY000)频繁出现：因为备份连接常处于Sleep状态，或卡在Waiting for table metadata lock，SET RESOURCE GROUP直接拒绝执行
备份进程真正有效的 CPU 限流方式
-
xtrabackup必须用--throttle=100控制每秒 IO 操作数（IOPS），间接压制 CPU 和磁盘压力 -
mysqldump需配合 OS 工具：-
ionice -c2 -n7降低 I/O 优先级 -
cpulimit -l 30 -p $(pgrep -f "mysqldump")限制 CPU 占用率（需提前安装）
-
-
mysqlbackup使用内置参数：--read-threads=2、--number-of-buffers=8显式压低并发与内存缓冲 - 对整个
mysqld进程做系统级隔离（推荐用于生产）：- 用
cgroups v2绑定 CPU 核心（如cpuset.cpus = 0-1）并设cpu.max = 200000 100000（即 2 核配额） - 这样连带其 fork 出的子进程（含备份触发的临时线程）都受控
- 用
为什么有人坚持试资源组？容易忽略的关键点
- 误以为
mysqldump的SELECT线程绑上资源组就能控住整条链路——但资源组只约束该线程下一条SELECT，且不干预客户端侧逻辑 - 在连接池场景下反复查
THREAD_ID并SET，结果绑的是上一个请求的残留线程，目标备份连接早已复用新 ID - 忘记
resource_group_enabled=ON未在my.cnf中开启，或没给用户授RESOURCE_GROUP_ADMIN权限，导致命令静默失败
最常被跳过的事实：资源组连 INSERT/UPDATE 都不干预，更别说完全脱离 SQL 层的 xtrabackup 文件直读行为。真要压制备份负载，必须离开 MySQL 内部机制，在 OS 层或工具参数里动手。
