MySQL 8.0资源组完全无法优化备份进程CPU争抢，因xtrabackup、mysqldump等工具运行在MySQL进程外部，其CPU由OS调度；有效方案是cpulimit、ionice、xtrabackup的--throttle/--parallel参数或cgroups v2系统级隔离。
MySQL 8.0 的资源组 完全无法优化备份进程的 CPU 争抢——这不是配置不到位，而是设计上就不支持。
xtrabackup、mysqldump、mysqlbackup 这些工具运行在 MySQL 进程外部，它们的 CPU 消耗由操作系统直接调度，和 RESOURCE GROUP 机制毫无关系。你绑了线程、设了 VCPU、调了 THREAD_PRIORITY，对备份进程的 CPU 占用率没有任何影响。
为什么 SET RESOURCE GROUP FOR thread_id 对 xtrabackup/mysqldump 无效
-
xtrabackup进程本身不进入 MySQL 线程模型：它通过 socket 连接 MySQL，执行少量SELECT（如获取 binlog 位置、表结构），其余时间都在本地做文件拷贝、压缩、校验，这些全在用户态完成 -
mysqldump的主要开销在客户端：序列化数据、网络发送、本地磁盘写入；MySQL 服务端只响应一个个短SELECT，而资源组只对“下一条SELECT”生效，且仅约束其调度优先级和 VCPU 亲和性 - 执行
SET RESOURCE GROUP low_prio FOR 12345后立即查performance_schema.threads，会发现该线程状态已是Sleep或Waiting for table metadata lock，触发ERROR 3661 (HY000)，命令静默失败
真正能压制备份 CPU 的 OS 级手段
-
cpulimit直接限制进程 CPU 百分比（需提前安装）：cpulimit -l 30 -p $(pgrep -f "xtrabackup.*--backup")
注意：必须在xtrabackup启动后立刻执行，否则可能错过主工作进程 -
ionice降 I/O 优先级（减少磁盘争抢，间接缓解 CPU 峰值）：
MySQL8 CRM Schema Design Expert下载面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
ionice -c2 -n7 xtrabackup --backup --target-dir=/mydata/backup/xtrabackup/full/
-
xtrabackup自带限流参数（最推荐）：-
--throttle=100：限制每秒 IO 操作数（IOPS），比 CPU 限频更稳定、更可控 -
--parallel=2：显式控制并发线程数，避免多核抢占 -
--compress-threads=1：压缩阶段单线程，防止 gzip 占满 CPU
-
-
mysqlbackup可用内置参数压低资源：--read-threads=2--number-of-buffers=8-
--use-tts（表空间传输，跳过部分元数据扫描）
误用资源组时最常踩的三个坑
- 创建资源组漏掉
TYPE = USER或VCPU = 0-1：语句能执行成功，但查INFORMATION_SCHEMA.RESOURCE_GROUPS发现VCPU_IDS是NULL，等于白建 - 以为给备份连接绑定资源组就能控住整条链路：实际上只影响该连接下一条
SELECT，而备份工具的绝大多数 CPU 消耗根本不经过 MySQL 查询路径 - 在连接池环境反复
SET RESOURCE GROUP：THREAD_ID复用频繁，刚绑完就被下一个请求覆盖，目标线程根本没被约束
真正要隔离备份负载，得从系统层下手：用 cgroups v2 绑定 cpuset.cpus 和 cpu.max，这样连 xtrabackup fork 出的子进程（如 gzip、xbstream）都受控——这才是生产环境该走的路。
