mysql触发器无法安全获取客户端真实ip，必须由应用层显式传入；user()返回授权主机模式而非网络源地址，中间代理会使host部分失真，唯一可靠方式是应用在sql中传入client_ip字段供触发器校验。
MySQL触发器无法安全获取客户端真实IP——必须由应用层显式传入，否则所有“取IP”方案都不可靠。
为什么 USER() 和 SUBSTRING_INDEX(USER(), '@', -1) 不等于真实客户端IP
USER() 返回的是认证时匹配的授权主机模式，比如 'appuser@10.20.30.%' 或 'admin@localhost'，它不是网络层源地址。即使客户端真实 IP 是 203.0.113.42，只要授权允许从 10.20.30.0/24 连入，USER() 就永远不体现这个值。
- 中间有跳板机、HAProxy、ProxySQL、云数据库代理（如阿里云 RDS Proxy）时，
HOST部分几乎总是内网地址或'%' -
CURRENT_USER()更严格，只返回权限系统定义的角色，连通配符都不展开，实际比USER()还“假” - 在触发器里执行
SUBSTRING_INDEX(USER(), '@', -1)，结果和你在客户端手动执行SELECT USER();完全一致——和请求来源无关
唯一可靠路径：应用层把 IP 作为字段写入，触发器只做校验和落库
MySQL 本身不解析 TCP 包、不读 HTTP 头、也不暴露原始连接信息给触发器。真实 IP 只能由应用在发起 INSERT/UPDATE 前，从 REMOTE_ADDR 或可信的 X-Forwarded-For（需反向代理透传并校验）中解析后，作为普通字段一并提交。
- 业务表加一列：
client_ip VARCHAR(45)（兼容 IPv4/IPv6） - 应用代码中显式赋值：
INSERT INTO orders (amount, client_ip) VALUES (100.00, '203.0.113.42'); - 触发器里直接引用：
NEW.client_ip，并可加强制校验：IF NEW.client_ip IS NULL OR NEW.client_ip = '' THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'client_ip is required'; END IF;
硬要绕路？这些替代方案要么失效，要么危险
所有试图在触发器内部“现场抓 IP”的做法，在生产环境都踩过坑：
-
INFORMATION_SCHEMA.PROCESSLIST查询不稳定：触发器执行期间该视图可能已刷新；HOST 列常为空、为'localhost'或中间节点地址；MySQL 8.0+ 默认禁止非 SUPER 用户查询 -
SELECT SUBSTRING_INDEX(USER(), '@', -1)在 DNS 解析开启时可能返回域名而非 IP；用INET_ATON()校验会失败 IPv6；INET6_ATON()又不支持 MySQL 5.7 - 基于
USER()做黑白名单（如SUBSTRING_INDEX(USER(),'@', -1) = '192.168.1.200'）只能封住授权主机段，不是真实来源，且易被绕过
最容易被忽略的一点是：任何不走 SQL 层的写入（LOAD DATA INFILE、mysqldump --no-create-info 导入、中间件批量刷库、MySQL Router 直通）都会让触发器完全失能。真要审计，得靠 general_log 或 performance_schema，而不是触发器。
