oracle是唯一在触发器中能直接获取客户端ip的主流数据库，必须用sys_context('userenv','ip_address')获取并显式赋值后比对，mysql/postgresql不支持；空值需判null，且真正有效的ip控制应在监听器或网络层实现。

BEFORE UPDATE 触发器必须结合 sys_context('userenv','ip_address') 判断

Oracle 是唯一在触发器中能直接获取客户端 IP 的主流数据库（MySQL/PostgreSQL 都不支持）。其他数据库无法在触发器里拿到真实连接 IP，硬加判断会失效。Oracle 中必须用 sys_context('userenv','ip_address') 获取当前会话来源 IP，再与白名单或黑名单比对。

常见错误是直接写 IF ip_address = '10.1.2.3' THEN ...——ip_address 不是变量，必须显式赋值：

• DECLARE v_ip VARCHAR2(30) := sys_context('userenv','ip_address');
• 再用 IF v_ip IN ('10.1.2.3', '192.168.5.10') THEN SIGNAL ...（注意 Oracle 用 RAISE_APPLICATION_ERROR，不是 SIGNAL）
• 空字符串或未知 IP（如通过连接池、代理）时 sys_context 可能返回 null，需加 IS NULL 判断，否则条件跳过

MySQL 和 PostgreSQL 不能靠触发器拦 IP，得换思路

MySQL 触发器里查不到客户端 IP；PostgreSQL 的 inet_client_addr() 只能在普通函数里用，触发器中不可调用（会报错 cannot be used in a trigger）。强行在触发器里读取网络信息，结果只有报错或静默跳过。

替代方案要分层落地：

• MySQL：改用 sql_mode + 应用层标识 —— 要求所有合法更新 SQL 必须带注释 /* app=finance-batch */，触发器用 INFORMATION_SCHEMA.PROCESSLIST 查当前会话的 INFO 字段（需 PROCESS 权限），匹配失败则 SIGNAL
• PostgreSQL：用 pg_stat_activity 查 application_name 或 client_hostname（后者依赖反向 DNS，不稳定），配合 SECURITY DEFINER 函数封装校验逻辑，撤掉直连 UPDATE 权限
• 通用兜底：数据库前加代理层（如 HAProxy、PgBouncer），在代理上做 IP 过滤，比 DB 层更早拦截

别忘了权限和部署闭环，否则触发器形同虚设

即使触发器逻辑完全正确，以下三点没做到，照样被绕过：

• Oracle 用户有 ADMINISTER DATABASE TRIGGER 权限（比如 DBA 角色）时，触发器仍会执行但无法阻止登录或修改 —— RAISE_APPLICATION_ERROR 报错后，该用户依然能继续操作
• MySQL 应用账号若被授予了 TRIGGER 权限，就可能自己删掉防护触发器；生产环境应只给 EXECUTE 权限，且触发器由 DBA 统一维护
• PostgreSQL 中，如果应用连接串用了 options=-c%20session_preload_libraries=... 加载恶意库，或 DBA 启用了 track_activities = off，pg_stat_activity 就查不到真实客户端信息

真正起效的 IP 控制，90% 发生在数据库之外

触发器只是最后一道防线，不是第一道。IP 级控制最有效的位置永远是监听器或网络层：

• Oracle：改 $ORACLE_HOME/network/admin/sqlnet.ora，加 TCP.VALIDNODE_CHECKING = YES 和 TCP.INVITED_NODES = (10.1.2.0/24,172.16.0.5)，重启监听器即生效
• MySQL：用系统防火墙（iptables 或 ufw）限制 3306 端口只允许指定网段访问，比任何 DB 内逻辑都快、都稳
• PostgreSQL：在 pg_hba.conf 里写明 hostssl all all 10.1.2.0/24 md5，拒绝其他 CIDR 段，reload 配置即可

触发器查 IP 的动作本身就有性能开销，且依赖会话上下文完整。一旦连接经过 NAT、负载均衡或连接池，拿到的 IP 往往是中间节点地址，不是真实来源 —— 这种情况下，还执着于在触发器里做 IP 判断，不如先确认链路是否透明。