如何利用MySQL 8.0的资源组Resource Groups优化迁移后负载

CREATE RESOURCE GROUP 必须指定 TYPE 和 VCPU 才生效；仅建组不设参数则 CPU 不隔离；VCPU 是逻辑核 ID 集合，非核数分配；资源组仅限 SELECT，对写操作无效；SET RESOURCE GROUP 仅影响后续查询，不中断运行中语句。

如何利用mysql 8.0的资源组resource groups优化迁移后负载_分配cpu核心

CREATE RESOURCE GROUP 必须带 TYPE 和 VCPU 才真正生效

迁移后想靠资源组“压住”某类查询的 CPU，第一步就容易翻车：只执行 CREATE RESOURCE GROUP rg_name;，看着语句没报错，查 INFORMATION_SCHEMA.RESOURCE_GROUPS 也显示存在，但实际完全不隔离 CPU。这是因为 MySQL 8.0.19+ 的资源组不是“声明即生效”，TYPE 和 VCPU 是强制必填项。

常见错误写法：CREATE RESOURCE GROUP report_bg; → VCPU 字段为 NULL 或 0-0，绑定线程后毫无效果。

正确写法必须显式指定：

TYPE = USER（用户线程只能用 USER 类型；SYSTEM 仅限 MySQL 内部线程）
VCPU 填服务器真实存在的逻辑核 ID，例如 8 线程机器可用 0-3、4,6、7，不能越界、不能加引号、不能留空
如需优先级控制，加上 THREAD_PRIORITY = 15（范围 0–19），但注意：Linux 下需 root 权限 + CAP_SYS_NICE 能力才真正生效

SET RESOURCE GROUP FOR thread_id 只对下一个查询起作用

迁移后发现某个报表查询把 CPU 打满，想临时“降权”，直接查 performance_schema.threads 找到线程 ID，再执行 SET RESOURCE GROUP low_prio FOR 12345; —— 这操作本身没错，但效果常被误判：它只影响该线程**后续发起的第一个及之后所有 SELECT 查询**，已运行中的查询不会中断、也不会切核。

典型误用场景：

查到 PROCESSLIST_TIME > 60 的慢线程，立刻 SET → 没用，那条 SQL 已在跑了
应用用连接池，线程 ID 复用频繁，刚绑完，连接就被归还、下次复用时又跑默认调度
没开 performance_schema（默认关闭），根本看不到活跃线程，SET 无从下手

真要干预正在跑的查询，得先 KILL QUERY 12345，再让应用重试，并确保重试连接在建立后第一时间执行 SET RESOURCE GROUP。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

资源组只限制 SELECT，INSERT/UPDATE/DELETE 完全不生效

这是最容易被忽略的硬限制：MySQL 8.0 的资源组机制**仅对优化器选择的 SELECT 查询生效**。所有写操作（INSERT、UPDATE、DELETE、ALTER TABLE）完全绕过资源组调度，哪怕你显式绑定了线程，它们仍跑在默认 CPU 上。

这意味着：

迁移后如果负载含大量批量写入（比如 ETL 导入、日志归档），资源组对这部分 CPU 占用毫无约束力
不能指望一个 VCPU = 2-3 的资源组把“报表查询 + 数据清洗 UPDATE”都锁死在这两个核上
若需整体限写，得配合其他手段：语句级限流（如 max_execution_time）、应用层节流、或用 ProxySQL 做路由+限速

VCPU 不是“分配几个核”，而是 CPU 亲和性集合

迁移后配置资源组，别把 VCPU = 2-3 理解成“给它分 2 个核”，它本质是告诉内核：“这个线程只允许调度到逻辑 CPU ID 为 2 和 3 的物理核心上”。所以填错范围，等于白配。

实操前务必确认真实 CPU 拓扑：

查逻辑核数：lscpu | grep "CPU(s):" 或 cat /proc/cpuinfo | grep processor | wc -l
避免覆盖系统线程所需核心：留至少 1–2 个核（如 0 和 1）给 MySQL 自身线程（_system_ 组）和 OS，否则可能卡顿
VCPU 支持三种格式：0（单核）、2-5（连续）、0,2,4（离散），严禁写成 "0-3"（字符串引号会报错）
验证是否生效：SELECT THREAD_ID, RESOURCE_GROUP, VCPU_IDS FROM performance_schema.threads WHERE THREAD_ID = 123;，看 VCPU_IDS 是否匹配预期

复杂点在于：THREAD_PRIORITY 在高负载下作用有限，它只是提示调度器“优先抢时间片”，并不能限制 CPU 使用率上限；真正起隔离作用的是 VCPU 绑定本身。迁移后若发现绑了核仍打满，先检查是否 SELECT 查询真的跑在目标核上（可用 top -H -p $(pgrep mysqld) + 1 查线程 CPU 分布），而不是盲目调优先级。