MySQL触发器无法获取客户端真实IP，因USER()和CURRENT_USER()仅返回授权主机模式（如'webapp@%'），不反映实际连接地址；唯一可靠方式是应用层解析并传入client_ip字段供触发器使用。
MySQL触发器里无法直接获取客户端真实IP，USER() 和 CURRENT_USER() 返回的是授权主机模式（如 'app@10.20.30.%'），不是终端发起连接的真实地址。
为什么 USER() 和 CURRENT_USER() 都不能用
这两个函数只反映 MySQL 权限系统中定义的「允许从哪来」，不反映「实际从哪来」：
-
USER()返回连接时声明的用户@主机（可能带通配符），比如'webapp@192.168.%.%'—— 它是配置值，不是实时网络地址 -
CURRENT_USER()更严格，只返回权限匹配到的账户定义，例如'webapp@%'，连具体网段都不展开 - 只要中间有跳板机、HAProxy、RDS Proxy 或任何四层代理，HOST 部分基本固定为内网地址或
'%'，和终端 IP 完全无关 - 在触发器里调用它们，结果和你在客户端执行
SELECT USER();一模一样 —— 和当前 DML 操作来源毫无关系
真正能用的 IP 只能由应用层传入
MySQL 不解析 HTTP 头、不读取原始 TCP 源地址（除非启用 performance_schema 并开启连接采集，但那不是触发器能访问的）。唯一可控、可信赖的方式是：让应用显式把解析好的 IP 当作字段写入业务表，触发器再引用它。
- 在业务表加一列，如
client_ip VARCHAR(45)（支持 IPv6） - 应用代码中必须解析
REMOTE_ADDR或X-Forwarded-For（注意校验可信代理链），然后拼进 INSERT/UPDATE 语句：INSERT INTO orders (amount, client_ip) VALUES (100.00, '203.0.113.42'); - 触发器中安全引用
NEW.client_ip，它就是你写进去的那个确定值，不会被 MySQL 自动替换 - 为防绕过，可在触发器开头加校验：
IF NEW.client_ip IS NULL OR NEW.client_ip = '' THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'client_ip is required'; END IF;
别碰 INFORMATION_SCHEMA.PROCESSLIST 和 AFTER CONNECT 触发器
这两类方案看似“自动”，实则不可靠且危险：
-
PROCESSLIST的HOST列不稳定：可能为空、为'localhost'、或显示跳板机地址；触发器执行期间该表可能已刷新，查到的记录与当前事务无关 - 游标遍历
PROCESSLIST是重操作，容易锁表、拖慢事务；MySQL 8.0+ 默认禁止非 SUPER 用户查询它 -
AFTER CONNECT ON *.*语法在官方 MySQL 中根本不存在 —— 这是某些博客杜撰的伪语法，实际会报错ERROR 1064 - 即使强行用存储过程+定时轮询模拟，也无法绑定到某次 INSERT/UPDATE 的上下文，日志和操作脱节
最易被忽略的一点：IP 地址的可信性完全取决于应用层是否做了可信代理头校验。如果应用直接信任未经验证的 X-Forwarded-For，攻击者可以伪造任意 client_ip 值写入数据库 —— 触发器再严谨也无济于事。
