MySQL 连接属性影响资源组调度的配置方法

先把一个容易误解的点说清楚：MySQL 的连接属性不会自动触发资源组调度。应用在连接建立时传入的 app_name、workload 等键值，会出现在 Performance Schema 的 session_connect_attrs 中，适合做连接识别和审计；真正把当前线程放入资源组的动作，仍然是 SET RESOURCE GROUP，或者针对单条语句使用 RESOURCE_GROUP 优化器提示。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/resource-groups.html

推荐采用“连接属性负责识别、应用初始化负责分配、Performance Schema 负责核对”的三段式方案。这样即使连接池扩缩容或线程重新建立，也不会把“看起来属于批处理”的标签误当成已经生效的 CPU 调度。

先区分连接标签和资源组结果

session_connect_attrs 保存的是连接建立时由客户端传入的键值，核心字段包括 PROCESSLIST_ID、ATTR_NAME 和 ATTR_VALUE。资源组结果则在 performance_schema.threads 的 RESOURCE_GROUP 列中体现，两张表的共同定位点是前台连接的进程列表 ID。

创建资源组并保留可审查的调度入口

资源组先按工作负载命名，再设置 CPU 范围和线程优先级。下面的例子把低优先级批处理放入用户资源组；注释说明每条语句的边界，实际 CPU 编号要根据服务器的可用虚拟 CPU 和运维策略调整。

-- 创建一个用户资源组；CPU 范围和优先级只是示例，需按主机核数调整
CREATE RESOURCE GROUP rg_batch TYPE = USER
  VCPU = 4-7
  THREAD_PRIORITY = 10;

-- 资源组管理需要 RESOURCE_GROUP_ADMIN 权限
GRANT RESOURCE_GROUP_USER ON *.* TO 'batch_runner'@'%';

-- 变更后先检查组定义，确认启用状态和 CPU 范围
SELECT RESOURCE_GROUP_NAME, RESOURCE_GROUP_TYPE,
       RESOURCE_GROUP_ENABLED, VCPU_IDS, THREAD_PRIORITY
FROM INFORMATION_SCHEMA.RESOURCE_GROUPS
WHERE RESOURCE_GROUP_NAME = 'rg_batch';

如果只允许业务账号把自己的当前线程放入组，使用 RESOURCE_GROUP_USER；创建、修改或删除资源组则需要更高的 RESOURCE_GROUP_ADMIN。不要把管理权限直接塞进连接池账号，否则应用故障可能演变成资源组配置故障。

在连接池初始化阶段显式完成分配

连接属性应在建立连接时写入，例如 app_name=report-api、workload=batch。但 MySQL 不会因为看到 workload=batch 就自动执行调度。连接池拿到一条新连接或重新借出连接后，应在同一个会话上执行 SET RESOURCE GROUP rg_batch，再把连接交给业务代码。

-- 在当前连接上显式切换资源组；无 FOR 子句表示当前会话线程
SET RESOURCE GROUP rg_batch;

-- 读取当前连接的唯一标识，后续用它关联属性与线程状态
SELECT CONNECTION_ID() AS processlist_id;

-- 查询当前连接的标签，确认连接池传入的是本次租用的工作负载
SELECT PROCESSLIST_ID, ATTR_NAME, ATTR_VALUE
FROM performance_schema.session_connect_attrs
WHERE PROCESSLIST_ID = CONNECTION_ID()
ORDER BY ORDINAL_POSITION;

连接池复用是最容易漏掉的地方：如果同一条连接之前被设置为 rg_interactive，下一次借给批处理任务时只更新连接属性而不执行 SET RESOURCE GROUP，调度结果仍可能停留在旧组。更稳妥的做法是在每次借出时重新设置并核对失败处理。

把连接属性和资源组结果放到一张核对表

排查“属性已经写入但调度没有生效”时，不要只查属性表。用连接 ID 把属性聚合后再连接 threads，可以同时看到连接身份、线程类型和资源组。下面查询只做观测，不会替代真正的切组动作。

-- 将同一连接的属性聚合为可读标签，并关联线程当前资源组
SELECT t.PROCESSLIST_ID,
       t.PROCESSLIST_USER,
       t.RESOURCE_GROUP,
       GROUP_CONCAT(CONCAT(a.ATTR_NAME, '=', a.ATTR_VALUE)
                    ORDER BY a.ORDINAL_POSITION SEPARATOR ', ') AS attrs
FROM performance_schema.threads AS t
LEFT JOIN performance_schema.session_connect_attrs AS a
  ON a.PROCESSLIST_ID = t.PROCESSLIST_ID
WHERE t.TYPE = 'FOREGROUND'
GROUP BY t.PROCESSLIST_ID, t.PROCESSLIST_USER, t.RESOURCE_GROUP
ORDER BY t.PROCESSLIST_ID;

结果里如果 attrs 显示 workload=batch，但 RESOURCE_GROUP 仍是默认组，说明识别成功而分配步骤缺失或失败。若属性为空，优先检查客户端驱动是否支持连接属性、Performance Schema 是否启用，以及属性总量是否被截断。

上线前检查连接复用和平台边界

• 连接属性不是秘密存储：不要写入密码、令牌或完整用户隐私，只保留可审计的短标签。
• 属性数据过大可能被 Performance Schema 截断；需要关注 performance_schema_session_connect_attrs_size 和丢失计数。
• 资源组能力受平台和服务器配置限制，threads.RESOURCE_GROUP 为空时先确认当前环境是否支持。
• SET RESOURCE GROUP 是本地服务器上的管理动作，不依赖复制传播；主从环境要分别配置和核对。
• 切组失败必须让连接回到连接池前执行回滚或销毁，不能把状态不明的连接交给下一个业务。

常见问题

只设置连接属性，能不能自动进入同名资源组？

不能。连接属性只是标签，必须由应用执行 SET RESOURCE GROUP 或由语句使用资源组优化器提示。

连接池复用后为什么资源组看起来错了？

资源组属于会话线程状态，单独刷新属性不会自动切组。应在每次借出连接时重新设置并通过 threads 核对。

如何确认查到的是同一条连接？

使用当前会话的 CONNECTION_ID()，再和两张 Performance Schema 表里的 PROCESSLIST_ID 对照。

这套配置的关键是保持职责分离：属性说明“这是谁”，SET RESOURCE GROUP 说明“它被放到哪里”，threads 说明“当前是否真的在那里”。把三者连成可查询的核对链，资源组调度才不会停留在配置文件或连接字符串的假设上。