MySQL 8.0角色功能需严格按创建→授权→分配→激活四步执行，缺一不可；版本≥8.0.1、activate_all_roles_on_login=ON、mysql.role_edges存在是前提，否则角色不可用。
MySQL 8.0 的角色功能本身不支持“开箱即用”的批量权限管理，必须显式走完创建→授权→分配→激活四步，漏掉任何一步，CURRENT_ROLE() 就返回 NULL，权限实际不可用。
确认 MySQL 版本和角色系统是否真正就绪
执行 SELECT VERSION();，结果必须是 8.0.1 或更高；低于该版本的 CREATE ROLE 会直接报 ERROR 1064（语法错误实为功能缺失）。接着验证角色系统是否启用：
- 运行
SHOW VARIABLES LIKE 'activate_all_roles_on_login';，值必须为ON，否则用户登录后不会自动激活角色 - 运行
SELECT 1 FROM mysql.role_edges LIMIT 1;，若报错Table 'mysql.role_edges' doesn't exist，说明实例未启用角色支持（常见于精简版或旧配置） - 若上述任一检查失败，需由高权限用户执行：
SET GLOBAL activate_all_roles_on_login = ON;和GRANT ROLE_ADMIN ON *.* TO 'admin_user'@'%';，再执行FLUSH PRIVILEGES;
创建角色并授予最小必要权限
角色名必须带单引号且显式指定主机，例如 'app_reader'@'%'；省略主机等价于 @'%'，但后续分配时若用户主机不匹配（如 'u1'@'10.20.%'），就会静默失败。
- 权限粒度要精确：用
GRANT SELECT ON mydb.* TO 'app_reader'@'%';，不能写成GRANT SELECT ON *.table_name（非法语法） - 禁止对系统库误授权：
REVOKE ALL PRIVILEGES ON mysql.* FROM 'app_reader'@'%';应作为标准步骤 - 不要加
WITH GRANT OPTION，避免权限被二次扩散 - 执行完立即
FLUSH PRIVILEGES;——角色权限变更后必须刷新，否则新用户无法继承
批量分配角色并确保权限真正生效
GRANT 'app_reader'@'%' TO 'u1'@'10.20.%', 'u2'@'10.20.%'; 这条语句只完成“挂载”，不等于“激活”。用户登录后仍需手动 SET ROLE 或依赖默认角色机制。
- 目标用户必须已存在，否则该语句静默跳过（无报错但不生效）
- 所有用户主机部分必须完全一致，
'u1'@'%'和'u2'@'localhost'无法同批处理 - 必须额外执行
ALTER USER 'u1'@'10.20.%' DEFAULT ROLE 'app_reader'@'%';，否则CURRENT_ROLE()始终为空 - 若想全局启用自动激活，需
SET PERSIST activate_all_roles_on_login = ON;并写入my.cnf持久化
验证权限是否落地而不是“看起来有”
别只看 SHOW GRANTS FOR 'u1'@'10.20.%'; 输出里有没有 GRANT 'app_reader'@'%' —— 这只是绑定记录。真正关键的是运行时状态：
- 用目标用户连接后执行
SELECT CURRENT_ROLE();，应返回'app_reader'@'%'，不是NULL或空字符串 - 执行
SHOW DATABASES;确认目标库可见；执行SELECT * FROM mydb.t LIMIT 1;验证具体操作权限 - 若权限改了但老连接没反应，不是 bug，是设计如此：已有连接权限缓存不变，必须重连或显式
SET ROLE 'app_reader'@'%';
最容易被忽略的点是：角色权限变更后，FLUSH PRIVILEGES 不会刷新已存在连接的权限上下文；而设 DEFAULT ROLE 前，必须确保该角色已被 GRANT 过具体权限——顺序颠倒，整套流程就卡死在“挂载成功但不可用”状态。
