RESOURCE_GROUP_ADMIN权限是创建和管理资源组的必要条件，必须由全局账号授予ON .范围，且需FLUSH PRIVILEGES生效；其与RESOURCE_GROUP_USER权限职责分离，前者含后者能力；启用前须确认@@have_resource_group=’YES’并确保系统支持。
RESOURCE_GROUP_ADMIN 权限是管理资源组的必要条件，没有它，连 CREATE RESOURCE GROUP 都会报错：ERROR 3713 (HY000): Access denied; you need (at least one of) the RESOURCE_GROUP_ADMIN privilege(s) for this operation。
必须用具有全局权限的账号（如 root）执行授权
GRANT RESOURCE_GROUP_ADMIN ON <em>.</em> TO 'user_name'@'host'; FLUSH PRIVILEGES; 是唯一有效路径。注意：
- 权限只能授予全局范围（
ON <em>.</em>），不支持库级或表级粒度 -
RESOURCE_GROUP_ADMIN不可拆分，不能只给创建权限而禁止修改或删除 - 授权后需
FLUSH PRIVILEGES，否则新权限不会立即生效
区分 RESOURCE_GROUP_ADMIN 和 RESOURCE_GROUP_USER
RESOURCE_GROUP_USER 是另一个独立权限，仅用于线程分配操作（如 SET RESOURCE GROUP 或使用 /<em>+ RESOURCE_GROUP() </em>/ hint）。它不包含任何资源组定义能力：
- 拥有
RESOURCE_GROUP_USER但无RESOURCE_GROUP_ADMIN的用户，无法执行CREATE、ALTER、DROP RESOURCE GROUP - 反之，有
RESOURCE_GROUP_ADMIN的用户默认也具备RESOURCE_GROUP_USER能力（MySQL 8.0.30+ 行为），但显式授予更稳妥
创建资源组前务必确认 MySQL 启动参数兼容性
某些部署方式（尤其是 RPM 安装或 systemd 管理的实例）默认禁用 resource groups，即使授了权也无法使用：
- 检查
SELECT @@have_resource_group;—— 返回YES才表示功能已启用 - 若返回
NO，需在my.cnf中显式添加resource_group=ON并重启 mysqld - Docker 容器中还需确认容器启动时未屏蔽
cap_sys_nice（Linux capability），否则THREAD_PRIORITY设置会静默失效
权限变更后记得验证实际效果
授权不是一劳永逸的。常见验证点包括：
- 登录目标用户，执行
SHOW GRANTS;确认RESOURCE_GROUP_ADMIN出现在结果中 - 尝试创建一个测试组：
CREATE RESOURCE GROUP test_rg TYPE = USER VCPU = 0 THREAD_PRIORITY = 5; - 查询
INFORMATION_SCHEMA.RESOURCE_GROUPS确认该组已写入且RESOURCE_GROUP_ENABLED = 1
真正容易被忽略的是：权限生效依赖于 MySQL 实例是否真正加载了 resource group 功能模块，而不是单纯看 SQL 授权语句有没有执行成功。
