mysql 8.0角色是解决权限维护成本的刚需工具，非语法糖；版本低于8.0.1不支持，8.0.1+需启用activate_all_roles_on_login并正确执行创建、授权、分配、激活四步。
MySQL 8.0 的角色（ROLE）不是“锦上添花”的语法糖，而是解决权限爆炸式维护成本的刚需工具；不用它，批量改权限、审计权限一致性、应对人员变动都会变成高风险手工操作。
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
真正容易出问题的地方不在语法，而在流程完整性：创建 → 授权 → 分配 → 激活，四步缺一不可；漏掉任何一步，CURRENT_ROLE() 都返回 NULL，权限实际不可用。
