mysql触发器不能直接发起http请求，须通过mysql-udf-http等udf间接实现，但该方式同步阻塞、无超时重试、破坏事务安全，生产环境强烈不建议；推荐触发器仅写outbox表，由外部服务异步消费调用。
MySQL触发器本身不能直接发起 HTTP 请求，但可以通过 mysql-udf-http 这类用户自定义函数（UDF）间接实现。这不是“绕过限制”，而是把网络 I/O 移到 MySQL 服务进程内执行——代价是牺牲事务安全性和稳定性。生产环境强烈不建议这么做。
mysql-udf-http 能做什么、不能做什么
mysql-udf-http 提供了四个同步阻塞式函数：http_get、http_post、http_put、http_delete。它们底层调用 libcurl，行为类似 shell 中的 curl -X GET，返回响应体字符串（或 NULL）。
但它做不到这些：
- 无法设置超时时间（默认可能卡住几十秒甚至更久）
- 不支持重试、熔断、降级等容错逻辑
- 失败时整个 SQL 语句报错，若在触发器中调用，会导致 INSERT/UPDATE 回滚
- 没有连接池，高并发下容易耗尽 socket 或触发系统级限制
安装和注册 UDF 的关键步骤
必须确保编译环境、MySQL 版本、插件路径三者严格匹配，否则 CREATE FUNCTION 会报 ERROR 1127: Can't find symbol 'http_get' in library。
- 先装依赖：
yum install curl-devel gcc make - 编译时指定正确路径：
./configure --with-mysql=/usr/bin/mysql_config --libdir=/usr/lib64/mysql/plugin/（注意不是/usr/lib64/mysql） - 检查生成的 so 文件是否真在 plugin 目录下；若实际在
/usr/lib64/mysql/plugin/mysql-udf-http.so.0.0.0，需软链或重命名 - 进 MySQL 执行注册（函数名大小写敏感）：
CREATE FUNCTION http_get RETURNS STRING SONAME 'mysql-udf-http.so';
在触发器里调用的典型写法与风险点
下面这段代码能跑通，但不等于它该被用在生产环境：
DELIMITER $$
CREATE TRIGGER notify_on_insert AFTER INSERT ON orders
FOR EACH ROW
BEGIN
SET @res = (SELECT http_post('https://webhook.example.com', CONCAT('{"id":', NEW.id, '}')));
END$$
DELIMITER ;
问题集中在：
-
SET @res = (SELECT ...)是唯一可行写法，不能直接在触发器里写SELECT http_post(...)（语法报错） - 如果 webhook 响应慢或超时，这个 INSERT 会被卡住，主业务写入延迟飙升
- 下游服务不可用时，订单插入失败——而你真正想保的其实是订单数据，不是通知
- 所有请求都在 mysqld 进程内发起，DBA 通常禁止这类插件上线（安全策略+稳定性双否决）
为什么“能用”不等于“该用”
真正棘手的不是技术能不能实现，而是故障传播路径：一个 HTTP 超时 → 触发器卡住 → 事务堆积 → 连接数打满 → 整个 MySQL 写入阻塞。这种级联失效在监控里往往只体现为“QPS 下降”或“慢查询突增”，根本看不出源头是某个 UDF。
如果你的场景只是“数据变更后通知下游”，更健壮的做法是：触发器只往一张 outbox 表插入事件记录，再由独立服务轮询或监听 binlog 消费并发起 HTTP 调用。这样数据库归数据库，网络归网络，边界清晰，出问题也容易定位。
