mysql触发器不能直接发http请求或调用外部服务，必须通过写入轻量队列表（如notify_queue），再由外部程序轮询或监听binlog异步处理。
MySQL触发器里不能直接发HTTP请求或调用外部服务
直接在 BEFORE UPDATE 或 AFTER UPDATE 触发器里写 curl、调用 Python 脚本、甚至尝试用 SYS_EVAL（已移除）都是行不通的。MySQL 触发器运行在服务端隔离环境中，不支持网络 I/O、系统命令或自定义函数调用（除非你编译并加载了极少见的 UDF，但生产环境强烈不建议）。
常见错误现象：ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA... 或直接报语法错误——因为 MySQL 拒绝执行任何可能破坏事务原子性或安全模型的操作。
- 触发器只应做轻量级数据校验、字段自动填充（如
updated_at）、日志写入（到本地表） - “消息推送”必须拆解为两阶段：触发器记录变更 → 外部程序轮询/监听变更 → 执行通知
- 不要试图绕过这个限制，否则会掉进权限、超时、事务回滚导致通知丢失等坑里
用专用日志表 + 时间戳/状态字段捕获待通知变更
核心思路是把“需要推送”的事实持久化到一张轻量日志表，由独立服务消费。比如你关注 orders 表中 status 字段从 'pending' 变为 'shipped' 的场景：
CREATE TABLE notify_queue ( id BIGINT PRIMARY KEY AUTO_INCREMENT, table_name VARCHAR(64) NOT NULL, row_id BIGINT NOT NULL, event_type VARCHAR(32) NOT NULL, -- 如 'order_shipped' payload JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, processed TINYINT DEFAULT 0 );
对应触发器示例（仅当满足条件时插入）：
DELIMITER $$
CREATE TRIGGER after_order_status_update
AFTER UPDATE ON orders
FOR EACH ROW
BEGIN
IF OLD.status = 'pending' AND NEW.status = 'shipped' THEN
INSERT INTO notify_queue (table_name, row_id, event_type, payload)
VALUES ('orders', NEW.id, 'order_shipped', JSON_OBJECT('order_id', NEW.id, 'tracking_no', NEW.tracking_no));
END IF;
END$$
DELIMITER ;
- 避免在触发器里做复杂逻辑（如查关联表、拼接长文本），会拖慢主业务更新
-
payload字段用JSON类型，方便存结构化数据，但别塞太大（MySQL JSON 有大小限制，且影响查询效率） - 务必加
processed字段和索引（如INDEX idx_unprocessed (processed, created_at)），否则消费程序扫描全表会越来越慢
用 MySQL Binlog 解析替代轮询，降低延迟与负载
如果对通知实时性要求高（秒级），轮询 notify_queue 表会有延迟和数据库压力。更优方案是监听 MySQL 的 binlog，过滤出目标表+字段变更事件：
- 工具推荐：
maxwell（输出 JSON 到 Kafka/Redis）、canal（阿里开源，支持 HTTP 回调）、或debezium（Kafka Connect 生态） - 配置时指定监控
orders表，并用正则匹配status字段变化（如old.status == "pending" && new.status == "shipped"） - 解析到事件后，直接调用企业微信/钉钉 Webhook、发 MQ、或写入 Redis Stream 触发下游服务
- 注意：需开启 MySQL
binlog_format = ROW且赋予REPLICATION SLAVE权限，DBA 通常对此较敏感，提前沟通
触发器里更新字段引发递归或死锁的典型陷阱
有人想在触发器里直接改同一张表（比如 AFTER UPDATE 中再 UPDATE orders SET notify_sent = 1），这会导致问题：
- MySQL 8.0+ 默认禁止同表递归修改，报错
ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger because it is already used by statement which invoked this stored function/trigger - 即使绕过（如用临时表中转），也可能因事务锁住整行，造成主业务阻塞
- 更隐蔽的坑：触发器里调用存储函数，而该函数又隐式访问了被触发的表，同样触发上述限制
正确做法始终是“只写日志表”，所有副作用（发消息、更新状态字段、调外部 API）交给外部程序统一处理。这条边界划清了，系统才真正可维护。
最容易被忽略的是日志表的清理策略——没人删 notify_queue，半年后它比业务表还大；也没人监控消费延迟，导致订单发货了两小时才推消息。这些运维细节，比写触发器本身重要得多。
