SQL Server 中应使用 CONNECTIONPROPERTY('client_net_address') 获取客户端 IP，但仅限直连场景；PostgreSQL 需查 pg_stat_activity；MySQL 触发器无法获取真实 IP，须由应用层传入。
SQL Server 中触发器如何获取客户端 IP 地址
SQL Server 触发器本身不直接暴露客户端网络信息，必须依赖系统上下文函数 CONNECTIONPROPERTY('client_net_address') 或 HOST_NAME()（后者不可靠，仅返回主机名）。真实 IP 需在连接建立时由客户端传入或由 SQL Server 自动捕获——前提是连接未经过代理或负载均衡器。
-
CONNECTIONPROPERTY('client_net_address')是唯一稳定获取 TCP 层客户端 IP 的方式，但仅在会话级有效，需在触发器内立即读取 - 若应用走连接池（如 .NET 的 SqlConnection），IP 来源是应用服务器而非最终用户，此时该值反映的是中间层地址
- 在 Always On 或镜像环境下，该函数仍返回原始连接发起方的 IP，不受故障转移影响
- 权限上无需额外授权，但调用者需有触发器执行权限，且不能在 contained database 中用于某些上下文（如无登录映射时可能返回 NULL）
PostgreSQL 触发器中怎样拿到 client_addr
PostgreSQL 没有内置触发器上下文函数直接返回客户端 IP，必须通过 pg_stat_activity 关联当前进程 ID 查询，且需确保 track_activities = on（默认开启）。该方法本质是查系统视图，不是“实时上下文”，存在极短延迟和竞态风险。
- 在触发器函数中用
(SELECT client_addr FROM pg_stat_activity WHERE pid = pg_backend_pid())获取 IP - 若连接使用 SSL 代理或 pgbouncer（transaction pool 模式），
client_addr显示的是代理地址，不是原始客户端 - 该查询需在
SECURITY DEFINER函数中执行，否则普通用户无法访问pg_stat_activity - 性能影响极小，但频繁调用（如高频写入表）建议缓存到
tg_argv或会话变量（SET LOCAL app.client_ip = 'x.x.x.x'）再读取
MySQL 触发器能否记录 REMOTE_ADDR
MySQL 触发器完全无法访问客户端网络信息。没有类似 CONNECTIONPROPERTY 或 pg_stat_activity 的机制，USER() 和 CURRENT_USER() 只返回账号+主机名（如 'app@10.20.30.40'），但该主机名来自认证阶段，可能被 DNS 解析覆盖、不可信，且无法区分真实 IP 与通配符（如 'app@%'）。
- 若必须记录 IP，唯一可行路径是：应用层将 IP 作为字段显式插入（如
INSERT INTO t (..., client_ip) VALUES (..., '1.2.3.4')） - 或改用存储过程封装写入逻辑，在过程开头用
SELECT SUBSTRING_INDEX(USER(), '@', -1)提取主机部分（仅当 MySQL 配置为不解析 DNS 且客户端直连时才可靠） - MySQL 8.0+ 的
performance_schema.host_cache不可用于触发器内实时查询，且默认关闭、权限受限
跨数据库统一记录 IP 的现实约束
所谓“统一方案”根本不存在。各数据库对客户端元数据的暴露粒度、时效性、权限模型差异太大，强行抽象会掩盖关键缺陷。真正能落地的做法是分层处理：
- 网络层：在反向代理（Nginx / HAProxy）或 API 网关中添加
X-Forwarded-For头，并透传给应用，由应用写入审计字段 - 应用层：所有 INSERT/UPDATE 封装为 DAO 方法，强制传入
request.getRemoteAddr()或等效值，避免依赖数据库侧补全 - 数据库侧：仅把触发器当作兜底（如防止绕过 ORM 直连修改），并明确注释“IP 来源不可控，仅作参考”
最常被忽略的一点：即使数据库成功拿到 IP，它也无法验证该 IP 是否被伪造。真正的可信来源永远在 TLS 终止点之后的第一跳，而不是 SQL 执行点。
