MySQL 8.0 角色功能需按三步启用：开启 activate_all_roles_on_login、授予 ROLE_ADMIN 权限、执行 FLUSH PRIVILEGES；角色默认不激活，须 SET ROLE 或设 DEFAULT ROLE；权限变更不影响已有连接，需手动 SET ROLE 加载。
MySQL 8.0 的 ROLE 本身不省事，省事的前提是你按对了三步顺序、开了关键开关、并且理解权限不会自动“活过来”——否则反而比直接 GRANT 用户更难排查。
CREATE ROLE 报错 ERROR 3719 或权限不足
这不是语法问题，是 MySQL 默认关掉了角色功能。即使你用的是 8.0.1+，CREATE ROLE 也会失败，除非先执行：
-
SET GLOBAL activate_all_roles_on_login = ON（会话级设置，重启失效） -
GRANT ROLE_ADMIN ON *.* TO 'admin_user'@'%'（必须显式授予该权限） -
FLUSH PRIVILEGES（必须，否则后续所有角色操作都卡住）
漏掉任意一条，CREATE ROLE 'app_reader'@'%' 就会报 ERROR 3719 (HY000): 'role_admin'@'%' is not set as a role 或类似提示。持久化需写入 my.cnf：activate_all_roles_on_login=ON。
用户授了角色却查不到数据，CURRENT_ROLE() 返回 NONE
角色不是登录即生效的“默认权限”，它只是被挂载到用户身上，但处于 inactive 状态。常见表现：
-
SHOW GRANTS FOR 'user1'@'%'只显示GRANT `app_reader`@`%` TO `user1`@`%`，不展开具体权限 -
SELECT CURRENT_ROLE()返回NONE -
SHOW DATABASES只看到information_schema，目标库不可见
解决方法只有两个路径之一：
- 用户登录后手动执行：
SET ROLE 'app_reader'@'%' - 或由管理员提前设默认角色：
ALTER USER 'user1'@'%' DEFAULT ROLE 'app_reader'@'%'（注意：该语句执行前，'app_reader'@'%'必须已被GRANT过权限，且执行者有ROLE_ADMIN）
权限改了，老连接还是旧权限
MySQL 权限变更不热生效。即使你刚执行了 GRANT SELECT ON mydb.* TO 'app_reader'@'%' 并 FLUSH PRIVILEGES，已存在的连接仍看不到新表、新字段。这是因为权限缓存在会话层。
- 对新连接：只要角色已设为默认，或用户主动
SET ROLE，就立即生效 - 对当前活跃会话：必须显式
SET ROLE 'app_reader'@'%'才能加载最新权限 - 不能靠
FLUSH PRIVILEGES强制刷新已有连接的权限上下文
这点和直接授给用户的权限行为一致，但角色场景下更容易误以为“改完角色就全局更新了”。
跨库授权、嵌套角色、新建对象权限的盲区
角色不是魔法容器，它遵循和用户完全一致的权限作用域规则：
-
GRANT SELECT ON mydb.*对后续新建的表有效；但GRANT SELECT ON mydb.t1不会覆盖t2 - MySQL 不支持角色嵌套（
GRANT r2 TO r1是非法语法），想复用权限只能靠多授 -
GRANT CREATE VIEW给角色，但用户仍创建失败？大概率缺了源表的SELECT权限——角色不自动补全依赖权限 -
SHOW GRANTS FOR 'user'@'%'查不到角色内具体权限，得用：SHOW GRANTS FOR 'user'@'%' USING 'app_reader'@'%'
真正省事的地方只有一个：当你需要批量调整几十个用户的某类权限时，改一次角色、不用遍历每个用户执行 GRANT/REVOKE。其余所有环节，该填的坑一个没少。
