MySQL 8.0无真正权限继承，本质是角色嵌套+显式激活：必须启用activate_all_roles_on_login、GRANT角色建立授权链、且SET DEFAULT ROLE激活用户，否则CURRENT_ROLE()返回NULL，权限不生效。
MySQL 8.0 没有“权限继承”这个功能，所谓批量继承，本质是角色嵌套 + 默认激活的组合操作；不设 SET DEFAULT ROLE 或没开 activate_all_roles_on_login，用户连 CURRENT_ROLE() 都返回 NULL，权限根本不会落地。
角色嵌套不是自动传递，而是显式授权链
你写 GRANT 'app_reader' TO 'app_writer'，只是声明“app_writer 可以被授予 app_reader”，并不等于 app_writer 现在就拥有了 SELECT 权限。真正生效要满足三个条件：
-
app_reader角色本身已被授过SELECT ON app_db.*（否则嵌套了个空壳） -
app_writer角色已被授予某个用户（比如GRANT 'app_writer' TO 'dev_user'@'%'） - 该用户登录后，必须激活包含嵌套结构的角色（
SET DEFAULT ROLE 'app_writer' TO 'dev_user'@'%'）
常见错误：只做了第一步嵌套，忘了给 app_reader 授权，或用户没被激活父角色——结果 SHOW GRANTS FOR 'dev_user'@'%' 看不到任何表级权限。
批量激活必须靠 SET DEFAULT ROLE 或全局配置
即使你给 100 个用户都 GRANT 'app_writer' TO user_x，他们登录后依然没有权限，因为 MySQL 8.0 默认不激活任何角色。解决方式只有两种：
- 逐个执行：
SET DEFAULT ROLE 'app_writer' TO 'user1'@'%'; SET DEFAULT ROLE 'app_writer' TO 'user2'@'%';（适合小规模） - 全局开启：
SET PERSIST activate_all_roles_on_login = ON;（推荐生产环境），再配合FLUSH PRIVILEGES; - 注意：
SET PERSIST会写入mysqld-auto.cnf，比SET GLOBAL更可靠；但若用 Docker 镜像，需挂载初始化 SQL 或改my.cnf持久化
漏掉这步，所有角色定义都只是“纸上权限”——CURRENT_ROLE() 返回 NULL，SELECT 直接报 ERROR 1044 (42000)。
查嵌套权限不能只看 SHOW GRANTS FOR user
SHOW GRANTS FOR 'dev_user'@'%' 只显示该用户的直接授权，哪怕他绑了三层嵌套角色，也不会展开。要验证实际生效的权限，必须用 USING 子句：
- 查 dev_user 通过
app_writer获得的权限：SHOW GRANTS FOR 'dev_user'@'%' USING 'app_writer'; - 查嵌套链是否完整：
SELECT * FROM mysql.role_edges WHERE FROM_USER IN ('app_reader', 'app_writer'); - 确认当前会话是否激活：
SELECT * FROM INFORMATION_SCHEMA.APPLICABLE_ROLES;（返回空说明没激活）
很多运维卡在“明明 GRANT 成功了却没权限”，就是没意识到 SHOW GRANTS 默认不递归展开角色链。
跨部门/多岗位权限别靠“继承”，用角色叠加更可控
比如市场部总监既要读 CRM，又要审预算表，权限不是靠“上级角色自动包含下级”，而是显式叠加：
GRANT 'marketing_base', 'finance_reviewer' TO 'zhangsan'@'10.20.%';SET DEFAULT ROLE ALL TO 'zhangsan'@'10.20.%';
这种叠加方式能避免循环嵌套（如 A → B → A 报错 ER_ROLE_GRANTED_TO_ITSELF），也方便审计：SHOW GRANTS FOR 'zhangsan'@'10.20.%' 明确列出所有角色名，不用猜继承路径。
最易被忽略的一点：角色嵌套层级建议不超过 2 层。超过后，mysql.role_edges 查询和权限溯源成本陡增，且 USING 子句一次只能指定有限角色名，调试时容易漏掉中间节点。
