SUSER_NAME()返回当前会话的登录名而非执行者账号；ORIGINAL_LOGIN()始终返回初始连接登录名，更适用于审计；SESSION_USER返回当前数据库用户。
SQL Server里用SUSER_NAME()拿当前登录名，但不是执行者账号
很多人以为SUSER_NAME()返回的是“调用这个存储过程的人”的用户名，其实它返回的是当前会话的**登录名（Login Name）**，也就是连接 SQL Server 时用的 Windows 账户或 SQL 登录名。如果存储过程是用 EXECUTE AS 切换过执行上下文，SUSER_NAME() 仍返回原始登录名，不是切换后的身份。
常见错误现象：
– 存储过程里记录操作日志，日志里写的总是 DBA 的登录名，而不是实际点“执行”按钮的应用用户
– 用 Windows 集成认证连上来，但SUSER_NAME()返回NT AUTHORITY\IUSR这类 IIS 匿名账户，不是终端用户
- 如果你没显式用
EXECUTE AS，SUSER_NAME()和SYSTEM_USER通常一致，都是登录名 -
SUSER_NAME()不带参数时返回当前会话登录名；传入 SID（如SUSER_NAME(0x...)）可查其他 SID 对应的登录名 - 它不反映应用层传递的“用户ID”，比如 ASP.NET 中的
User.Identity.Name或 JWT 里的 sub 字段 —— 这些必须由应用传入参数，不能靠 SQL 自动获取
想拿到应用传来的“业务用户”就得靠输入参数
SQL Server 本身没有机制能穿透连接池、代理、中间件去识别 HTTP 请求头里的用户标识。所谓“执行者”，在数据库层面只有两个可信来源：登录名（SUSER_NAME()）、以及应用主动传进来的值。
使用场景：
– 审计日志表需要记录created_by字段
– 行级安全策略（RLS）需匹配用户所属部门
– 触发器中做变更人校验
- 存储过程开头加一个
@operator_name NVARCHAR(128)参数，由应用层从当前业务会话中提取并传入 - 不要默认设为
NULL再 fallback 到SUSER_NAME()——这会让审计链路断裂，你无法区分“真是用户没传”还是“应用漏传了” - 如果用 Entity Framework，可在
DbContext.SaveChanges()前统一注入；若用 ADO.NET，确保每次SqlCommand.Parameters.Add()都带上该值
ORIGINAL_LOGIN()和SESSION_USER的区别在哪
这三个函数常被混用，但语义完全不同：
-
SUSER_NAME()：当前会话的登录名（可能被EXECUTE AS覆盖） -
ORIGINAL_LOGIN()：不管怎么EXECUTE AS，它始终返回最初建立连接的那个登录名 —— 更稳定，适合审计溯源 -
SESSION_USER：返回当前会话的数据库用户（db_user），不是登录名；如果登录名没映射到当前库的用户，它会返回dbo或报错
示例对比（假设用DOMAIN\alice登录，然后EXECUTE AS USER = 'bob'）：SUSER_NAME() → DOMAIN\aliceORIGINAL_LOGIN() → DOMAIN\aliceSESSION_USER → bob
权限与性能影响：别在循环里反复调用SUSER_NAME()
它是个轻量函数，没有 IO，但频繁调用（比如在游标或大结果集的每行计算中）仍会带来微小开销。更重要的是权限问题：
- 普通用户调用
SUSER_NAME()不需要额外权限，但若传入 SID 参数查别人，需要VIEW SERVER STATE - 如果存储过程用了
EXECUTE AS OWNER且 owner 是sysadmin，那调用者可能无意中获得过高信息可见性 —— 比如通过SUSER_NAME(0x...)枚举服务器上所有 SID - 建议：只在必要位置取一次，赋给变量，后续用变量；避免在 WHERE 条件里直接写
SUSER_NAME() = ...，不利于计划缓存复用
真正难的从来不是怎么拿到名字，而是搞清楚你要的“执行者”到底指哪一层 —— 是 Windows 登录账户？数据库用户？还是业务系统里的工号？后者永远得靠应用传，SQL 没法猜。
