如何利用MySQL 8.0的资源组功能限制备份进程的资源

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 层或工具参数里动手。