MySQL 8.0+ 角色创建与激活必须显式启用
MySQL 5.7 不支持角色，只有 8.0 及以上版本才原生支持
CREATE ROLE。但即使版本达标，
mysql系统库中默认不启用角色功能——必须确认
activate_all_roles_on_login变量是否为
ON，否则用户登录后不会自动激活已授予的角色。 检查当前设置：
SELECT @@activate_all_roles_on_login;临时启用（重启失效）：
SET GLOBAL activate_all_roles_on_login = ON;永久生效需在
my.cnf中添加：
activate_all_roles_on_login = ON若未启用，用户需手动执行
SET ROLE 'role_name';才能获得权限，否则
SHOW GRANTS;不显示角色赋予的权限
GRANT 语句对角色和用户的语法差异
给角色赋权和给用户赋权看似一样，但行为不同：角色本身不登录，只作为权限容器；而用户可登录，且可被授予多个角色。关键区别在于
WITH ADMIN OPTION的传播能力。 创建角色并授权：
CREATE ROLE 'app_reader';<br>GRANT SELECT ON `orders`.* TO 'app_reader';把角色授给用户（不是
GRANT ... TO user@host那种直接权限）：
GRANT 'app_reader' TO 'webapp'@'%';若希望该用户还能把
app_reader授给别人，必须加
WITH ADMIN OPTION：
GRANT 'app_reader' TO 'webapp'@'%' WITH ADMIN OPTION;注意：
WITH GRANT OPTION是用于普通权限（如
SELECT），而
WITH ADMIN OPTION才用于角色授权的传递
角色嵌套与循环引用会直接报错
MySQL 允许角色 A 授予角色 B，B 再授予角色 C，形成层级；但绝不允许出现循环，比如 A → B → A。一旦发生，
GRANT会立即失败，并提示
ER_ROLE_GRANTED_TO_ITSELF或类似错误。 常见误操作：
CREATE ROLE 'dev_team';<br>CREATE ROLE 'backend_team';<br>GRANT 'dev_team' TO 'backend_team';<br>GRANT 'backend_team' TO 'dev_team'; -- ❌ 报错检查现有角色继承关系：
SELECT * FROM mysql.role_edges;解除嵌套用：
REVOKE 'dev_team' FROM 'backend_team';角色嵌套深度无硬性限制，但超过 3 层后权限溯源会变困难，建议用
SHOW GRANTS FOR 'user'@'host' USING 'role1', 'role2';显式验证
权限回收时 REVOKE 不会级联删除角色
REVOKE某个角色对用户的授权，只断开绑定关系，不会删除角色本身，也不会影响其他用户对该角色的持有。但若误用
DROP ROLE，所有依赖它的用户将瞬间失去对应权限，且无法回滚。 安全做法是先查谁用了该角色：
SELECT FROM_HOST, FROM_USER FROM mysql.role_edges WHERE TO_HOST='%' AND TO_USER='app_writer';再逐个撤销：
REVOKE 'app_writer' FROM 'api_worker'@'10.0.2.%';确认无绑定后再删角色：
DROP ROLE 'app_writer';特别注意：
REVOKE ALL PRIVILEGES对角色无效，只能针对具体权限或角色名操作；对用户执行该语句也不会清除其被授予的角色
角色机制本身不复杂，真正容易出问题的是权限叠加后的实际效果——比如一个用户同时拥有
SELECT和
INSERT角色，又单独被
REVOKE INSERT，这时候得靠
SHOW GRANTS FOR 'u'@'h'看最终合并结果，而不是只信某一条
GRANT语句。
