mysql触发器中禁止使用sleep()等延迟语句，因其会阻塞事务；应通过应用层异步队列（如rabbitmq/kafka）或event+状态字段兜底实现延迟任务，避免数据库承担非事务性职责。
MySQL触发器里不能用 SLEEP() 或延迟语句
MySQL 触发器是同步执行的，且运行在事务上下文中——这意味着它必须立刻完成，否则会阻塞整个 INSERT/UPDATE/DELETE 操作。你写 SLEEP(5) 或尝试调用存储过程模拟延迟，都会让当前事务卡住 5 秒，所有并发写入跟着排队，线上基本不可接受。
常见错误现象：ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger —— 因为 MySQL 禁止在触发器里做任何可能隐式提交的操作，而多数“延迟”方案（比如插入延迟队列表后靠事件轮询）容易误触事务边界。
- 触发器中禁止调用含
COMMIT、ROLLBACK、CREATE TABLE、DROP TABLE的逻辑 -
SELECT ... INTO OUTFILE、LOAD DATA等 I/O 类操作也不允许 - 哪怕只是想“记个日志等会儿再处理”，也得跳出触发器本身来设计
替代方案：用业务层发消息到异步队列（推荐）
真正可行的做法，是把“需要延迟做的事”从数据库层剥离，交由应用代码或中间件承接。比如用户注册后 10 分钟发欢迎邮件，触发器不干这事，而是由应用在插入 users 表后，往 RabbitMQ/Kafka/Redis Stream 里丢一条带时间戳的消息。
使用场景：定时通知、积分延时发放、风控二次校验、缓存预热等所有“非强实时 + 需要失败重试”的任务。
- 避免数据库承担非事务性职责，降低锁竞争和慢查询风险
- 消息队列天然支持延迟投递（如 RabbitMQ 的
x-delay插件、Kafka 配合 timing-wheel 实现） - 失败可重试、可监控、可人工干预，比藏在触发器里的逻辑健壮得多
如果非要在 DB 层搞，用 EVENT + 状态字段兜底
MySQL 原生不支持触发器延迟，但可以用 EVENT 定时扫描 + 状态字段组合模拟。例如：触发器只更新一条记录的 status 和 execute_at，再配一个每分钟跑一次的 EVENT，查出 execute_at 且 <code>status = 'pending' 的行来批量处理。
性能与兼容性影响：MySQL 5.7+ 支持 EVENT，但需确认 event_scheduler = ON；高频扫描大表会加重 I/O，务必加复合索引（如 (status, execute_at)）。
- 不要在 EVENT 中直接修改被触发器刚操作的同一张表，容易引发死锁或幻读
- 处理逻辑尽量轻量，复杂计算或外部调用仍建议移交应用层
- 记得在 EVENT 执行完后更新
status，避免重复执行
别碰 MySQL UDF 或外部脚本调用
有人想通过自定义函数（UDF）调用系统命令或 Python 脚本实现异步，这条路极其危险。MySQL 进程以高权限运行，UDF 一旦有内存泄漏或崩溃，直接拖垮整个实例；而且 UDF 不受事务控制，失败无法回滚，和触发器初衷完全相悖。
常见错误现象：MySQL 进程异常退出、ERROR 2013 (HY000): Lost connection to MySQL server during query、审计日志里出现大量 system() 调用痕迹。
- MySQL 官方已明确不推荐生产环境使用 UDF 做业务逻辑
- 即使成功调起外部进程，也无法保证它真能执行完——网络抖动、磁盘满、目标服务宕机都无感知
- DBA 通常会在初始化时禁用
sys_exec等危险函数，上线前就卡住
