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