MySQL触发器调用外部脚本实现HTTP告警的方法

MySQL触发器无法直接发送HTTP请求，这几乎是每位深度使用MySQL的开发者都曾遇到的技术瓶颈。MySQL天生不具备网络I/O能力，像`http_get`、`http_post`这类函数并非原生支持。那么该如何解决？通常需要借助用户自定义函数（UDF）扩展。但请注意——这些UDF本质上是将libcurl或系统调用强行嵌入mysqld进程运行，结果就是同步阻塞、缺乏超时机制、也没有重试策略。当你发起一个`http_get`请求时，如果下游接口响应缓慢，你的`INSERT`语句就会直接卡死，整个事务随之崩溃。

mysql-udf-http：看似可用，实际处处是坑

即便你成功编译并安装了`mysql-udf-http.so`，并注册了`http_post`函数，在MySQL触发器中也只能按如下方式编写： ``` SET @res = (SELECT http_post('https://api.example.com', '{"id": 123}')); ``` 不能直接使用`SELECT http_post(...)`（否则会语法报错），也无法在存储过程中直接调用。常见的踩坑点包括： - 在`CREATE FUNCTION`时，若`SONAME`路径出错一个字符（例如`mysql-udf-http.so.0.0.0`未创建软链接到`mysql-udf-http.so`），便会触发`ERROR 1127: Can't find symbol 'http_post'`错误。 - 如果你传递的是JSON字符串，且后端通过`@RequestBody`接收，需要注意：`http_post`默认发送`application/x-www-form-urlencoded`类型，必须手动拼接query string，否则body内容为空。 - 如果返回的响应体为`NULL`，系统不会抛出异常，只会静默失败。你只能通过`@res IS NULL`来判断，但无法区分是网络超时还是服务返回空结果。 这些均是实际开发中遇到的真实陷阱，仅调试就可能耗费半天时间。

sys_exec：表面灵活，实则是更大的雷

有人可能会想：能否使用`lib_mysqludf_sys`中的`sys_exec`来执行`curl`或`php`脚本？表面上看确实更灵活，但实际风险更大： - 脚本执行权限受`mysqld`进程所属用户（通常是`mysql`）限制，权限不足会导致直接失败。 - `sys_exec`仅返回shell退出码，而非HTTP状态码。`0`仅表示命令执行完毕，并不代表请求成功。例如curl返回0，但实际请求可能并未成功。 - 在高并发场景下，频繁fork子进程极易触发`max_connections`或`ulimit -n`限制，导致数据库连接崩溃。 - 脚本的标准错误输出会被MySQL直接丢弃，调试只能通过`echo >> /tmp/debug.log`手动写入文件，而线上环境通常禁止此类写盘操作。 因此，这条路基本行不通。

真正可行的方案：Outbox模式 + 外部消费者

综上所述，结论非常明确：不要让触发器处理网络请求。正确的做法是——触发器仅负责向`outbox`表写入记录，建表示例如下： ``` CREATE TABLE outbox ( id BIGINT AUTO_INCREMENT PRIMARY KEY, event_type VARCHAR(32), payload TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, processed TINYINT DEFAULT 0 ); ``` 然后使用一个独立服务（如Python、Go或Java）轮询该表，发送HTTP请求，并将`processed`字段更新为`1`。该模式具有以下几个关键优势： - 触发器逻辑可在毫秒级完成，完全不影响主业务的写入性能。 - 外部服务可实现重试、熔断、限流和告警——这些功能在MySQL内部根本无法实现。 - 失败的消息仍保留在`outbox`表中，便于查询和重放，相比UDF中消息丢失即消失，其可靠性提升十倍以上。 - 更重要的是，DBA不会因安全策略禁用UDF插件，运维人员也乐意配合部署消费者服务。 归根结底，真正的难点不在于如何调通一次HTTP请求，而在于如何让“通知”机制在生产环境中具备高并发承载能力、容错性和可观测性——这些全部应交给应用层处理，而非强行塞入数据库。