MySQL 8.0角色功能需完成创建、授权、激活三步才生效，缺一即报ERROR 1142；ERROR 1064或3719源于版本低于8.0.1、activate_all_roles_on_login未开启、缺少ROLE_ADMIN权限或误用反引号。
MySQL 8.0 的 Role 功能不是“建完就生效”，必须完成创建、授权、激活三步，漏掉任一环节，用户执行 SELECT 仍会报 ERROR 1142。
CREATE ROLE 报 ERROR 1064 或 ERROR 3719 怎么办
这不是语法写错，而是卡在版本或配置上：
- 先跑
SELECT VERSION();——输出必须是8.0.1或更高；5.7.x或8.0.0直接不支持CREATE ROLE - 检查全局变量：
SELECT @@activate_all_roles_on_login;必须返回ON，否则建成功也会报ERROR 3719 - 确认当前用户有
ROLE_ADMIN权限：SHOW GRANTS;里得包含GRANT ROLE_ADMIN ON *.*，否则连GRANT 'role_x' TO 'user'都被拒绝 - 角色名别用反引号：
CREATE ROLE `app_reader`是错的，应写成CREATE ROLE 'app_reader'或CREATE ROLE app_reader
GRANT 了角色，用户还是没权限
GRANT 'app_reader' TO 'user1'@'%' 只建立绑定关系，不触发权限加载。用户登录后 CURRENT_ROLE() 返回 NONE 就是铁证。
- 必须显式执行：
SET DEFAULT ROLE 'app_reader' TO 'user1'@'%'; - 连接池（如 HikariCP）需额外配置：
sessionVariables=default_role=app_reader或connection-init-sql="SET DEFAULT ROLE 'app_reader'" - 用户有多个角色时，
SET DEFAULT ROLE ALL TO虽方便，但违反最小权限原则，生产环境慎用
SHOW GRANTS 看不到角色权限，是不是没授成功
不是失败，是设计如此。SHOW GRANTS FOR 'user'@'%' 只显示直接授予用户的权限（比如 USAGE），完全不展开角色继承的权限。
- 查角色内具体权限：
SHOW GRANTS FOR 'app_reader'; - 查某用户通过某角色获得的权限：
SHOW GRANTS FOR 'user1'@'%' USING 'app_reader'; - 验证当前会话是否生效：登录后执行
SELECT CURRENT_ROLE();，返回非NONE才算真正激活 - 审计时如果只扫
SHOW GRANTS输出，可能把拥有 DBA 权限的账号当成“仅能连接”，风险极大
权限变更后已连着的会话查不到新表
MySQL 不刷新已有连接的权限缓存。哪怕你刚执行 GRANT SELECT ON new_table TO 'app_reader'，已连着的会话仍查不到该表。
- 要么重连，要么在当前会话手动执行
SET ROLE 'app_reader';强制重载 - 角色嵌套（如
GRANT r2 TO r1）也一样：权限链定义完不等于自动生效，必须确保用户被授予的是父角色，且已设为默认角色 - 真正容易被忽略的是：角色名区分大小写，
'Analyst'和'analyst'是两个不同角色；FLUSH PRIVILEGES在角色权限变更后建议执行一次，尤其在批量操作后
