CREATE RESOURCE GROUP 必须指定 TYPE 和 VCPU 才生效；仅建组不设参数则 CPU 不隔离；VCPU 是逻辑核 ID 集合，非核数分配；资源组仅限 SELECT，对写操作无效；SET RESOURCE GROUP 仅影响后续查询，不中断运行中语句。
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。
面向 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 分布），而不是盲目调优先级。
