触发器无法直接调用外部 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
);
<p>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)
);</p><p>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 = FULLDebezium 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 失败都发生在触发器范围之外，必须由独立服务兜底。
