17370845950

MySQL触发器无法调用外部HTTP接口，因内核层不支持网络I/O；正确做法是触发器仅写入outbox表，由外部服务异步消费并调用API，确保事务原子性与幂等性。

触发器无法直接调用外部 HTTP 接口

MySQL 触发器（TRIGGER）运行在服务端内核层，不支持 curl、HTTP 请求 或任何阻塞式 I/O 操作。试图在 BEFORE INSERT 或 AFTER UPDATE 中调用外部 API 会直接报错：ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA（即使绕过该限制，底层也无网络能力）。

常见误操作包括：尝试用 sys_exec()（需加载非官方插件）、调用自定义 UDF（不稳定且权限风险高）、或在触发器里写 SELECT ... INTO OUTFILE 再靠定时脚本轮询——这些方案线上环境基本不可控。

• 真正可行的路径只有一条：把「触发动作」转为「可异步消费的消息」
• 触发器本身只做轻量级写入，比如往一张 outbox 表插入记录
• 由独立服务（Python/Go 进程、Flink 任务或消息队列消费者）监听这张表的变化并发起外部调用

用 outbox 表 + 轮询实现可靠集成

这是最轻量、兼容性最强的方案，无需升级 MySQL 版本，也不依赖 Binlog 解析能力。核心是让触发器只负责写，不负责发。

示例场景：用户表 users 更新后，需同步昵称到企业微信通讯录。

CREATE TABLE users (
  id INT PRIMARY KEY,
  nickname VARCHAR(50),
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
CREATE TABLE outbox (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
event_type VARCHAR(32) NOT NULL,      -- 'user_updated'
payload JSON NOT NULL,                -- {"user_id": 123, "nickname": "张三"}
status ENUM('pending', 'sent', 'failed') DEFAULT 'pending',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_status_created (status, created_at)
);
DELIMITER $$
CREATE TRIGGER after_users_update_outbox
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.nickname != NEW.nickname THEN
INSERT INTO outbox (event_type, payload)
VALUES ('user_updated', JSON_OBJECT('user_id', NEW.id, 'nickname', NEW.nickname));
END IF;
END$$
DELIMITER ;

• 触发器不处理重试、超时、鉴权，只保证事件写入原子性（与主事务同提交）
• 外部服务用 SELECT ... FOR UPDATE SKIP LOCKED 安全消费，避免重复处理
• payload 字段存 JSON，便于扩展字段；不要存大文本或二进制，避免拖慢主表写入

替换方案：用 MySQL 8.0+ 的事件通知机制（如 binlog + Debezium）

如果已有 Kafka 或 Flink 基础设施，且业务允许秒级延迟，推荐跳过触发器，直接从 binlog 捕获变更。这比 outbox 更解耦，也更实时。

关键点：

• MySQL 必须开启 binlog_format = ROW 和 binlog_row_image = FULL
• Debezium Connector 配置监听 users 表，输出变更事件到 Kafka topic
• 下游消费者解析 after.nickname 字段，调用企业微信 API
• 失败时可重放 offset，无需维护 outbox.status 状态机

缺点是部署复杂度上升，且对 MySQL 权限要求更高（需 REPLICATION SLAVE, REPLICATION CLIENT）。

别忽略事务边界和幂等性设计

无论用 outbox 还是 binlog，外部系统调用失败后，必须能安全重试。MySQL 本身不提供「触发器级事务回滚后自动撤回已发出的 HTTP 请求」的能力。

• 所有对外接口必须设计为幂等：例如企业微信更新成员接口带 version 或用 upsert 语义
• outbox 表的 status 字段要配合 updated_at 和重试次数，防止无限循环
• 不要在触发器里写日志文件或调用存储过程封装 HTTP —— 这类行为在 MySQL 重启或主从切换后极易丢失上下文

最常被忽视的是：以为触发器「执行成功」就等于外部系统已收到数据。实际上，网络抖动、目标服务 503、DNS 失败都发生在触发器范围之外，必须由独立服务兜底。