MySQL 8.0+ 的 ROLE 是权限模板的实际落地方式，通过创建角色、授予权限、分配给用户三步实现批量权限管理，需注意权限生效机制、跨库语法、角色嵌套限制等细节。
MySQL 8.0+ 的 ROLE 是权限模板的实际落地方式
MySQL 原生不支持“权限模板”这个概念，但 ROLE（角色）从 8.0.1 开始正式可用，它就是最贴近权限模板的机制：把一组 GRANT 权限打包命名，后续可批量授予/回收，避免重复执行多条 GRANT 语句。
注意：MySQL 5.7 及更早版本没有 ROLE，只能靠脚本或外部工具模拟，不推荐在生产环境手动维护权限 SQL 列表。
创建和使用 ROLE 的标准流程
角色本身是数据库对象，需显式创建，再授予权限，最后分配给用户。三步缺一不可，漏掉 FLUSH PRIVILEGES 或未启用 activate_all_roles_on_login 可能导致权限不生效。
CREATE ROLE 'app_reader';GRANT SELECT ON mydb.* TO 'app_reader';-
GRANT USAGE ON *.* TO 'app_reader';（可选，用于允许连接但无实际权限） CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd123';GRANT 'app_reader' TO 'api_user'@'%';- 用户首次登录后需执行
SET ROLE 'app_reader';，或配置全局自动激活：SET PERSIST activate_all_roles_on_login = ON;
常见权限错配场景与修复建议
角色权限不会自动继承到新创建的表或库，比如对 mydb.* 授予 SELECT 后，后续新建的表默认可查；但若用 mydb.table_x 精确授权，则新表无权限。这点和直接授给用户的权限行为一致，不是角色特有缺陷。
- 误以为
DROP ROLE会自动回收已授出的权限 → 实际上需先REVOKE 'role_name' FROM user@host，再删角色 - 跨库权限写成
GRANT SELECT ON *.table_name→ 语法错误，必须指定库名，如GRANT SELECT ON mydb.* - 使用
SHOW GRANTS FOR 'user'@'%'查不到角色权限 → 需加FOR 'user'@'%' USING 'role_name'或直接查SHOW GRANTS FOR 'user'@'%' USING 'app_reader'; - 角色被授予了
CREATE VIEW但用户仍无法创建 → 检查是否遗漏SELECT权限（创建视图要求对源表有SELECT）
权限变更后如何确保立即生效
MySQL 的权限缓存机制意味着：即使 GRANT/REVOKE 执行成功，当前已连接的会话仍沿用旧权限。只有新连接或主动刷新才会更新。
- 对单个用户重载权限：
FLUSH PRIVILEGES;（全局生效，但不强制刷新活跃会话） - 让当前会话立即应用新角色：
SET ROLE 'app_reader'; - 强制所有活跃会话重新认证（不常用）：
KILL CONNECTION [id];
（需SUPER或CONNECTION_ADMIN权限） - 生产环境推荐做法：权限变更后，通知应用侧重启连接池，而非依赖
FLUSH PRIVILEGES
真正容易被忽略的是角色嵌套限制：MySQL 不支持角色 A 授予角色 B（即不能 GRANT role_b TO role_a），所有角色必须平级管理。如果需要分层权限模型，得靠应用层组合多个角色或改用外部权限系统。
