触发器本身不自带客户端 IP 获取能力，必须依赖数据库提供的上下文函数或系统视图；不同数据库实现差异极大，不能写一套 SQL 通吃所有平台。
SQL Server：用 CONNECTIONPROPERTY('client_net_address')，但要注意连接路径
这是唯一推荐的、会话级有效的办法。它返回 TCP 层建立连接时的真实客户端地址（IPv4/IPv6），不是主机名，也不是代理后端地址。
-
CONNECTIONPROPERTY('client_net_address')必须在触发器内立即调用，延迟读取可能因会话复用而失效 - 如果应用走连接池（如 .NET
SqlConnection或 Java HikariCP），该值是应用服务器 IP，不是最终用户 IP - 经过反向代理（Nginx / F5 / ALB）或负载均衡器时，该函数始终返回代理 IP，无法穿透
- 在 Always On 故障转移后仍有效，返回原始发起方 IP，不受副本切换影响
- 无需额外权限，但触发器执行者需有
EXECUTE权限；在 contained database 中若无登录映射，可能返回NULL
PostgreSQL：查 pg_stat_activity 关联 pg_backend_pid()，要设 SECURITY DEFINER
PG 没有触发器内置变量，只能通过系统视图反查当前会话信息。本质是“快照式查询”，不是实时上下文。
- 必须写成
SECURITY DEFINER函数，否则普通用户无权访问pg_stat_activity - 典型写法：
(SELECT client_addr FROM pg_stat_activity WHERE pid = pg_backend_pid()) - 若使用
pgbouncer（transaction pool 模式）或 SSL 终止代理，client_addr显示的是中间层地址 -
track_activities需为on（默认开启），否则视图为空 - 高频写入表时建议用
SET LOCAL app.client_ip = 'x.x.x.x'在应用层预设，避免反复查系统视图
Oracle：用 SYS_CONTEXT('USERENV', 'IP_ADDRESS')，仅限登录触发器或显式设置
这个函数在普通 DML 触发器里**不可用**——它只在登录会话初始化时可靠，DML 触发器中调用会返回空或 NULL。
- 正确做法是建
AFTER LOGON ON DATABASE触发器，调用DBMS_APPLICATION_INFO.SET_CLIENT_INFO()把 IP 存进client_info字段 - 后续在业务表的触发器里，可通过
SELECT client_info FROM v$session WHERE sid = SYS_CONTEXT('USERENV','SID')关联获取（注意权限和性能） - BS 架构下（如 Java Web 应用），查到的仍是应用服务器 IP；真实用户 IP 需由应用在 JDBC URL 或
setClientInfo()中传入 - 直接在 DML 触发器里写
SYS_CONTEXT('USERENV', 'IP_ADDRESS')大概率返回空，别试
MySQL：触发器里拿不到真实客户端 IP，必须由应用层传入
MySQL 触发器完全不暴露网络会话信息。USER()、CURRENT_USER() 只返回账号，@@hostname 是服务端主机名，没有等效于 CONNECTIONPROPERTY 的机制。
- 唯一可行路径：应用在 INSERT/UPDATE 语句中显式带入 IP 字段，例如
INSERT INTO orders (..., client_ip) VALUES (..., ?) - 若用代理（如 ProxySQL、MaxScale），可在代理层注入
SET @client_ip = 'x.x.x.x'，再在触发器里读@client_ip变量 - 不要尝试用
INFORMATION_SCHEMA.PROCESSLIST查，该视图不包含客户端 IP 字段，且权限受限 - 试图用存储过程调用外部命令（如
sys_exec）获取 IP 属高危操作，多数生产环境禁用
真正麻烦的地方不在语法，而在网络链路——你拿到的 IP 到底是哪一层的？直连、连接池、反向代理、SSL 终止、数据库中间件……每多一层，就多一次地址覆盖。先画清架构图，再决定在哪一层捕获 IP，比纠结触发器写法重要得多。
