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），所有角色必须平级管理。如果需要分层权限模型，得靠应用层组合多个角色或改用外部权限系统。
