MySQL 8.0资源组仅对SELECT生效，写操作完全绕过；创建时必须显式指定TYPE=USER/SYSTEM和有效VCPU范围，否则无CPU隔离效果。
CREATE RESOURCE GROUP 必须显式指定 TYPE 和 VCPU
升级到 MySQL 8.0 后，CREATE RESOURCE GROUP 不再是“建了就生效”。漏掉 TYPE 或 VCPU 会导致资源组创建成功但实际无 CPU 隔离效果——查 INFORMATION_SCHEMA.RESOURCE_GROUPS 会发现 VCPU 字段为 NULL 或 0-0。
必须显式声明：
-
TYPE = USER（用户线程只能用USER；SYSTEM仅供 MySQL 内部线程） -
VCPU必须是有效逻辑核范围，例如0、1-2、0,2,4；不能留空、填-1或超出物理核数 -
THREAD_PRIORITY在 Linux 上需 root 权限 +CAP_SYS_NICE能力才真正起作用；否则设了也白设
正确示例：CREATE RESOURCE GROUP rg_tenant_a TYPE = USER VCPU = 0-1 THREAD_PRIORITY = 19;
SET RESOURCE GROUP FOR thread_id 只影响后续查询
资源组不是“永久绑定线程”，而是调度策略。执行 SET RESOURCE GROUP rg_tenant_a FOR 12345 后，仅该线程 ID 的下一个查询开始受约束——已运行中的慢 SQL 不会中断或迁移 CPU 核。
常见误用场景：
- 从
performance_schema.threads找出长时间运行的线程，直接SET绑定——无效，那条 SQL 已在跑 - 应用使用连接池（如 HikariCP），线程 ID 复用频繁，
SET命令可能绑错会话 - 未启用
performance_schema（默认关闭），根本查不到活跃线程 ID
真要干预运行中查询，得先 KILL QUERY 12345，再让应用重试，并确保重试连接在初始化时就绑定了资源组。
资源组只对 SELECT 生效，写操作完全绕过
这是最容易被忽略的硬限制：RESOURCE GROUP 在 MySQL 8.0 中仅控制优化器选择的 SELECT 查询。所有写操作——INSERT、UPDATE、DELETE、ALTER TABLE——完全不走资源组调度，哪怕线程已绑定，仍跑在默认 CPU 上。
这意味着：
- 无法靠资源组压制一个正在执行大批量
UPDATE的租户任务 - 混合负载下，高优先级租户的
SELECT可能被保护，但其自身的写操作仍会抢占 CPU，间接影响其他租户 - 若租户主要负载是写密集型（如日志写入、实时聚合），资源组基本不起隔离作用
多租户场景下，资源组只是 CPU 层面的辅助手段
资源组解决不了数据面和权限面的隔离问题，它只管“谁能在哪些核上跑 SELECT”。真正的多租户性能隔离需要组合策略：
- 数据库级隔离仍是首选：每个租户独占
database，配合精确GRANT和禁用SHOW DATABASES - 资源组可作为补充：为关键租户的报表类
SELECT绑定专用核，避免 OLTP 查询被长耗时分析查询拖垮 - 注意
VCPU分配不能重叠：比如rg_tenant_a VCPU = 0-1和rg_tenant_b VCPU = 1-2共享核 1，仍可能互相干扰
复杂点在于：你得清楚知道哪些租户的哪些查询是 SELECT 密集型、哪些核空闲、哪些线程 ID 能稳定对应租户——这些在连接池+短连接场景下极难精准控制。
