MySQL触发器无法限制IP写操作，因无法获取真实客户端IP；可行方案为账号级隔离、网络层拦截或代理层控制。
MySQL 不支持用触发器限制 IP 写操作——这是根本行不通的方案，别试了。
触发器（BEFORE INSERT、BEFORE UPDATE 等）运行在语句执行阶段，此时连接已建立、用户已认证，USER() 或 CURRENT_USER() 返回的是「用户名@主机名」，但这个「主机名」来自账号定义（比如 'appuser'@'192.168.1.50'），不是客户端实时 IP；更关键的是：触发器里无法获取当前 TCP 连接的真实客户端 IP 地址。MySQL 没有类似 SQL Server 的 EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]') 机制。
为什么 USER() 和 CURRENT_USER() 都不能反映真实来源 IP
USER() 返回「登录时声明的用户名@host」，可能被客户端伪造（如 mysql -h evil.com -u app@'%'）；CURRENT_USER() 返回实际匹配的账号（如 'app'@'192.168.1.%'），但这是权限系统预设的 pattern，不是运行时解析出的 IP。两者都不等于 $_SERVER['REMOTE_ADDR'] 那种 Web 层可得的地址。
- 执行
SELECT USER(), CURRENT_USER();在任意触发器里，结果都和连接建立时一致，不会随每条 INSERT 变化 - 所谓“限制特定 IP 的写操作”，本质要区分「谁连进来」，而触发器连这个信息都没有
- 试图用
HOST_NAME()或SUBSTRING_INDEX(USER(), '@', -1)解析出 IP，只会得到账号定义里的通配符或字面量（如'192.168.1.%'），不是192.168.1.105
真正能限制 IP 写权限的三个可行层级
必须跳出“在 SQL 层加逻辑”的思维，从连接建立前或账号设计上控制：
-
账号级隔离：创建多个账号，按 IP 分配不同权限。例如
'writer_a'@'192.168.1.10'有INSERT权限，'writer_b'@'192.168.1.11'只有SELECT，应用连接时用对应账号 -
网络层拦截：用
iptables或firewalld限制 3306 端口只对可信 IP 开放，iptables -A INPUT -p tcp --dport 3306 -s 192.168.1.10 -j ACCEPT，再-j DROP兜底 - 代理层控制：在 MySQL 前加 ProxySQL 或 MaxScale，它们能读取真实客户端 IP（通过 PROXY protocol 或 TCP 层），并基于 IP 做读写路由或拒绝
常见误操作与后果
有人会尝试在触发器里写类似这样的逻辑：
DELIMITER $$
CREATE TRIGGER tr_no_insert_from_bad_ip
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
IF SUBSTRING_INDEX(USER(), '@', -1) = '192.168.1.200' THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'IP not allowed to write';
END IF;
END$$
DELIMITER ;
这看起来像在限制，但实际效果是：只要账号是 'xxx'@'192.168.1.200'，所有从该 IP 连进来的写操作都会被拦；而如果账号是 'xxx'@'%'，则永远不触发——因为 SUBSTRING_INDEX(USER(), '@', -1) 返回的是 '%'，不是真实 IP。
最易被忽略的一点：MySQL 的 Host 字段匹配规则是「最长前缀优先」，'user'@'192.168.1.200' 和 'user'@'192.168.1.%' 是两个独立账号，权限互不影响。想靠一个触发器兜底，反而会让权限模型变得不可预测。
