MySQL用USER()或SYSTEM_USER()、PostgreSQL用session_user和inet_client_addr()获取会话信息，需注意类型兼容、空值处理及避免递归；审计漏记录主因是连接池、代理或批量操作导致会话信息失真，须结合应用透传与触发器防护。
触发器里怎么拿到当前用户和会话信息
MySQL 和 PostgreSQL 的触发器默认不暴露会话上下文，AUDIT_USER 或 CURRENT_USER() 这类函数返回的是执行触发器的定义者（definer），不是实际发起 DML 的用户。真要审计“谁在什么时候改了哪条记录”，得靠数据库自带的会话变量或系统函数。
MySQL 8.0+ 可用 USER()（含主机）或 CURRENT_USER()（含权限上下文），但更稳的是 SYSTEM_USER()；PostgreSQL 则直接用 current_user、session_user，必要时加 inet_client_addr() 和 pg_backend_pid() 补充来源。
-
USER()在 MySQL 中反映连接时的用户名@host，适合区分不同终端登录者 - PostgreSQL 的
session_user是认证用户，current_user可能被SET ROLE修改，审计建议优先用前者 - 别在触发器里调
SELECT USER()—— 触发器内不允许显式查询，直接写函数名即可 - Oracle 需用
sys_context('USERENV', 'SESSION_USER')，且必须确保触发器是行级 +FOR EACH ROW
INSERT/UPDATE/DELETE 触发器中如何安全记录会话字段
审计表字段设计不当，会导致触发器报错或漏数据。比如把 client_ip 定义为 CHAR(15)，MySQL 就存不下 IPv6 地址；PostgreSQL 若用 inet 类型却传入空字符串，直接抛 invalid input syntax for type inet。
关键不是“能不能记”，而是“记全且不崩”。触发器体里对新旧值的引用（如 NEW.id、OLD.name）和会话函数必须统一处理空值与类型兼容性。
- MySQL：用
IFNULL(INET_ATON(USER()), 0)存 IP 整数，或直接用VARCHAR(45)存原始字符串 - PostgreSQL：IP 字段声明为
INET，插入前用NULLIF(inet_client_addr(), '0.0.0.0')过滤无效地址 - 时间字段别依赖
NOW()—— 触发器可能跨事务延迟，用CURRENT_TIMESTAMP更准 - 避免在触发器里做复杂拼接（如
CONCAT(USER(), '@', VERSION())），函数调用开销叠加易拖慢主 DML
为什么触发器审计常漏掉批量操作或代理连接
很多团队发现“明明改了数据，审计表却没记录”，大概率是触发器没覆盖真实入口。典型有三类场景：应用直连数据库走连接池（user 恒为连接池账号）、中间件代理（如 ProxySQL、ShardingSphere）、或 ORM 批量语句（INSERT ... ON DUPLICATE KEY UPDATE）绕过单行触发逻辑。
根本问题在于：触发器只响应“到达存储引擎的 DML”，不感知上层路由逻辑。一旦连接被复用或语句被重写，会话信息就失真。
- 连接池场景下，
USER()返回的是池账号（如pool_user@localhost），真实操作人只能靠应用层透传到自定义会话变量（MySQL 的@app_user，PG 的SET app.user = 'xxx'） - ProxySQL 等代理需开启
mysql-client-statistics并配置send_query_comment=true，再让触发器解析COMMENT提取标记 - MySQL 的
INSERT ... SELECT或REPLACE INTO不触发BEFORE UPDATE，必须为每种 DML 类型单独建触发器
PostgreSQL 中用 pg_trigger_depth() 防止递归写审计表
审计表自身被 INSERT，若触发器没设防，就会无限递归：写审计 → 触发审计 → 再写审计……最终爆栈或锁表。MySQL 用 SQL SECURITY DEFINER + 权限隔离较弱，PG 提供了更直接的判断方式。
pg_trigger_depth() 返回当前嵌套层数，首次进触发器是 1，写审计表时升为 2，这时直接 RETURN 即可中断。
CREATE OR REPLACE FUNCTION log_user_action()
RETURNS TRIGGER AS $$
BEGIN
IF pg_trigger_depth() > 1 THEN
RETURN NEW;
END IF;
INSERT INTO audit_log (table_name, op_type, user_name, client_ip, changed_at)
VALUES (TG_TABLE_NAME, TG_OP, session_user, inet_client_addr(), NOW());
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
注意：pg_trigger_depth() 是会话级计数，不区分触发器函数名，所以多个审计触发器共存时也适用；但它无法防止其他非触发路径（如直接 INSERT audit_log）引发的循环，得靠应用层约定或约束兜底。
真正难的不是写触发器，是确认每一笔审计日志背后那个 session_user 确实来自真实终端——中间件没透传、连接池没切换、应用没伪造 header，这些链路断一环，审计就成摆设。
