MySQL 8.0角色权限必须完成创建→授权→分配→激活四步闭环，缺一不可；漏步则CURRENT_ROLE()返回NULL，权限不生效。
MySQL 8.0 的角色功能不是“配完就生效”的开关，而是必须走完四步闭环：创建 → 授权 → 分配 → 激活；漏掉任意一步，CURRENT_ROLE() 返回 NULL，所有权限实际不可用。
CREATE ROLE 报错 ERROR 1064 或 ERROR 3719 怎么办
这基本说明你卡在版本或前置配置上。先执行 SELECT VERSION();，如果返回值低于 8.0.1，角色功能根本不存在，硬写 CREATE ROLE 必报 ERROR 1064。5.7 及更早版本只能逐个 GRANT 用户，没有角色抽象层。
如果是 8.0.1+ 却报 ERROR 3719 (HY000): 'role_admin'@'%' is not set as a role，说明角色功能被禁用。必须由 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 权限给角色后用户仍报 ERROR 1142 怎么排查
常见错误是以为“授了权就等于能用”。实际上，GRANT SELECT ON app.* TO 'app_reader'; 只是把权限塞进角色容器里，它还没和任何用户产生关系。
必须补全后续两步：
-
GRANT 'app_reader' TO 'api_user'@'%';（绑定角色到用户） -
SET DEFAULT ROLE 'app_reader' TO 'api_user'@'%';（激活，否则登录后CURRENT_ROLE()仍是NULL）
注意：SHOW GRANTS FOR 'api_user'@'%'; 默认不显示角色权限——这是正常行为。要查真实权限，得用：SHOW GRANTS FOR 'api_user'@'%' USING 'app_reader';。
批量更新几百个用户的权限，为什么不能只改用户而要改角色
因为“改角色”才是 MySQL 8.0 批量权限管理的设计原意。你执行一次 GRANT SELECT ON finance.* TO 'report_reader';，所有已绑定该角色的用户，下次新建连接或手动 SET ROLE 'report_reader'; 就立刻获得新权限。
反过来说，如果绕开角色、对每个用户单独 GRANT，不仅操作繁琐，还极易出现遗漏或不一致。更危险的是：REVOKE INSERT ON app_db.* FROM 'dev_user'@'%'; 只影响该用户的直授权限，对角色定义毫无影响——你以为收了权限，其实别人照旧能用。
所以生产环境推荐流程是：
- 角色名统一带主机名，如
'report_reader'@'%'，避免匹配歧义 - 批量绑定用户支持逗号语法：
GRANT 'report_reader' TO 'u1'@'%', 'u2'@'%', 'u3'@'%'; - 权限变更后，依赖
activate_all_roles_on_login=ON让新连接自动生效，旧连接需重连或手动SET ROLE
真正容易被忽略的点在于：角色权限不会自动延伸到未来新建的数据库。比如之后建了 archive_db，必须显式补一句 GRANT SELECT ON archive_db.* TO 'report_reader';，否则用户查不到。
