应使用CONNECTIONPROPERTY('client_net_address')获取客户端IP，CAST为NVARCHAR(46)确保兼容IPv6；HOST_NAME()不可靠，仅返回主机名且常为空或中间节点名，不能代表真实客户端。
SQL Server里用CONNECTIONPROPERTY('client_net_address')拿IP，别碰HOST_NAME()
HOST_NAME()在触发器中基本不可信：本地Windows认证返回'<local machine>'</local>或NULL，经代理或容器时返回中间节点名，和真实客户端IP毫无关系。真正可用的是CONNECTIONPROPERTY('client_net_address')，它从TCP连接层提取IP，更接近真实来源。
但要注意：CONNECTIONPROPERTY只在会话建立后有效，且在某些连接池复用场景下可能被缓存；如果应用走的是命名管道或共享内存，它也可能返回'127.0.0.1'或空值——这不是函数问题，是网络栈本身没透传IP。
- 必须显式转换为字符串：
CAST(CONNECTIONPROPERTY('client_net_address') AS NVARCHAR(46))，因为返回类型是sql_variant - IPv6地址最长46字符，字段定义至少用
NVARCHAR(46)，别用CHAR(15) - 不能在登录触发器外用
EVENTDATA()取IP，它只在DDL或LOGON触发器中可用
PostgreSQL触发器中inet_client_addr()失效？先确认是否过pgbouncer
inet_client_addr()在直连时能拿到真实IP，但一旦前面有连接池（如pgbouncer），它就只能返回池子本机地址（比如127.0.0.1）。这不是函数缺陷，是网络架构决定的。
可行替代方案是让应用层主动设置上下文变量：
- 连接建立后立即执行：
SET app.client_ip = '192.168.1.5'; SET app.user_id = 'alice'; - 触发器函数里用
current_setting('app.client_ip', true)读取，第二个参数true避免因未设而报错 - 注意：该方式依赖应用严格遵守，漏设一次就丢一条记录；不适用于无法控制应用逻辑的遗留系统
Oracle触发器里SYS_CONTEXT('USERENV', 'IP_ADDRESS')返回NULL怎么办
SYS_CONTEXT('USERENV', 'IP_ADDRESS')在RAC、负载均衡、反向代理或数据库连接池后常为空或127.0.0.1。Oracle根本收不到真实客户端IP，不是触发器写错了。
此时硬要记录IP，唯一可靠路径是结合登录触发器+审计表：
- 创建
AFTER LOGON ON DATABASE触发器，在登录瞬间用SYS_CONTEXT('USERENV', 'SESSION_USER')和SYS_CONTEXT('USERENV', 'IP_ADDRESS')写入临时会话表 - 业务DML触发器再通过
SELECT ... FROM session_context_log WHERE spid = SYS_CONTEXT('USERENV', 'SID')关联查出IP - 必须提前授予权限：
GRANT INSERT ON session_context_log TO your_trigger_owner;
所有数据库都通用的底线：不要指望触发器自动识别“真实操作人”
触发器能拿到的永远是连接层身份：CURRENT_USER()、USER()、ORIGINAL_LOGIN()这些返回的都是数据库账号，不是前端填的工号或手机号。如果应用用统一账号app_rw连接，所有日志里的“用户”都会是app_rw。
想把操作归因到具体业务人员，唯一办法是应用在SQL里显式传参，比如：
- INSERT语句带
updated_by = 'alice'字段 - UPDATE前执行
SET CONTEXT_INFO = 0x616C696365（SQL Server）或SET app.operator = 'alice'（PG） - 触发器只负责读取并写入审计表，不尝试“猜测”身份
IP和用户名这两项信息，本质都依赖客户端网络环境和应用配合程度，触发器只是搬运工，不是魔术师。
