普通用户执行GRANT 'role_name' TO 'user'报ERROR 3530，是因为该操作需ROLE_ADMIN权限，该权限必须由高权限账户显式授予且不可通过角色继承；缺少此权限或activate_all_roles_on_login未开启均会导致失败。
普通用户无法直接委派角色管理权限，必须由具备 ROLE_ADMIN 权限的高权限账户显式授予，且该权限不可通过角色间接继承。
为什么普通用户执行 GRANT 'role_name' TO 'user' 会报错 ERROR 3530
MySQL 8.0 对角色委派做了严格权限隔离：GRANT role TO user 不是普通 DML 操作，而是元数据变更，需明确持有 ROLE_ADMIN 权限。即使你已把某个角色（如 app_admin）授予了该用户，只要没单独给它 ROLE_ADMIN，它依然不能转授角色。错误信息 ERROR 3530 (HY000): Cannot grant to a role or user without the ROLE_ADMIN privilege 就是这个原因。
常见误解是“我把 app_admin 角色给了他，里面包含 CREATE ROLE 和 GRANT OPTION，他就该能委派”——但 MySQL 不支持角色内嵌 ROLE_ADMIN，该权限只能直接授予用户/角色，且不继承。
-
ROLE_ADMIN是全局动态权限，必须用GRANT ROLE_ADMIN ON *.* TO 'user'@'%'单独授予 - 不能写成
GRANT ROLE_ADMIN ON mydb.* TO ...—— 范围必须是*.* - 授予后需
FLUSH PRIVILEGES（虽 8.0 多数情况自动刷新，但生产环境建议显式执行）
ROLE_ADMIN 和 APPLICATION_PASSWORD_ADMIN 的区别
两者都影响角色操作，但作用点完全不同：
-
ROLE_ADMIN：控制能否执行CREATE ROLE、DROP ROLE、GRANT role TO user、REVOKE role FROM user -
APPLICATION_PASSWORD_ADMIN：仅控制能否执行SET DEFAULT ROLE（即激活角色），和委派无关
所以，若目标是让某用户“把角色分给别人”，只需给 ROLE_ADMIN；若他还需要“帮别人设默认角色”，才额外加 APPLICATION_PASSWORD_ADMIN。两者可分开授权，不必捆绑。
如何安全地委派角色管理权（最小权限原则）
直接给 ROLE_ADMIN ON *.* 风险过高，推荐限制作用域和行为：
- 只对特定主机授权：
GRANT ROLE_ADMIN ON *.* TO 'role_mgr'@'10.20.30.%'，避免开放给% - 不授予
WITH GRANT OPTION，防止该用户再把ROLE_ADMIN授出 - 搭配
activate_all_roles_on_login=ON（需 root 设置并写入my.cnf），否则被委派者即使拿到角色也无法自动生效 - 验证是否生效：
SHOW GRANTS FOR 'role_mgr'@'10.20.30.%';必须看到ROLE_ADMIN行；再用该用户登录，尝试GRANT 'app_reader' TO 'test_user'@'%';看是否成功
委派后仍无法 GRANT？检查这三点
即便已授 ROLE_ADMIN，以下情况仍会导致失败：
- 角色名主机部分不匹配：比如
GRANT 'app_reader'@'localhost' TO 'user1'@'%'会失败，因角色定义在localhost，而用户在%；必须统一为'app_reader'@'%'或'user1'@'localhost' - 目标用户不存在：MySQL 8.0 要求被授角色的用户必须已存在（
CREATE USER已执行），否则报ERROR 1396 - 未启用角色全局开关：
activate_all_roles_on_login为OFF时，GRANT role TO user虽语法通过，但后续SET DEFAULT ROLE会静默失败，CURRENT_ROLE()始终返回NULL
角色委派不是“赋予权限就完事”的线性流程，而是依赖三重确认：权限到位（ROLE_ADMIN）、对象存在（用户+角色 host 匹配）、系统开关开启（activate_all_roles_on_login）。漏掉任一环，表面成功，实际无效。
