MySQL 8.0 引入的角色 Role 并不是一个新的权限实体，而是一个可以被授予用户或其他角色的权限集合名称。角色之间可以互相授权，这意味着权限可以沿着角色授权关系逐层传递，形成继承效果。很多人对角色功能的理解停留在单个角色直接授权给用户，却忽略了角色到角色的 GRANT 操作，这恰恰是构建分层权限模型的关键。接下来从基础机制开始，逐步展开嵌套授权的实现方式。
一、角色权限继承的基本机制
角色在使用前需要先创建，并通过 GRANT 语句把具体权限授予角色。用户得到角色后，并不等于权限自动生效，因为 MySQL 8.0 的角色默认处于未激活状态，必须通过 SET DEFAULT ROLE 或会话内 SET ROLE 来激活。下面的示例创建了一个只读角色，并把它授予给开发用户：
CREATE ROLE 'app_reader'; GRANT SELECT ON app_db.* TO 'app_reader'; CREATE USER 'dev01'@'%' IDENTIFIED BY 'Dev_password123'; GRANT 'app_reader' TO 'dev01'@'%'; SET DEFAULT ROLE 'app_reader' TO 'dev01'@'%';
这里 app_reader 是角色的名字，使用引号包裹是因为名称中包含下划线。实际环境中建议用反引号或单引号明确标识。用户 dev01 登录后，app_reader 成为默认角色，其对 app_db 的只读权限会自动激活。如果不写最后一行，用户虽然被授予了角色，但角色处于未激活状态，执行 SELECT 时会报权限不足，这是角色使用中最高频的坑。
角色权限继承的本质是角色之间的授权关系。假设有 base_reader 和 dev_writer 两个角色，dev_writer 需要先拥有 base_reader 的查询权限，再拥有自己的写入权限。可以先将 base_reader 授予 dev_writer，那么 dev_writer 的权限集合就包含 base_reader 的所有权限。当用户激活 dev_writer 时，被继承的查询权限也一并激活。这种继承是动态叠加的，后续修改 base_reader 的权限，凡是直接或间接继承它的角色都会受到影响。
二、嵌套授权的实现与验证
理解了角色之间可以互相授权后，就可以构造更完整的分层模型。下面创建一个三层角色：base_reader 负责基础查询，dev_writer 负责数据写入，team_lead 聚合前两者并额外获得结构修改权限。这里的关键操作是 GRANT 'base_reader' TO 'dev_writer' 以及 GRANT 'dev_writer' TO 'team_lead'，它们形成了真正的继承链。
CREATE ROLE 'base_reader', 'dev_writer', 'team_lead'; GRANT SELECT ON app_db.* TO 'base_reader'; GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'dev_writer'; GRANT 'base_reader' TO 'dev_writer'; GRANT 'dev_writer' TO 'team_lead'; GRANT ALTER, CREATE INDEX ON app_db.* TO 'team_lead';
此时 team_lead 直接拥有 ALTER 和 CREATE INDEX 权限，并通过 dev_writer 继承其写入权限，再通过 dev_writer 继承 base_reader 的查询权限。用户只要被授予 team_lead，理论上就获得了三层权限的总和。
验证这种继承关系可以从两个层面进行。第一，查看角色本身被授予了哪些角色，使用 SHOW GRANTS FOR team_lead 会看到 GRANT 'dev_writer' TO 'team_lead' 这样的记录，但不会展开 dev_writer 包含 base_reader 的细节，这是理解角色链时需要注意的：展示的是直接授权边，不是展开后的全部权限。第二，验证最终用户的实际权限，可以使用带 USING 子句的命令：
SHOW GRANTS FOR 'alice'@'%' USING 'team_lead';
这个命令会显示用户通过 team_lead 得到的权限。结合 mysql.role_edges 系统表，可以查询角色与角色、角色与用户之间的边关系：
SELECT FROM_USER, TO_USER FROM mysql.role_edges WHERE TO_USER = 'team_lead';
如果 mysql.role_edges 中已经有从 dev_writer 到 team_lead 的记录，就说明嵌套授权已经被记录在案。该表只存储角色图的边，不会展开权限，因此适合做权限拓扑审计。
三、角色激活与默认角色对继承的影响
即使角色之间已经建立了继承关系，如果最上层角色在用户会话中未激活，整条继承链也不会生效。MySQL 的角色激活有两种方式：登录时自动激活默认角色，或者会话内显式执行 SET ROLE。当用户拥有多个角色时，可以设置 SET DEFAULT ROLE ALL TO user 一次激活全部默认角色，也可以只选择部分角色。
嵌套角色激活有一个容易误解的地方：用户激活 team_lead 后，是否还需要单独激活 dev_writer 和 base_reader？答案是不需要。MySQL 在激活一个角色时，会递归激活该角色被授予的其他角色，因此 team_lead 被激活后，其继承链上的角色都会处于活动状态。这个特性让高层角色的使用体验非常简洁，用户只需要关心自己拥有哪些顶层角色。
但在会话内手动 SET ROLE 时，必须明确指定角色名称，不能使用 SET ROLE ALL 激活所有角色然后期望继承链自动展开。实践中更推荐通过 SET DEFAULT ROLE 把常用角色设为默认，减少用户登录后的额外操作。还要注意，SET ROLE 只能激活当前用户已经被授予的角色，如果用户只被授予了 team_lead，就无法直接执行 SET ROLE 'base_reader'，因为没有直接授予关系。
四、回收权限与循环授权的细节
嵌套授权提高了管理效率，但也让权限回收变得需要仔细理解。如果从 base_reader 撤销了 SELECT 权限，那么所有直接或间接继承 base_reader 的角色和用户都会失去 app_db 的查询能力。如果只是断开角色之间的边，例如 REVOKE 'base_reader' FROM 'dev_writer'，则 dev_writer 不再继承查询权限，但 team_lead 仍然通过 dev_writer 间接指向 base_reader 吗？不会，因为 dev_writer 已经不再拥有 base_reader，所以 team_lead 通过 dev_writer 的继承链也丢失 base_reader。理解这一点有助于在变更角色的下级边时预估影响范围。
另一个常见的运维问题是不小心形成循环授权。比如将 role_a 授予 role_b，又把 role_b 授予 role_a，MySQL 不会阻止这种操作，但权限激活和审计会变得复杂，甚至导致管理混乱。生产环境中建议用 mysql.role_edges 定期检查是否存在环路，或者至少在角色命名和授权流程上约定单向依赖，避免双向引用。
权限变更的生效时间也会影响继承。数据库、表级权限的修改通常立即生效，但已经建立的会话中，角色的活动集合可能不会自动刷新所有缓存。如果发现撤销权限后用户仍能执行旧操作，可以尝试让用户重新连接或执行 FLUSH PRIVILEGES。对于基于角色的复杂继承，建议把权限评审和变更记录纳入变更流程，而不是等到审计时再反查。