MySQL触发器无法获取客户端真实IP，必须由应用层通过SET @client_ip = 'x.x.x.x'显式传入，再在BEFORE触发器中校验白名单并用SIGNAL中断非法操作。
触发器里怎么拿到客户端真实IP
MySQL触发器本身无法直接获取连接来源IP，USER() 和 CURRENT_USER() 返回的是账号信息，不是网络地址。必须依赖外部传入或会话变量——最可靠的方式是应用层在执行修改前显式设置：
SET @client_ip = '192.168.1.100';然后在触发器中读取
@client_ip。注意：这个变量是会话级的，每个连接独立，不会污染其他会话。
BEFORE UPDATE/DELETE 触发器中校验白名单
限制数据修改必须放在 BEFORE UPDATE 和 BEFORE DELETE 触发器里，因为此时语句尚未执行，还能用 SIGNAL 中断操作。白名单建议存为表（如 ip_whitelist），避免硬编码：
- 建白名单表：
CREATE TABLE ip_whitelist (ip VARCHAR(45) PRIMARY KEY);
- 触发器内查表并中断：
IF NOT EXISTS (SELECT 1 FROM ip_whitelist WHERE ip = @client_ip) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'IP not allowed to modify data'; END IF;
- 若白名单很小且极少变动，也可用
IN列表，但超过 5–10 个 IP 就该用表，否则维护和性能都吃力
为什么不能在 AFTER 触发器里做限制
AFTER 触发器执行时，原操作已完成，即使你在这里抛出 SIGNAL，数据也已经改了或删了。MySQL 不支持回滚 AFTER 触发器里的隐式事务，所以限制逻辑必须前置。另外，INSERT 同样需要限制，对应加 BEFORE INSERT 触发器，逻辑一致。
应用端忘记设 @client_ip 怎么办
这是最常踩的坑：触发器读到 @client_ip 为 NULL 或空字符串，导致所有修改被拦。应在触发器开头加兜底判断：
IF @client_ip IS NULL OR TRIM(@client_ip) = '' THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Missing client IP context'; END IF;同时，在应用连接池初始化或每次执行前强制设置，比如在 JDBC 的
connection.setClientInfo("ApplicationName", "xxx") 不起作用，必须走 execute("SET @client_ip = ?")。
白名单校验本身简单，难点全在上下文传递的可靠性——IP 不是数据库自动给的，得靠应用一层不掉链子，而且每个连接生命周期里只能设一次、不能覆盖。 
