MySQL 8.0 没有真正的角色继承功能，所谓“继承”实为角色嵌套与显式激活的组合效果；必须先启用角色支持（SET GLOBAL activate_all_roles_on_login=ON并授ROLE_ADMIN权限），再通过GRANT role_a TO role_b建立授权链，并设默认角色才能使嵌套权限生效。
MySQL 8.0 没有“角色继承”这个独立功能，所谓继承只是角色嵌套 + 显式激活的组合效果；不执行 GRANT role_a TO role_b 和 SET DEFAULT ROLE，就不存在自动权限传递。
CREATE ROLE 后必须显式启用角色支持才能用嵌套
即使语法允许 GRANT role_a TO role_b，MySQL 8.0 默认也会报错 ERROR 3719 (HY000): 'role_a'@'%' is not set as a role。根本原因是全局变量 activate_all_roles_on_login 默认为 OFF，且用户缺少 ROLE_ADMIN 权限。
- 由 root 或高权限用户执行：
SET GLOBAL activate_all_roles_on_login = ON; - 再执行：
GRANT ROLE_ADMIN ON *.* TO 'admin_user'@'%'; - 最后：
FLUSH PRIVILEGES; - 持久化配置需在
my.cnf的[mysqld]段添加：activate_all_roles_on_login=ON
角色嵌套不是自动继承，而是手动授权链
GRANT role_child TO role_parent 这条语句本身不触发任何权限叠加，它只是建立一个“可被授予”的关系。真正生效的前提是：该嵌套角色已被授予某个用户，且该用户激活了包含嵌套结构的父角色。
- 正确链式写法示例：
CREATE ROLE 'base_connect', 'app_reader', 'app_writer'; GRANT USAGE ON *.* TO 'base_connect';GRANT SELECT ON app_db.* TO 'app_reader';-
GRANT 'base_connect' TO 'app_reader';← 这步让app_reader获得连接能力 -
GRANT 'app_reader' TO 'app_writer';← 这步让app_writer继承读权限 GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_writer';
注意：app_writer 用户必须被授予 app_writer 角色（而非 app_reader），否则嵌套链不会触发。
SET DEFAULT ROLE 是嵌套生效的关键开关
即使角色嵌套定义完整、GRANT role_writer TO user_x 成功执行，用户登录后 CURRENT_ROLE() 仍返回 NULL——因为 MySQL 8.0 默认不激活任何角色。
- 管理员必须显式执行：
SET DEFAULT ROLE 'app_writer' TO 'user_x'@'%'; - 或一次性激活所有已授角色：
SET DEFAULT ROLE ALL TO 'user_x'@'%'; - 普通用户无法自行执行
SET DEFAULT ROLE，必须由具备ROLE_ADMIN权限者操作 - 激活后验证方式：
SELECT CURRENT_ROLE();返回非NULL值才算真正生效
嵌套层级不能无限递归，且权限不自动同步新对象
MySQL 8.0 允许角色 A → B → C 的线性嵌套，但不支持环形引用（如 A → B → A）或深度超过 64 层的链；更重要的是，角色权限只作用于当前已存在的数据库对象。
- 对
app_db.*授予SELECT后，后续新建的表默认可查；但若用精确对象授权（如GRANT SELECT ON app_db.t1 TO 'app_reader'），则新建表t2无权限 - 修改
app_reader的权限（如新增GRANT SELECT ON app_db.logs），所有绑定app_writer的用户下次激活角色时即生效——但前提是他们重新执行SET ROLE或建立新连接 - 删除父角色前，必须先
REVOKE role_a FROM role_b，否则DROP ROLE role_b会失败
最容易被忽略的一点：角色嵌套只影响权限集合，不改变权限粒度。比如 app_reader 有列级 SELECT(id,name)，嵌套进 app_writer 后，写权限仍需单独授予对应列，INSERT 不隐含 SELECT。
