MySQL 8.0角色权限需完成启用、创建、授权、绑定+激活四步闭环，缺一即CURRENT_ROLE()返回NULL；版本低于8.0.1不支持角色，ERROR 3719需开启activate_all_roles_on_login并赋ROLE_ADMIN权限，GRANT分授角色权限与授角色给用户两步不可合并，SET DEFAULT ROLE是激活临门一脚。
MySQL 8.0 的角色权限不会自动生效，必须完成“启用→创建→授权→绑定+激活”四步闭环，漏掉任意一环，CURRENT_ROLE() 就返回 NULL，用户照样 Access denied。
CREATE ROLE 报错 ERROR 3719 或 ERROR 1064 怎么办
这不是语法写错了，而是环境没准备好。
-
ERROR 1064：说明 MySQL 版本低于 8.0.1，角色功能压根不支持。运行SELECT VERSION();确认，若输出是5.7.32这类，别折腾角色，老实用GRANT SELECT ON db.* TO 'u'@'%'; -
ERROR 3719（提示'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 - 角色名必须用单引号，如
'app_reader'；写成`app_reader`或"app_reader"可能触发语法错误
GRANT 权限给角色 vs GRANT 角色给用户，两步不能跳
很多人以为“建了角色、授了权、再把角色给用户”，权限就自动有了——其实这是两个完全独立的动作，顺序不能反，缺一不可。
- 第一步（填充角色）：
GRANT SELECT, INSERT ON myapp.* TO 'app_writer'@'%';—— 权限是授给角色本身的，不是授给用户 - 第二步（绑定用户）：
GRANT 'app_writer'@'%' TO 'dev_user'@'10.20.%';—— 这只是在mysql.role_edges表里加一条记录，用户登录后仍无权限 - 常见错误：省略主机名，比如写成
GRANT SELECT ON db.* TO 'app_reader'，等价于'app_reader'@'%'，但后续对'dev_user'@'localhost'执行GRANT 'app_reader' TO ...会因 host 不匹配失败 - 角色不支持列级授权：
GRANT SELECT(id) ON t1 TO 'r'直接报ERROR 1142 - 角色不支持
WITH GRANT OPTION，但可用WITH ADMIN OPTION控制角色能否被再授予他人
SET DEFAULT ROLE 是权限生效的临门一脚
执行完前两步后用户仍被拒？SELECT CURRENT_ROLE(); 返回 NULL？问题几乎一定出在这步没做。
- 显式激活默认角色：
SET DEFAULT ROLE 'app_reader'@'%' TO 'dev_user'@'10.20.%';—— 注意 host 必须严格匹配，'dev_user'@'%'不能对'dev_user'@'localhost'设默认角色 - 也可用
ALTER USER 'dev_user'@'10.20.%' DEFAULT ROLE 'app_reader'@'%';，但前提是该用户已存在且已有USAGE权限 -
SET DEFAULT ROLE需要SYSTEM_VARIABLES_ADMIN或APPLICATION_PASSWORD_ADMIN权限，普通用户无法自行执行 -
SET DEFAULT ROLE ALL TO ...会激活所有已授予角色，违背最小权限原则，慎用 - 验证是否真正生效：
SHOW GRANTS FOR 'dev_user'@'10.20.%' USING 'app_reader';查角色带来的真实权限；SELECT CURRENT_ROLE();返回非NULL值才算成功
最容易被忽略的断点是：SHOW GRANTS FOR 'user'@'%' 默认只显示直授权限，不会展开角色继承链——这不是配置失败，而是设计行为。别靠它判断角色是否生效，得用 USING 子句或查 CURRENT_ROLE()。
