触发器同步执行会阻塞主线程，导致客户端超时；其运行在事务上下文中，耗时操作必须剥离至应用层异步、消息队列或定时任务处理。
触发器执行阻塞主线程，客户端等待超时
MySQL 触发器在 BEFORE 或 AFTER 事件中同步执行，且运行在客户端连接的同一事务上下文中。这意味着：只要触发器里的逻辑没跑完，整个 SQL 语句就卡住不返回，客户端也就一直挂着等响应。如果触发器里做了 HTTP 请求、文件读写、复杂计算或调用外部 API，哪怕只耗时 3 秒，而客户端设置的 connection-timeout 是 2 秒，就会直接断开——报错通常是 MySQL server has gone away 或 timeout exceeded，但根源不是网络断了，是服务端“卡死”了。
wait_timeout 和 interactive_timeout 不救触发器里的慢操作
很多人以为调大 wait_timeout 就能解决，其实这是误解。这个参数只控制“空闲连接”被服务器主动关闭的时间，而触发器执行期间连接是“活跃”的（正在跑 SQL），wait_timeout 完全不生效。真正起作用的是客户端侧的超时配置：
-
connect_timeout：建立 TCP 连接阶段的超时（通常影响不大） -
interactive_timeout/wait_timeout：对空闲连接有效，对正在执行的语句无效 -
net_read_timeout和net_write_timeout：控制服务器读取/发送数据包的单次等待上限，但触发器执行属于“内部处理”，也不走这条路
换句话说：MySQL 本身没有“单条 SQL 执行超时”机制，它默认会一直等下去，直到客户端先放弃。
替代方案：把耗时逻辑移出触发器
触发器只适合轻量、确定、毫秒级完成的动作（比如字段自动补全、简单校验）。任何可能变慢的操作都必须剥离。常见做法有：
- 用应用层异步任务承接：例如 Dify 中用
go func()启动协程，或 Python 用celery/asyncio.create_task() - 改用消息队列解耦：INSERT 后发一条 Kafka/RabbitMQ 消息，由独立消费者处理后续逻辑
- 用定时任务兜底：把待处理记录写入一张
pending_tasks表，由后台 Job 每 30 秒扫一次
强行在触发器里加 SLEEP(1) 或调用 sys_eval()（如果启用）只会让问题更隐蔽——它不会报错，但会让所有依赖该表的写入操作集体变慢，最终拖垮整个业务链路。
容易被忽略的连锁反应
一个慢触发器引发的问题往往不止超时本身：
- 事务持有时间拉长 → 行锁/表锁堆积 → 其他查询被阻塞
- 连接池被占满（尤其 HikariCP 的
maximum-pool-size设得小）→ 新请求排队或拒绝 - 如果触发器还写了日志到磁盘或远程服务 → IO 或网络抖动会进一步放大延迟
- 监控指标（如 MySQL 的
Slow_queries）可能不统计触发器内部耗时，导致性能问题“不可见”
最麻烦的是：你查 SHOW PROCESSLIST 只能看到 Query 状态卡在那条 INSERT 上，根本看不到“它正在触发器里干啥”，得靠堆栈或日志埋点才能定位到真实瓶颈点。
