MySQL 8.0中GRANT 'role' TO user报ERROR 3530，根本原因是执行者未被显式授予该角色且附带WITH ADMIN OPTION；必须先由高权限账户授角色+WITH ADMIN OPTION，登录后还需激活角色（如SET DEFAULT ROLE ALL或启用activate_all_roles_on_login）。
普通用户无法直接用 WITH ADMIN OPTION 分发角色，必须先由高权限账户把目标角色连同 WITH ADMIN OPTION 一起授予该用户；且该用户登录后需已激活对应角色，否则 GRANT 'role' TO ... 会静默失败或报错。
为什么 GRANT 'role' TO user 总是报 ERROR 3530
这不是语法或网络问题，而是权限链断裂：MySQL 8.0 要求执行角色分发的用户，必须显式持有被分发角色（如 'app_reader'），且该角色是以 WITH ADMIN OPTION 方式授予的。常见错误包括：
- 误以为只要自己有
SELECT权限就能转授角色——不行，WITH ADMIN OPTION是角色授权时的独立修饰符，和数据权限无关 - 用
GRANT SELECT ON app.* TO 'user'@'%'授了权限，再试图GRANT 'app_reader' TO ...——这无效，因为'app_reader'角色本身没被授予该用户 - 虽执行了
GRANT 'app_reader' TO 'user'@'%'，但漏掉WITH ADMIN OPTION，导致无分发权
WITH ADMIN OPTION 必须绑定角色，不能绑定用户或权限
这是 MySQL 8.0 的硬性设计：你不能对用户直接加 WITH ADMIN OPTION，也不能对单个权限（如 SELECT）加。它只存在于「角色 → 用户」这一层授权中。正确流程是：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先创建角色：
CREATE ROLE 'app_reader'; - 给角色赋数据权限：
GRANT SELECT ON app.* TO 'app_reader'; - 再把角色连同管理权授予人：
GRANT 'app_reader' TO 'role_mgr'@'10.20.30.%' WITH ADMIN OPTION; - 被授者登录后，还需确保角色已激活（见下一条）
用户登录后角色不生效？检查 activate_all_roles_on_login
即使 GRANT ... WITH ADMIN OPTION 成功，用户登录后执行 GRANT 'app_reader' TO 'dev1'@'%' 仍可能失败，原因常是角色未激活。验证方式：
- 查当前设置：
SELECT @@activate_all_roles_on_login;—— 若返回OFF，则角色不会自动生效 - 临时启用：
SET GLOBAL activate_all_roles_on_login = ON;（重启失效） - 永久启用：在
my.cnf中添加activate_all_roles_on_login = ON并重启 mysqld - 若无法改全局配置，用户登录后必须手动执行：
SET DEFAULT ROLE ALL TO 'role_mgr'@'10.20.30.%';
分发后权限不可见？用 SHOW GRANTS 显式验证继承链
被委派者执行 SHOW GRANTS FOR CURRENT_USER; 只显示直授权限，不展开角色内容。要确认是否真能分发，必须用：
-
SHOW GRANTS FOR 'role_mgr'@'10.20.30.%' USING 'app_reader';—— 这会展示该用户以'app_reader'身份拥有的全部权限和分发能力 - 若结果里出现
GRANT 'app_reader' TO ... WITH ADMIN OPTION，说明链路完整 - 若没有，说明
WITH ADMIN OPTION没被正确授予，或角色未激活，或存在嵌套循环（如A → B → A）被 MySQL 自动拒绝
真正容易被忽略的是：角色分发不是“一次授权、永久有效”的操作。一旦上游角色权限变更（比如删掉某张表的 SELECT），所有下游通过 WITH ADMIN OPTION 分发出去的实例都会同步失效——但你不会收到任何通知，只能靠定期用 SHOW GRANTS USING 主动核验。
