MySQL 8.0+原生支持RBAC但默认不启用，角色需显式创建、授权、授予用户并激活（SET DEFAULT ROLE或SET ROLE），否则权限不生效；SHOW GRANTS不显示角色继承权限，须用USING子句查看。
MySQL 8.0+ 原生支持基于角色的权限管理（RBAC），但默认不启用，且角色行为与传统用户权限有关键差异：角色本身不能登录，必须被显式授予并激活才能生效，SET ROLE 或 SET DEFAULT ROLE 是绕不开的操作环节。
如何创建角色并分配权限
角色本质是权限容器，需用 CREATE ROLE 显式声明，再用 GRANT 绑定具体权限。注意：角色名需带引号（如含特殊字符）或使用反引号（如为保留字），且不能与现有用户名冲突。
CREATE ROLE 'app_reader'; GRANT SELECT ON mydb.* TO 'app_reader'; CREATE ROLE 'app_writer'; GRANT SELECT, INSERT, UPDATE ON mydb.* TO 'app_writer';
- 角色权限可跨库、跨表粒度控制，但不支持列级权限（如
GRANT SELECT(col1) ON ...在角色上无效） -
GRANT到角色时不能加WITH GRANT OPTION—— 角色无法传递权限给其他用户或角色 - 执行需有
CREATE ROLE和对应GRANT OPTION权限，普通 DBA 用户可能无权创建角色
如何将角色授予用户并激活
用户获得角色后，默认不自动启用；必须用 SET ROLE 或提前设置默认角色，否则即使已 GRANT，查询仍报 Access denied。
CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd123'; GRANT 'app_reader' TO 'api_user'@'%'; SET DEFAULT ROLE 'app_reader' TO 'api_user'@'%';
-
GRANT 'role_name' TO 'user'@'host'只是绑定关系，不激活 -
SET DEFAULT ROLE让用户每次连接自动启用指定角色（推荐生产环境使用） - 若未设默认角色，应用需在连接后立即执行
SET ROLE 'app_reader'，否则权限不生效 - 一个用户可被授予多个角色，
SET DEFAULT ROLE ALL可激活全部，但需谨慎——可能违反最小权限原则
为什么 SHOW GRANTS 看不到角色权限
SHOW GRANTS FOR 'user'@'host' 默认只显示直接授予用户的权限，不展开角色继承的权限，容易误判权限是否生效。
- 查角色实际生效权限，要用
SHOW GRANTS FOR 'user'@'host' USING 'role_name' - 查用户当前会话激活的角色，执行
SELECT CURRENT_ROLE();—— 返回NONE表示没激活任何角色 - 权限检查是运行时行为：即使角色已授、默认已设，若连接时未带
mysql --default-auth=mysql_native_password（旧客户端兼容问题），也可能导致角色不加载
常见权限失效场景与排查点
最常踩的坑不是权限没给，而是角色没激活、连接协议不兼容、或权限缓存未刷新。
- 修改角色权限后，已连接用户不会自动更新，需重新连接或执行
FLUSH PRIVILEGES（MySQL 8.0.16+ 多数情况无需，但角色变更后建议执行） - 使用 MySQL Connector/J 8.0+ 时，需在 JDBC URL 加
&allowPublicKeyRetrieval=true&useSSL=false，否则部分认证插件下角色可能不加载 - 通过代理（如 ProxySQL）连接时，代理可能剥离
SET DEFAULT ROLE请求，需确认其是否透传初始化命令 -
DROP ROLE会立即撤销所有绑定用户的该角色权限，但不会报错提示哪些用户受影响 —— 操作前务必SELECT * FROM mysql.role_edges;检查依赖关系
角色不是“开箱即用”的权限开关，它把权限分层管理的复杂性暴露给了运维和开发：谁创建角色、谁授权角色、谁激活角色、谁审计角色变更，每个环节都可能断链。真正落地时，SET DEFAULT ROLE 的配置时机和客户端兼容性，比设计角色体系本身更值得花时间验证。
