MySQL 8.0 不支持真正的权限继承，角色嵌套仅为显式授权链，非自动继承：GRANT 'base_role' TO 'child_role' 仅授予角色，不传递后续权限变更；子角色不会随父角色权限更新而自动生效，必须手动重授或重新激活。
MySQL 8.0 没有真正的权限继承，所谓“嵌套授权”只是角色间显式授予权限的链式引用，不是自动继承；用户获得的是静态权限副本，不随上游角色变更实时生效。
角色嵌套 ≠ 权限自动继承
执行 GRANT 'base_role' TO 'child_role' 后，child_role 并不会“继承”base_role 的权限——它只是被显式授予了该角色。后续若修改 base_role 的权限（如新增 INSERT），child_role 不会自动获得，必须手动对 child_role 再执行一次 GRANT 或重新激活其权限上下文。
常见误判点：
- 看到
mysql.role_edges中存在父子记录，就认为权限已传递 - 修改父角色后未检查子角色实际权限，导致新权限在用户会话中不可用
- 混淆“角色可被授予角色”和“权限可动态继承”两个概念
如何正确构建角色嵌套链
嵌套需分三步显式完成，缺一不可：
- 先创建所有角色：
CREATE ROLE 'base_user', 'app_reader', 'app_writer'; - 给基础角色授予权限：
GRANT SELECT ON app_db.* TO 'base_user'; - 再逐层授权角色：
GRANT 'base_user' TO 'app_reader'; GRANT 'app_reader' TO 'app_writer';
注意：app_writer 要真正拥有 base_user 的 SELECT 权限，必须确保：
– 它已被赋予 app_reader 角色
– app_reader 已被赋予 base_user 角色
– 用户登录后激活的是 app_writer（或设为默认角色）
查看嵌套权限是否生效的实操方法
SHOW GRANTS 默认不显示嵌套路径，必须用 USING 显式展开：
- 查用户直接权限：
SHOW GRANTS FOR 'alice'@'%'; - 查某一层角色带来的权限：
SHOW GRANTS FOR 'alice'@'%' USING 'app_writer'; - 查完整嵌套链效果：
SHOW GRANTS FOR 'alice'@'%' USING 'app_writer', 'app_reader', 'base_user';
更可靠的方式是查系统表：
– 确认嵌套关系：SELECT * FROM mysql.role_edges WHERE FROM_USER IN ('base_user', 'app_reader');
– 确认最终权限落地：SELECT * FROM INFORMATION_SCHEMA.ROLE_TABLE_GRANTS WHERE ROLE_NAME = 'app_writer';
嵌套链失效的典型场景与修复
角色嵌套链容易在以下情况断开：
- 父角色被
DROP ROLE，但未先REVOKE其对子角色的授权 →role_edges表残留脏数据，需手动清理 - 用户被授予了
app_writer，但未设置默认角色或未执行SET ROLE 'app_writer';→ 嵌套权限完全不生效 - 使用
FLUSH PRIVILEGES试图“刷新嵌套” → 无效，该命令不处理角色元数据缓存（8.0+ 自动管理）
修复要点：
– 删除前先跑 REVOKE 'base_user' FROM 'app_reader';
– 用户侧务必执行 SET DEFAULT ROLE 'app_writer' TO 'alice'@'%';
– 权限变更后，让目标用户重新登录或执行 SET ROLE DEFAULT; 再 SET ROLE 'app_writer';
嵌套角色本质是人工维护的权限拓扑图，不是运行时策略引擎；每加一层，就要多一次显式授权、多一次验证步骤。别指望它像 Linux 组那样“改完父组，子用户立刻生效”。
