MySQL 8.0 资源组无法限制备份进程负载，因其仅调度 MySQL 内部线程，而 xtrabackup、mysqldump、mysqlbackup 均运行在 server 外，绕过 SQL 层与线程模型；有效限流须在 OS 层或工具参数中实现。
MySQL 8.0 的资源组完全无法限制备份进程负载。 因为 xtrabackup、mysqldump、mysqlbackup 等工具运行在 MySQL server 进程之外，不创建受控的 MySQL 内部线程，资源组的 CPU 调度机制对其无效。
为什么 SET RESOURCE GROUP 对备份毫无作用
资源组只干预 MySQL 服务线程内部的 SELECT 查询调度。而备份行为本质是：
- xtrabackup 直接读取
ibdata1、ib_logfile等物理文件，绕过 SQL 层和线程模型 - mysqldump 虽通过连接执行
SELECT，但其 I/O、压缩、网络传输逻辑全在客户端进程，MySQL 服务端只负责返回结果集 - mysqlbackup 是独立二进制，以系统进程方式运行，与 mysqld 的线程调度无绑定关系
即使你查到 performance_schema.threads 里某个线程名含 “backup”，执行 SET RESOURCE GROUP low_prio FOR thread_id 也不会生效——它不是资源组能识别和调度的目标类型。
真正有效的备份限流手段
必须离开 MySQL 内部机制，在 OS 层或工具参数中控制：
-
xtrabackup：用--throttle=100限制每秒 IOPS，避免磁盘打满 -
mysqldump：配合ionice -c2 -n7降低 I/O 优先级，再加cpulimit -l 30限制 CPU 使用率（需提前安装） -
mysqlbackup：用--read-threads=2和--number-of-buffers=16显式约束并发读和内存缓冲 - 对整个
mysqld进程做系统级隔离：用 cgroups v2 绑定 CPU 核心、限制内存上限，其子进程（包括备份调用的临时线程）也会被纳入管控
误用资源组去“绑备份线程”的典型错误
常见静默失败场景包括：
- 执行
SET RESOURCE GROUP low_prio FOR 12345后无报错也无效果——因为该thread_id不属于资源组可调度范围 - 试图用
ALTER USER 'backup_user'@'%' RESOURCE GROUP = low_prio持久绑定——用户级绑定只影响其发起的SELECT/INSERT/UPDATE/DELETE，不覆盖备份工具自身的系统调用 - 在配置文件中开启
resource_group_enabled=ON并以为万事大吉——这仅让资源组功能可用，不改变备份进程的执行路径
最常被忽略的一点：资源组连 INSERT/UPDATE 都不干预，更别说完全脱离 SQL 执行路径的备份行为。真要压制备份负载，得在 OS 层或工具参数里动手。
