MySQL触发器无法获取客户端真实IP，USER()和CURRENT_USER()返回的是授权主机名而非连接源IP；可靠方式是应用层显式传入IP（如SET @client_ip）或在INSERT前校验并用SIGNAL抛出异常拦截。
触发器里怎么拿到客户端真实IP
MySQL触发器无法直接获取连接来源的IP地址，USER() 和 CURRENT_USER() 返回的是账号信息，不是网络层IP。必须依赖外部传入——常见做法是应用层在执行关键语句前，先用 SET @client_ip = '192.168.1.100' 显式设置会话变量，再在触发器中读取 @client_ip。
容易踩的坑：
- 忘记在每次连接开始时初始化
@client_ip，导致后续触发器读到 NULL 或旧值 - 应用未做校验，传入非法格式（如含空格、端口、IPv6压缩写法），影响后续IP段匹配
- 使用连接池时，会话复用可能导致
@client_ip残留上一个请求的值
用INET_ATON()和位运算判断IP是否在黑名单网段内
MySQL原生不支持 CIDR 表示法（如 '192.168.1.0/24'），但可以用 INET_ATON() 将IP转为整型，配合子网掩码做位运算实现等效判断。例如：要判断 @client_ip 是否属于 '192.168.1.0/24'，等价于：
(INET_ATON(@client_ip) & INET_ATON('255.255.255.0')) = (INET_ATON('192.168.1.0') & INET_ATON('255.255.255.0'))
实际部署建议把网段存成三列：ip_start INT UNSIGNED、ip_end INT UNSIGNED、mask_len TINYINT，插入时用脚本预计算好范围，触发器里只做简单整数比较，避免每次重复调用函数和位运算。
注意点：
-
INET_ATON()对非法IP（如'192.168.1.256'）返回NULL，需提前用IS_IPV4(@client_ip)校验（MySQL 8.0.22+） - IPv6 不支持
INET_ATON()，若需兼容，得改用INET6_ATON()+BINARY(16)存储，但触发器逻辑更复杂，多数黑名单场景只需 IPv4
INSERT触发器中如何中止操作并报错
MySQL触发器不能直接 ROLLBACK 或 RETURN，唯一可靠拦截方式是让触发器执行一条必然失败的语句，比如向一个不存在的表插入，或调用不存在的函数。推荐用 SIGNAL（MySQL 5.5+）抛出自定义错误：
IF EXISTS (SELECT 1 FROM ip_blacklist WHERE ip_start <= INET_ATON(@client_ip) AND ip_end >= INET_ATON(@client_ip)) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Client IP blocked by blacklist'; END IF;
这样应用层能收到明确错误码，而不是因隐式失败难以定位。别用 INSERT INTO nonexistent_table 这类方式——它会让错误信息变成“table doesn't exist”，掩盖真实意图。
关键限制：
-
SIGNAL只能在存储过程、函数、触发器中使用，且 MySQL 版本必须 ≥ 5.5 - 触发器中不能修改触发它的同一张表（即不能在
INSERT t1的触发器里再INSERT INTO t1），否则报错ERROR 1442
为什么不该在UPDATE/DELETE触发器里做IP拦截
黑名单拦截本质是「访问控制」，应发生在数据变更**之前**，且与操作类型无关。但在 UPDATE 或 DELETE 触发器里做IP检查，会带来两个实际问题：
- 业务逻辑可能依赖 UPDATE 成功后发通知、写日志等，而触发器中断会导致这些后续动作被跳过，产生状态不一致
- 如果只在 INSERT 触发器里拦截，攻击者可绕过（比如先 INSERT 再 UPDATE 脏数据），所以真正可靠的方案是：所有写操作统一走一个入口表或存储过程，由它集中做IP校验，而不是分散到各表触发器
换句话说，触发器适合做「数据一致性约束」，不适合做「权限控制」；后者该由应用层或代理层（如 ProxySQL）承担。强行塞进触发器，调试难、维护重、还容易漏场景。
