触发器适合“数据一变就响应”的场景，如订单插入时立即写审计日志，或用户禁用时同步删除token；必须与主事务原子绑定，仅做轻量操作，严禁耗时、外部调用或聚合计算。
触发器适合“数据一变就响应”的场景
比如订单表 orders 插入一条新记录，你立刻要往审计表 audit_log 写入操作人、时间、IP；或者用户表 users 的 status 字段被更新为 'disabled'，你得同步把关联的 token 表里对应记录删掉。这类动作必须和主事务原子性绑定——要么一起成功，要么一起回滚。AFTER INSERT 或 BEFORE UPDATE 就是干这个的。
常见错误现象：INSERT INTO orders 成功了，但触发器里写日志失败，导致主事务也回滚；或者在 BEFORE 触发器里改了 NEW.price 却忘了判断空值，结果插入 NULL 导致后续报错。
- 只用
NEW和OLD访问当前行数据，别查其他大表 - 避免在触发器里调用存储过程以外的外部服务（如 HTTP 请求、发邮件）
- 别在触发器里做聚合计算（如“每插一笔就重算当日总销售额”），会拖慢写入
定时任务适合“按时间规律执行”的维护类操作
比如每天凌晨 2 点清空 logs 表中 7 天前的数据，或每小时刷新一次物化视图 sales_summary。这类任务不依赖某次 DML，而是靠时间驱动，且允许失败后重试、延迟执行、留日志——触发器完全不提供这些能力。
MySQL 用 EVENT，PostgreSQL 用 pg_cron，SQL Server 用 SQL Server Agent。它们都支持启用/禁用、查看运行状态、设置失败告警。
- MySQL 必须先确认
event_scheduler是ON，否则所有CREATE EVENT都静默失效 -
DO块里不能有SELECT返回结果集，要用INSERT ... SELECT或写日志表替代 - 事件默认启用，加
DISABLE才能创建后不立即跑
两者混用时，关键在“解耦”和“轻量交接”
真实系统里常组合使用，但必须划清边界：触发器只做最轻量的标记或落日志，调度器负责批量处理。比如电商订单库，AFTER INSERT 触发器只往 order_pending_sync 表里插入一条带 order_id 和 created_at 的记录；然后一个每 5 秒执行一次的 EVENT 扫描这张表，批量把待同步订单推到 Kafka。
容易踩的坑：BEFORE UPDATE 触发器里直接调用 CALL sync_to_erp(@order_id)，而这个存储过程内部又去远程接口拉数据——这会让主事务卡住几秒甚至超时。
- 触发器只写、不读（除非极小范围校验）、不调外部
- 调度任务读取触发器写入的中间表，而不是直接查业务主表
- 中间表要有索引（如
(status, created_at)），不然调度器扫描太慢
别让触发器“假装能定时”
有人在 AFTER INSERT 里写 SLEEP(3600) 再执行逻辑，或用递归方式调用自身模拟延时——这既不可靠（连接可能中断），又破坏事务语义，还让数据库线程阻塞。MySQL 的 EVENT、PostgreSQL 的 cron.schedule()、SQL Server 的作业调度器，才是唯一正途。
真正难处理的是“既要即时又要定时”的混合需求，比如“新订单 10 秒内未支付就自动取消”。这种得靠外部消息队列 + TTL，或者用调度器高频轮询（如每 5 秒查一次 status = 'pending' 且 created_at 的订单），而不是硬塞进触发器。
