MySQL 8.0角色权限生效必须严格遵循「创建→授权→分配→激活」四步，缺一不可；否则CURRENT_ROLE()返回NULL，权限不生效，且角色名host必须全程精确匹配。
MySQL 8.0 的角色功能能简化权限管理，但必须按「创建 → 授权 → 分配 → 激活」四步走；漏任一步，CURRENT_ROLE() 返回 NULL，权限实际不生效。
CREATE ROLE 报错 ERROR 1064 或 ERROR 3719 怎么办
这通常不是语法写错，而是根本没启用角色支持或权限不足。
- 先确认版本：
SELECT VERSION();—— 必须是8.0.x或更高，否则CREATE ROLE直接语法报错ERROR 1064 - 即使版本正确，
activate_all_roles_on_login默认为OFF，会导致CREATE ROLE报ERROR 3719（提示 role_admin 未设置） - 必须由高权限账号（如
root）执行：SET GLOBAL activate_all_roles_on_login = ON;，再GRANT ROLE_ADMIN ON *.* TO 'admin_user'@'%'; - 该变量重启失效，生产环境务必写入
my.cnf：[mysqld]<br>activate_all_roles_on_login=ON
GRANT 权限给角色后，用户还是 SELECT 失败
因为 GRANT 'app_reader' TO 'user1'@'%' 只是绑定关系，不等于激活——角色权限不会自动生效。
- 角色本身是空壳：
CREATE ROLE 'app_reader'后不GRANT SELECT ON myapp.* TO 'app_reader'，它连SELECT都没有 - 分配角色 ≠ 启用角色：
SHOW GRANTS FOR 'user1'@'%'永远只显示GRANT 'app_reader' TO，不会展开角色内的具体权限 - 必须显式激活：
SET DEFAULT ROLE 'app_reader' TO 'user1'@'%'，否则用户登录后CURRENT_ROLE()仍为NULL - 连接池场景（如 HikariCP）需额外配置：
connection-init-sql="SET DEFAULT ROLE 'app_reader'"或sessionVariables=default_role=app_reader
如何验证角色是否真正生效
别信 SHOW GRANTS，也别只看语句有没有报错——最直接的验证方式是用目标用户登录后执行 CURRENT_ROLE()。
-
CURRENT_ROLE()返回非NULL（如'app_reader'@'%'）才表示角色已激活 - 若返回
NULL，大概率卡在SET DEFAULT ROLE没执行，或activate_all_roles_on_login仍为OFF - 查角色自身权限用：
SHOW GRANTS FOR 'app_reader'@'%'；查某用户通过角色获得的权限用：SHOW GRANTS FOR 'user1'@'%' USING 'app_reader' - 注意：角色不支持列级授权（
GRANT SELECT(id,name) ON t TO 'r'报ERROR 1142），也不支持WITH GRANT OPTION
最容易被忽略的是：角色名带主机名（如 'app_reader'@'%'）必须前后一致，创建、授权、分配、激活四个环节里主机名不匹配，就会静默失败。还有就是 FLUSH PRIVILEGES 虽在 8.0+ 不强制要求，但在角色权限变更后执行一次，能避免部分缓存导致的延迟生效问题。
