mysql 8.0 的资源组不能限制备份进程资源消耗，因为xtrabackup、mysqldump、mysqlbackup等外部工具运行在mysql服务进程之外，其cpu/内存不受资源组控制；资源组仅调度mysql内部线程的select查询，而备份操作绕过sql层或在客户端处理，必须通过os级cgroups、工具自身参数（如--throttle、ionice、--read-threads）来限流。
MySQL 8.0 的资源组（Resource Groups）**不能用于限制备份进程的资源消耗**——因为 xtrabackup、mysqldump 或 mysqlbackup 这类外部备份工具运行在 MySQL 服务进程之外，它们的 CPU / 内存占用完全不受 MySQL 内部资源组机制控制。
为什么 SET RESOURCE GROUP 对备份无效？
资源组只作用于 MySQL 服务线程内部的 SELECT 查询调度，而备份操作本质是：
-
xtrabackup直接读取 InnoDB 文件（ibdata1、ib_logfile、表空间），绕过 SQL 层，不创建 MySQL 线程 -
mysqldump虽通过连接执行SELECT，但其线程属于客户端会话，且备份期间大量 I/O 和压缩逻辑在客户端进程里完成 -
mysqlbackup（Enterprise Backup）是独立二进制，以系统进程方式运行，与 MySQL server 的线程调度无绑定关系
真正能限制备份资源的替代方案
必须从操作系统或备份工具自身参数入手：
-
xtrabackup支持限速：用--throttle=100控制每秒 IO 操作数（IOPS），避免磁盘打满 -
mysqldump可配合ionice -c2 -n7和cpulimit -l 30降低优先级和 CPU 占用（需提前安装） -
mysqlbackup提供--read-threads、--number-of-buffers等参数，显式限制并发读线程和内存缓冲区大小 - 对整个
mysqld进程做系统级隔离：用cgroups v2绑定 CPU 核心、限制内存上限，这样连带其子进程（如 backup 工具调用的临时线程）也受控
误用资源组去“绑备份线程”的典型错误
有人尝试查 performance_schema.threads 找到 backup 相关线程并执行：
SET RESOURCE GROUP low_prio FOR 12345;
这不会生效，原因包括：
- 备份工具不走 MySQL 线程模型（如
xtrabackup） - 即使走线程（如
mysqldump），它执行的是大量SELECT+ 客户端处理，资源组只影响服务器端的 CPU 亲和性，不影响客户端压缩/网络传输等开销 -
THREAD_ID在连接池复用下瞬时变化，SET RESOURCE GROUP命令极易绑错目标
最常被忽略的一点：资源组连 INSERT/UPDATE 都不干预，更别说完全脱离 SQL 执行路径的备份行为。真要压制备份负载，得离开 MySQL 内部机制，在 OS 层或工具参数里动手。
