MySQL CURRENT_ROLE 怎样查看当前会话真正启用的角色

排查 MySQL 权限时，最容易混淆的是“账号被授予了什么”和“这条连接此刻启用了什么”。要看当前会话真正生效的角色，先执行 SELECT CURRENT_ROLE();：返回逗号分隔的活动角色，若返回 NONE，只说明当前会话没有活动角色，不等于账号从未被授予角色。

官方参考地址：https://dev.mysql.com/doc/refman/8.4/en/information-functions.html

先用 CURRENT_ROLE 看会话正在使用什么

在同一条连接中执行下面的查询。不要在客户端窗口之间切换后再对比，因为角色激活是会话级状态。

-- 只观察当前连接真正活动的角色
SELECT CURRENT_ROLE();

-- 同时记录认证账号，避免把登录名当成活动角色
SELECT CURRENT_USER(), CURRENT_ROLE();

官方定义中，结果是一个 utf8mb3 字符串，多个活动角色用逗号分隔；没有活动角色时返回 NONE。因此，看到 NONE 后应继续查授权关系，而不是立刻给账号追加权限。

SHOW GRANTS 负责回答“授予过什么”

当 CURRENT_ROLE() 与预期不一致时，用 SHOW GRANTS 查看账号的授予关系。下面的账号名只是示例，生产环境替换成实际连接账号：

-- 查看账号本身及其角色授予关系
SHOW GRANTS FOR 'app_user'@'localhost';

-- 用 USING 展开指定角色带来的权限，便于核对有效授权
SHOW GRANTS FOR 'app_user'@'localhost'
  USING 'app_read'@'%';

角色可以已授予但未激活。MySQL 手册给出的判断边界是：活动角色的权限才会在该会话中生效，授予关系本身不代表当前连接已经启用它。可以把结果按下面的表格拆开：

SET ROLE 改的是当前连接

确认账号确实拥有目标角色后，可以在当前会话临时切换。下面三种写法分别表示清空、恢复默认和只启用一个角色；每次切换后都立即复查。

-- 临时关闭当前会话的全部角色
SET ROLE NONE;
SELECT CURRENT_ROLE();

-- 恢复该账号配置的默认角色
SET ROLE DEFAULT;
SELECT CURRENT_ROLE();

-- 只启用已授予的读角色，缩小本次会话权限
SET ROLE 'app_read';
SELECT CURRENT_ROLE();

这几条语句不会替其他连接修改角色。尤其在连接池场景中，连接归还池子后可能保留上一次调用的活动集合；应用应在借出连接时执行固定的初始化策略，或明确禁止在同一连接中混用不同权限上下文。

登录默认值与生产检查清单

如果目标是让账号每次登录都自动启用指定角色，应由管理员配置默认角色，而不是把一条 SET ROLE 只放在某个临时客户端里：

-- 让账号登录后默认启用已授予的全部角色
SET DEFAULT ROLE ALL TO 'app_user'@'localhost';

-- 变更后在新连接中复查初始状态
SELECT CURRENT_ROLE();

MySQL 还提供 activate_all_roles_on_login，用于让显式授予和强制角色在登录时自动激活。采用哪一种方式要和权限基线一致：默认角色适合精确控制，自动激活适合角色集合稳定且有统一治理的环境。无论采用哪种配置，都不要用旧连接的结果代替新连接验证。

• 发布前：记录应用账号、授予角色、默认角色和预期的 CURRENT_ROLE()。
• 连接初始化：明确执行 SET ROLE DEFAULT 或固定角色集合，并记录失败处理。
• 变更后：分别在新连接和已复用连接中检查，确认没有残留的活动角色。

常见问题

账号有角色但 CURRENT_ROLE() 返回 NONE，正常吗？

正常。角色可以已授予但未激活；先用 SHOW GRANTS 核对，再用 SET ROLE 或默认角色配置决定激活方式。

SET DEFAULT ROLE 会立刻改变正在使用的连接吗？

它面向后续登录的初始状态。当前连接要立即改变，应执行 SET ROLE 并再次查询 CURRENT_ROLE()。

为什么应用账号与 CURRENT_ROLE() 不是同一个名字？

账号是认证主体，角色是权限集合；一个账号可以拥有多个角色，也可以在当前会话只激活其中一部分。