SQL触发器不能定时执行，其本质是响应数据变更事件；所谓“定时触发”实为外部调度更新控制表后由触发器响应，而非触发器自身具备定时能力。
SQL触发器本身不能定时执行
触发器（TRIGGER）是响应 INSERT、UPDATE、DELETE 等数据变更事件而自动运行的，它没有内置的「定时」能力。所谓“定时触发”，本质是外部调度驱动数据变更，再由触发器响应——不是触发器在定时，而是有人在定时改表。
常见错误是试图在触发器里写 SLEEP() 或调用系统时间函数做轮询，这不仅无效（MySQL 禁止触发器内含非确定性/耗时操作），还会阻塞事务、拖垮性能。
用定时更新状态表来间接触发业务逻辑
核心思路：建一张轻量级状态控制表（如 job_schedule），由外部定时任务（如 cron / Windows Task Scheduler / pg_cron / SQL Server Agent）定期更新其某字段（如 last_run 或 status），触发器监听该表变化，执行下游动作。
CREATE TABLE job_schedule (id TINYINT PRIMARY KEY DEFAULT 1, last_run DATETIME, status ENUM('pending','running','done'));- 定时任务每 5 分钟执行一次：
UPDATE job_schedule SET last_run = NOW(), status = 'pending' WHERE id = 1; - 触发器绑定在该表上：
CREATE TRIGGER trig_on_schedule AFTER UPDATE ON job_schedule FOR EACH ROW BEGIN ... END; - 触发器体内可调用存储过程处理真实业务（如归档旧数据、发通知、更新统计表），但必须快——超时或报错会导致 UPDATE 事务失败。
MySQL / PostgreSQL / SQL Server 的关键差异点
不同数据库对触发器能力限制差别很大，直接影响能否落地：
- MySQL：支持
AFTER UPDATE，但禁止在触发器中修改触发它的表（即不能在job_schedule的触发器里再UPDATE job_schedule），也不能调用含事务控制的存储过程；适合做轻量通知或写日志表。 - PostgreSQL：支持
pg_cron扩展直接调度 SQL，更推荐绕过触发器，直接用SELECT ... INTO TEMP+INSERT/UPDATE完成闭环；若坚持用触发器，可用NOTIFY配合监听程序解耦。 - SQL Server：支持
INSTEAD OF和更灵活的上下文判断（如IF UPDATE(last_run)），但要注意 Service Broker 或 SQL Agent 调度比触发器更稳定，尤其涉及跨库或远程调用时。
真正需要定时+自动化的场景，优先用数据库原生调度器
除非已有强约束必须走触发器路径（例如审计合规要求所有动作必须经 DML 触发），否则应避开“用触发器模拟定时”的设计：
- MySQL 8.0+ 可启用
event_scheduler，用CREATE EVENT直接跑定时 SQL，无依赖、易监控。 - PostgreSQL 推荐
pg_cron（需扩展安装）或pgAgent，支持失败重试、日志跟踪。 - SQL Server 原生
SQL Server Agent是工业级方案，能连作业、步骤、警报、通知全链路。 - 所有这些方案都比“定时改一个字段再靠触发器转发”少一层故障点，也更容易查问题——比如发现没执行，直接看调度器日志，而不是去翻触发器是否被禁用、事务是否被回滚、是否被死锁卡住。
触发器适合反应式逻辑，不是调度器替代品。把定时职责还给调度器，把响应职责留给触发器，边界划清了，维护成本才真的降下来。
