SQL触发器不能自动关闭过期业务记录，因其仅响应INSERT/UPDATE/DELETE等显式DML事件，不感知系统时钟变化，无法在数据自然过期瞬间执行动作；BEFORE UPDATE中判断expire_at < NOW()仅拦截本次更新，不影响已过期但未被修改的记录，也无法实现定时扫描与状态更新。
SQL 触发器不能自动关闭过期业务记录——它不响应时间变化，只响应 INSERT、UPDATE、DELETE 这类显式操作。你写一个 BEFORE UPDATE 里判断 expire_at < NOW()，只能拦住这次更新，不会让“已存在但过期”的记录变状态，更不会定时扫表改数据。
为什么触发器里判断 expire_at
常见错误是以为在 BEFORE INSERT 或 AFTER UPDATE 里加个时间判断就能“自动关掉过期记录”。实际问题很直接：
-
NOW()在触发器中返回的是语句开始时刻的时间戳，同一批操作所有行看到的值都一样，无法支撑秒级过期判定 - 触发器不监听时钟，也不会因为某行
expire_at到了就自己跑一次 - 如果真在触发器里写
UPDATE或DELETE同一表（比如“过期就设 status='closed'”），会触发ERROR 1442：Can't update table 'xxx' in stored function/trigger because it is already used... - 即使绕过报错（比如用存储过程间接调），也会把业务 SQL 响应拖慢，事务变长，锁更多行
MySQL 中真正能“自动关闭”的可行路径
必须拆开责任：应用层负责写入时带 expire_at，查询时主动过滤；数据库侧用 EVENT 定期更新状态，而非依赖触发器。
- 确保
event_scheduler已开启：SET GLOBAL event_scheduler = ON（或写进my.cnf） - 给执行用户授
EVENT权限：GRANT EVENT ON *.* TO 'app_user'@'%' - 建事件示例（每 5 分钟把过期 pending 订单关掉）：
CREATE EVENT close_expired_orders ON SCHEDULE EVERY 5 MINUTE DO UPDATE orders SET status = 'closed' WHERE status = 'pending' AND expire_at < NOW();
- 关键点：
WHERE必须包含当前状态约束（如status = 'pending'），否则重复执行会反复更新已关记录 - 性能兜底：在
(status, expire_at)上建联合索引，避免全表扫描
PostgreSQL / SQLite / 云数据库怎么处理
这些环境没有 EVENT，硬套 MySQL 语法会直接报错 syntax error near 'EVENT'。
- PostgreSQL：别折腾
pg_cron扩展（编译麻烦、升级易崩），用系统cron+psql -c "UPDATE ..."更稳 - SQLite：完全无定时能力，只能由应用层轮询或外部进程驱动
- 阿里云 RDS、AWS RDS：默认禁用
event_scheduler，得去控制台手动开启或提工单申请权限 - 所有方案都要注意时区：
NOW()返回的是数据库 server 的time_zone，不是系统时区，必要时用CONVERT_TZ(NOW(), '+00:00', '+08:00')校准
真正容易被忽略的不是语法，而是时间精度和事务边界：MySQL EVENT 每次在独立事务中执行，但如果 UPDATE 影响几十万行，仍可能锁表、阻塞写入——所以高频业务表必须加 LIMIT 并配合分批逻辑，而这个，触发器和 EVENT 都做不到，得靠外部脚本或存储过程兜底。
