MySQL用CURRENT_USER()查权限上下文，USER()查连接来源；PostgreSQL用CURRENT_USER查执行角色、SESSION_USER查初始登录名；SQL Server用SUSER_NAME()查登录名、USER_NAME()查库用户；Oracle用SYS_CONTEXT('USERENV','SESSION_USER')查认证用户，USER仅返回schema名。
MySQL 中查当前登录用户用 USER() 还是 CURRENT_USER()
两者都返回用户信息，但语义和权限校验逻辑完全不同。USER() 返回客户端声明的用户名+主机（比如 'admin@192.168.1.100'），而 CURRENT_USER() 返回服务器实际用于权限匹配的账户（比如 'admin@%'）。如果用了代理、跳板机或 SET ROLE，这两个值很可能不一致。
- 日常调试建议优先看
CURRENT_USER()，它反映真实生效的权限上下文 -
USER()更适合审计连接来源，比如排查谁从哪台机器连进来的 - 在存储过程或触发器里，
CURRENT_USER()才决定能访问哪些表，不是USER()
PostgreSQL 怎么拿到当前会话的用户名和角色
PostgreSQL 没有统一的“当前用户”函数，得按场景选：CURRENT_USER 是执行上下文的角色（受 SET ROLE 影响），SESSION_USER 是初始登录角色，CURRENT_ROLE 是当前生效的角色名（可能和 CURRENT_USER 相同）。
- 想查谁真正拥有操作权限 → 用
CURRENT_USER - 想追溯原始登录身份（比如审计日志）→ 用
SESSION_USER - 在
pg_stat_activity里看到的usename字段，对应的是SESSION_USER - 注意：这些都不是函数调用，不用加括号，写成
CURRENT_USER就行，加了反而报错
SQL Server 的 SUSER_NAME() 和 SYSTEM_USER 区别在哪
SUSER_NAME() 返回当前登录的 Windows 或 SQL 登录名（如 'DOMAIN\alice' 或 'sa'），而 SYSTEM_USER 是别名，等价于 USER_NAME() —— 但它查的是数据库级用户，不是登录名。如果登录名没映射到当前库的用户，USER_NAME() 可能返回 NULL。
- 跨库操作时，
SUSER_NAME()稳定；USER_NAME()依赖当前数据库上下文 - 判断是否以
sa身份运行，用SUSER_NAME() = 'sa'，别用SYSTEM_USER - 权限检查逻辑里，SQL Server 实际比对的是
SUSER_SID()对应的 SID，不是名字字符串
Oracle 查登录用户要小心 USER 和 SYS_CONTEXT 的陷阱
USER 是个伪列，只返回当前 schema 名（比如 'HR'），不是登录账号；真要查 OS 用户或数据库认证用户，必须用 SYS_CONTEXT('USERENV', 'SESSION_USER') 或 'OS_USER'。
-
USER在视图定义里会被固化为创建者，不是调用者 —— 这点极易误判权限归属 - 常用键包括：
'SESSION_USER'（DB 认证用户）、'OS_USER'（操作系统用户名）、'IP_ADDRESS'（客户端 IP） -
SYS_CONTEXT返回VARCHAR2，长度默认 256，超长会截断，生产环境建议显式指定第三个参数控制长度
有些系统把登录名、schema 名、角色名混在一起返回，看着像一个东西，其实背后权限链路差得很远。查之前先想清楚：你要的到底是“谁连进来的”，还是“谁被授权执行的”。
