不能在MySQL触发器中直接获取真实业务操作人，因USER()等函数仅返回连接用户而非应用层登录用户，必须由应用层显式传入user_id等标识供触发器使用。
触发器里拿不到真实操作人——这是数据库设计的固有约束，不是你写错了。所有试图在触发器中直接调用 USER()、CURRENT_USER() 或查 INFORMATION_SCHEMA.PROCESSLIST 的方案，都必须先过三关：类型兼容、空值防御、执行权限限制。
MySQL 触发器中 USER() 为什么不可信
它返回的是「连接声明的用户@host」，不是业务系统里的登录人。常见现象是所有审计记录都显示 'app@localhost' 或 'root@127.0.0.1'，因为应用用了统一账号连接池，或本地 socket 连接导致 host 被固化为 localhost。
-
SYSTEM_USER()比USER()稍稳，但它仍是定义者身份，不随请求变化 - 想取客户端 IP？
USER()的 host 部分可能被 DNS 反查污染，且 IPv6 地址会被截断 - 触发器内不能执行
SELECT ... FROM performance_schema.threads（8.0.16 前报错），INFORMATION_SCHEMA.PROCESSLIST是唯一可读的替代，但需配合CONNECTION_ID()查找，并手动SUBSTRING_INDEX(HOST, ':', 1)提取 IP - 字段类型必须预留余量：
VARCHAR(45)存 IP 字符串，别用CHAR(15)—— 否则 IPv6 直接存失败
PostgreSQL 触发器中 session_user 和 current_setting 的配合用法
session_user 是认证时的用户名，不可被 SET ROLE 修改，适合做审计基准；但它的值来自连接层，若走 PgBouncer 的 session 模式，所有请求都会显示同一个 session_user。
- 真正可控的方式是应用层执行
SET LOCAL app.user_id = 'u_123'，触发器里用current_setting('app.user_id', true)读取 - 必须加
true参数，否则变量不存在时直接报错，而不是返回 NULL - IP 和端口可用
inet_client_addr()+inet_client_port()，但要注意：本地 Unix socket 连接时前者返回 NULL，需用NULLIF(inet_client_addr(), '0.0.0.0')过滤无效值 - 别在触发器里拼接字符串（如
CONCAT(session_user, '@', inet_client_addr())），开销叠加会拖慢主 DML
SQL Server 触发器中 ORIGINAL_LOGIN() 是唯一可信入口
SUSER_NAME() 和 CURRENT_USER 在 EXECUTE AS 或连接池场景下会返回代理账号（如 NT AUTHORITY\SYSTEM），只有 ORIGINAL_LOGIN() 绑定连接生命周期起点，不会漂移。
- 必须把
DECLARE @LoginName SYSNAME = ORIGINAL_LOGIN();放在触发器最开头，避免嵌套调用时上下文丢失 - 日志表字段要用
NVARCHAR(128)存登录名——域账号如DOMAIN\user.name超过 30 字符 - 不要查
sys.dm_exec_sessions获取原始登录名，既需要VIEW SERVER STATE权限，又多一次 DMV 查询，纯属冗余 - 敏感字段变更审计建议用
COLUMNS_UPDATED()位运算判断，而非全字段比对，性能更可控
最易被忽略的一点：无论用哪种函数，触发器本身不解决连接池掩盖身份的问题。真正的链路是「应用透传 → 数据库接收 → 触发器落库」，中间任何一环断掉，审计就漏。比如 PgBouncer 开了 transaction 模式却没在每次事务开头 SET LOCAL，或者 MySQL 应用复用连接但忘了重置 @current_user_id 变量——这些都不是触发器能兜底的。
