MySQL触发器不能发起HTTP请求或发邮件,因其运行于数据库进程内且禁止外部I/O;硬上UDF风险高,应改用队列表+外部消费或Redis Pub/Sub解耦实现可靠通知。
这是必须先确认的前提:MySQL触发器运行在数据库服务进程内,不支持curl、http_post()、mail()、system()等任何外部I/O操作。所有试图在触发器里直接调用API或发邮件的写法,要么语法报错,要么静默失败,要么导致事务卡死甚至mysqld崩溃。
即使你成功编译安装了mysql-udf-http.so并注册了http_post()函数,也立刻面临几个无法绕开的问题:
http_post()是同步阻塞调用,超时默认不设限——下游API响应慢10秒,你的INSERT就卡10秒HTTP 404、503状态码,也无法获取headers或错误详情mysql用户下,该用户通常被禁止网络访问(尤其在Docker容器或SELinux加固环境)plugin_dir外路径加载,且要求so文件属主为mysql、权限为644,chmod 755都会被拒绝生产环境普遍采用解耦设计,核心是让触发器做唯一确定的事:写入一条结构化记录。后续通知逻辑完全交给独立服务处理。
具体步骤如下:
notification_queue表,字段至少包含:id、table_name、row_id、event_type(INSERT/UPDATE/DELETE)、payload(JSON)、status(pending/processing/success/failed)、created_at
AFTER INSERT触发器,仅执行INSERT INTO notification_queue (...) VALUES (...),不带任何函数调用SELECT * FROM notification_queue WHERE status = 'pending' LIMIT 10,拿到后更新status为processing,再调用外部APIstatus = 'success';失败则设'failed'并记录error_message,便于人工干预或自动重试这个模式天然支持重试、限流、鉴权、全链路日志追踪,且不影响主业务写入性能。
轮询有延迟(最小间隔通常1~5秒),若需亚秒级响应,可用Redis替代队列表:
redis_udf(比mysql-udf-http更轻量、更稳定)REDIS_PUBLISH('notifications', JSON_OBJECT(...))
redis-py的pubsub.subscribe()实时监听,收到消息立即处理注意:REDIS_PUBLISH()仍是同步调用,但耗时在毫秒级,且Redis服务通常与MySQL同机部署,网络开销极小——这是目前最接近“触发即通知”又不破坏稳定性的折中方案。