current_role() 返回空字符串是因为当前会话未显式激活任何角色;必须先执行 set role role_name; 才能使其返回对应角色名,该函数仅反映当前活跃角色而非已授予角色列表。

MySQL 8.0+ 中 CURRENT_ROLE() 返回空字符串的常见原因
直接执行 SELECT CURRENT_ROLE(); 却返回空字符串(''),不是函数坏了,而是当前 SESSION 没有被显式激活任何角色。MySQL 的角色默认是“授予但不启用”的——就像发了门禁卡,但没按电梯楼层按钮。
- 角色必须先用
SET ROLE role_name;或SET ROLE DEFAULT;显式激活,CURRENT_ROLE()才会显示它 - 即使用户被
GRANT role_name TO 'u'@'%';过,也不代表该角色自动生效 -
CURRENT_ROLE()只反映当前活跃角色,不是“所有已授角色”的列表
查当前 SESSION 的全部有效角色(含未激活的)要用 ACTIVE_ROLES()?错,得用系统表
MySQL 没有 ACTIVE_ROLES() 函数。想看到“当前用户在本 session 中**可能激活**的角色”,需查 information_schema.APPLICABLE_ROLES;想看“当前 session **实际生效**了哪些”,得结合 performance_schema.threads 和权限上下文——但最实用的是:
SELECT * FROM information_schema.APPLICABLE_ROLES
WHERE IS_GRANTABLE = 'YES' AND GRANTEE = CONCAT('''', USER(), '''@''', SUBSTRING_INDEX(USER(), '@', -1), '''');
注意:APPLICABLE_ROLES 列出的是该用户**有权限切换到的角色**(即被显式 GRANT 且未被 REVOKE 的),不是当前激活态。
抓取并分析 OpenClaw JSONL 会话日志,重建并回填代理记忆文件。适用于:(1) 模型切换后记忆不完整,(2) 验证记忆覆盖度,(3) 重建丢失记忆,(4) 通过 cron/heartbeat 自动同步每日记忆。支持简单提取及基于 LLM 的叙事摘要,并自动清理敏感信息。
CURRENT_ROLE() 的典型使用场景和正确调用链
它真正有用的地方,是在存储过程、触发器或应用连接池复用时,快速判断当前上下文的身份边界。例如做行级权限控制前确认角色是否就位:
- 先激活:
SET ROLE 'reporter'@'%'; - 再验证:
SELECT CURRENT_ROLE();→ 返回'reporter'@'%' - 若要恢复为默认角色(通常是无角色状态):
SET ROLE NONE;,此时CURRENT_ROLE()又变为空字符串 - 如果用户有多个角色,
SET ROLE ALL EXCEPT 'admin'@'%';后,CURRENT_ROLE()仍只返回一个(最新激活的那个),不是列表
容易忽略的权限与配置前提
CURRENT_ROLE() 能用,不代表你能用角色功能——它依赖底层开关和权限:
- MySQL 必须 ≥ 8.0.0,且
activate_all_roles_on_login系统变量为OFF(默认值),否则登录即激活所有角色,CURRENT_ROLE()总是非空 - 执行
SET ROLE需要有ROLE_ADMIN权限,或被明确授予目标角色(WITH ADMIN OPTION) - 普通用户调用
CURRENT_ROLE()不报错,但若权限不足导致无法激活角色,函数始终返回空,别误以为是 bug
角色机制本身不难,难的是记住“授予 ≠ 激活”,而 CURRENT_ROLE() 只回答后者。漏掉 SET ROLE 这一步,就永远看不到非空结果。










