MySQL 8.4 角色权限怎么查清继承链：CREATE ROLE、GRANT 与 CURRENT_ROLE

线上报表账号明明已经授予了角色，登录后却仍然拿到权限不足；先别急着给账号直接补一条 GRANT。MySQL 8.4 里，角色的“已授予”和“当前生效”是两件事，应该沿着 CREATE ROLE、GRANT、默认角色和 CURRENT_ROLE() 逐层核对。

最稳妥的排查顺序是：先看账号拿到了哪些角色，再用 SHOW GRANTS ... USING 展开角色权限，最后在实际会话里用 CURRENT_ROLE() 确认它是否真的激活。

先把“授予了角色”和“权限正在生效”分开

下面用三个账号对象说明关系：角色 app_read 持有报表库的查询权限，角色 app_write 持有写入权限，账号 report_user 只通过角色获得访问能力。

CREATE ROLE 'app_read'@'%';
CREATE ROLE 'app_write'@'%';
GRANT SELECT ON reporting.* TO 'app_read'@'%';
GRANT INSERT, UPDATE ON reporting.* TO 'app_write'@'%';
CREATE USER 'report_user'@'localhost' IDENTIFIED BY 'change_me';
GRANT 'app_read'@'%' TO 'report_user'@'localhost';
GRANT 'app_write'@'%' TO 'report_user'@'localhost';

这段 SQL 建立的是授权关系，不等于每次连接都自动使用两个角色。MySQL 8.4 默认不会因为 GRANT 角色就把它们全部激活，所以登录后的会话仍然可能没有报表表权限。

第一轮检查：SHOW GRANTS 先确认角色挂到了谁

管理员先在授权检查会话中执行：

SHOW GRANTS FOR 'report_user'@'localhost';
SHOW GRANTS FOR 'app_read'@'%';
SHOW GRANTS FOR 'app_write'@'%';

账号结果通常会列出两条角色授予语句，但这一步只回答“角色是否挂到账号上”。角色本身的结果才会告诉你它携带哪些数据库、表或动态权限。若这里没有 GRANT 'app_read'@'%'，先修正授权关系，别在会话里反复执行 SET ROLE。

需要把角色权限展开时，可以把已授予角色写到 USING 子句中：

SHOW GRANTS FOR 'report_user'@'localhost'
  USING 'app_read'@'%', 'app_write'@'%';

输出同时出现账号自身的 GRANT USAGE、角色授予和角色携带的 GRANT SELECT、GRANT INSERT 等内容时，授权链才算可读。MySQL 8.4 的文档特别提醒，普通的 SHOW GRANTS 不会替你展开角色。

第二轮检查：用 CURRENT_ROLE() 看当前连接到底启用了什么

切换到 report_user 的真实连接执行：

SELECT CURRENT_USER(), CURRENT_ROLE();
SELECT COUNT(*) AS visible_rows FROM reporting.daily_sales;

如果 CURRENT_ROLE() 返回 NONE，而查询报权限不足，现象就对上了：角色已经授予，但没有在当前会话激活。仅在测试连接里运行下面的语句，观察效果：

SET ROLE 'app_read'@'%';
SELECT CURRENT_ROLE();
SELECT COUNT(*) AS visible_rows FROM reporting.daily_sales;

成功时，CURRENT_ROLE() 会列出 app_read，并且查询可以通过；这能证明角色权限本身有效。若仍然失败，再回到 SHOW GRANTS FOR 'app_read'@'%' 检查对象范围、库名和账号连接的 host 部分。

把激活策略固定下来：默认角色和会话角色不要混写

如果每次登录都应该具备只读报表能力，可以为账号设置默认角色：

SET DEFAULT ROLE 'app_read'@'%' TO 'report_user'@'localhost';

重新建立连接后执行 SELECT CURRENT_ROLE()，应看到 app_read。这条语句改变的是账号默认配置，后续登录会使用它；而 SET ROLE DEFAULT 是当前连接恢复默认角色的动作，两者名字相似，作用范围不同。

需要临时扩大权限时，使用会话级语句，并在任务结束后恢复：

SET ROLE 'app_read'@'%', 'app_write'@'%';
-- 完成一次受控写入后
SET ROLE DEFAULT;

也可以用 SET ROLE NONE 做反向验证：如果角色被全部关闭后查询立刻失败，说明权限确实来自角色；如果仍能查询，就要继续查账号直授权限或 mandatory roles。生产环境不建议为了省事打开全局的 activate_all_roles_on_login，除非你已经评估过所有账号的角色集合。

四个容易误判的权限现场

相关问题

为什么 SHOW GRANTS 看不到角色里的 SELECT？

因为普通调用主要展示账号的直接授权和角色授予关系。用 USING 指定角色后，才会把这些角色代表的权限一起列出。

SET DEFAULT ROLE 会立即改变当前连接吗？

它设置登录默认值；当前连接需要执行 SET ROLE DEFAULT 或重新连接后，才能按新的默认角色激活。

CURRENT_ROLE() 返回 NONE 就是没有角色吗？

不是。它只说明当前会话没有激活角色，仍需用 SHOW GRANTS FOR 判断角色是否已授予。

为什么应用账号和命令行账号结果不同？

MySQL 账号由用户名和 host 共同确定。请在应用连接中同时检查 CURRENT_USER()、CURRENT_ROLE()，不要只对比登录用户名。

收尾检查清单

一次角色权限排查至少留下三份证据：账号的 SHOW GRANTS、角色的展开结果，以及应用真实连接里的 CURRENT_ROLE()。三者能对上，再去调整默认角色；否则直接给账号补权限，往往只是把真正的激活问题藏得更深。