MySQL触发器不支持异步操作，正确做法是触发器写入中间表mq_outbox，再由外部服务轮询投递；或监听binlog实现更可靠的异步通知。
MySQL触发器本身不支持异步操作
直接在 AFTER INSERT 触发器里调用 HTTP 请求、写 Kafka 或发 Redis 消息，MySQL 会报错或卡死——它没有网络 I/O 能力，也不允许执行存储过程以外的外部命令。硬要“推送”，本质是同步阻塞，且不可靠。
真正可行的方案：用触发器写入中间表 + 外部服务轮询
这是生产环境最稳定的做法：触发器只做一件事——把变更数据快速落库；另一个独立服务（比如 Python/Go 进程）持续查这张表，拿到新记录后异步投递到消息队列。
CREATE TABLE mq_outbox (id BIGINT PRIMARY KEY AUTO_INCREMENT, table_name VARCHAR(64), pk_value VARCHAR(128), payload JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, delivered TINYINT DEFAULT 0)- 在业务表的
AFTER INSERT触发器中，仅执行INSERT INTO mq_outbox (table_name, pk_value, payload) VALUES ('orders', NEW.id, JSON_OBJECT('order_id', NEW.id, 'status', NEW.status)) - 外部服务用
SELECT * FROM mq_outbox WHERE delivered = 0 ORDER BY id LIMIT 100批量拉取，成功投递后用UPDATE mq_outbox SET delivered = 1 WHERE id IN (...)标记 - 注意加索引：
INDEX idx_delivered_created (delivered, created_at)，避免全表扫描
为什么不用 MySQL 的 UDF 或外部脚本调用
UDF（如 sys_exec）需要编译安装、权限极高、极易导致 MySQL 崩溃；SHELL 调用在多数云数据库（如阿里云 RDS、AWS RDS）被彻底禁用。即使本地能跑，失败无重试、无事务一致性、无日志追踪，线上等于埋雷。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 触发器内调用
SYS_EVAL或自定义 UDF，MySQL 8.0+ 默认禁用，需设置secure_file_priv和plugin_dir，DBA 通常拒绝开放 - 哪怕调用成功，HTTP 请求超时或 MQ 不可达时，触发器会报错中断，导致主事务回滚——你本意是“异步通知”，结果却拖垮了核心写入
- 没有幂等标记机制，网络抖动可能造成重复投递，而触发器自身无法判断“这条是否已推过”
更现代的替代思路：监听 binlog（推荐用于高一致性场景）
如果对实时性和一致性要求更高，跳过触发器，直接用 Debezium、Maxwell 或 Canal 解析 MySQL binlog，把 INSERT 事件转成消息发到 Kafka/RocketMQ。这种方式不侵入业务逻辑，不增加主库压力，还能精确控制位点和重放。
- 需开启 MySQL 的
binlog_format = ROW和binlog_row_image = FULL - 对比触发器方案，它天然支持多表、更新/删除事件、事务边界识别（BEGIN/COMMIT）
- 缺点是部署复杂度上升，需要额外维护一个 binlog client 服务，小项目可能杀鸡用牛刀
真正难的不是“怎么写触发器”，而是想清楚：你的“异步推送”是否真需要强顺序？失败后要不要告警？消息是否允许延迟 1–2 秒？这些决策比语法细节影响更大。
