MySQL触发器不能安全直接调用外部API或执行系统命令，因其同步阻塞会导致事务卡死、数据不一致；可靠方案是触发器仅写入outbox表，由外部服务异步轮询并调用API。
MySQL触发器**不能安全、可靠地直接调用外部API或执行系统命令**。强行这么做会导致事务卡死、数据不一致、权限失控，甚至让整个数据库服务不可用。
mysql-udf-http 或 sys_exec 在触发器里会卡住 INSERT
即使你编译安装了 mysql-udf-http.so 或启用了 sys_exec，在触发器中调用 http_post() 或 sys_exec() 仍是高危操作：
- mysqld 进程会同步阻塞等待外部响应，超时不可控；下游 API 延迟 5 秒，你的
INSERT就卡 5 秒 - 事务未提交前调用失败，无法回滚外部副作用（比如已发邮件但订单插入失败）
-
http_post()返回NULL时不会报错，你得手动检查@res IS NULL，但无法区分是网络断开、DNS 失败还是对方返回空 JSON -
sys_exec()需要FILE权限，且脚本路径、用户环境、SELinux/AppArmor 等常导致静默失败
触发器只写 outbox 表，才是生产可用的方案
把“调用外部”这个动作从数据库里彻底剥离，用异步解耦方式实现：
- 触发器只做一件事：向
outbox表插入一条待发送记录，包含url、method、payload、created_at - 外部程序（Python/Node.js）用短间隔轮询
outbox，按status = 'pending'取任务，调用 API 成功后更新为'sent' - 轮询程序必须自带重试（指数退避）、失败隔离（单条失败不影响其他）、幂等标记（加
request_id防重发） - 示例表结构：
CREATE TABLE outbox ( id BIGINT PRIMARY KEY AUTO_INCREMENT, url TEXT NOT NULL, method VARCHAR(10) DEFAULT 'POST', payload JSON NOT NULL, status ENUM('pending', 'sent', 'failed') DEFAULT 'pending', attempts TINYINT DEFAULT 0, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
为什么不能用 BEFORE 触发器 + signal 模拟“同步回调”
有人试图在 BEFORE INSERT 中查 outbox 状态，再用 SIGNAL 强制等待，这是错误思路：
-
SIGNAL只能抛异常中断当前语句，不能暂停等待外部结果 - 触发器内无法查询自己刚插入的
outbox记录（除非用AFTER，但那时事务已不可逆） - 轮询程序和触发器不在同一事务上下文，不存在“同步感知”机制
- 任何想在触发器里“等外部结果”的设计，本质都在对抗 MySQL 的事务模型
真正容易被忽略的点是：outbox 表本身需要加索引（如 (status, created_at)），否则轮询会全表扫描；同时轮询频率不能太密（比如 100ms 一次），否则在高并发下反而成为数据库负担。
