不能只靠应用层定时任务处理订单超时，因其高并发查库压力大、分布式需额外协调锁或幂等逻辑、时间不同步易误关单；mysql event+存储过程可将逻辑收束服务端，原子性强且不依赖外部调度。
为什么不能只靠应用层定时任务处理订单超时？
应用层轮询更新 order_status 确实可行，但存在明显短板：高并发下频繁查库压力大、分布式部署时需额外协调锁或幂等逻辑、数据库与业务时间不同步导致误关单。MySQL 存储过程配合事件调度器（EVENT）能将判断和更新收束在服务端，原子性强，且不依赖外部调度系统。
如何用 EVENT + 存储过程组合实现自动关闭？
核心是两步：先写存储过程封装更新逻辑，再创建定时事件周期调用它。注意 MySQL 事件默认是禁用的，必须先开启：
SET GLOBAL event_scheduler = ON;
存储过程示例（假设订单表为 orders，状态字段为 status，创建时间为 created_at，超时阈值为 30 分钟）：
DELIMITER $$
CREATE PROCEDURE close_expired_orders()
BEGIN
UPDATE orders
SET status = 'closed'
WHERE status = 'pending'
AND created_at
-
NOW()是执行时刻时间，不是事件定义时刻，每次触发都实时计算 - 务必加
WHERE status = 'pending'条件，避免重复关闭已变更状态的订单 - 建议在
status和created_at上建联合索引，否则全表扫描会拖慢事件执行
EVENT 创建时最容易被忽略的三个配置项
创建事件不是只写 ON SCHEDULE EVERY 1 MINUTE 就完事。以下三项不显式声明，常导致事件不运行或行为异常：
-
ENABLE：默认是DISABLE，必须显式写ENABLE，否则创建后不会激活 -
ON COMPLETION PRESERVE：默认是NOT PRESERVE，即执行一次就自动删除，必须设为PRESERVE才能持续运行 -
DEFINER：若用低权限账号创建，可能因 DEFINER 用户不存在或无 EXECUTE 权限而失败，建议显式指定为DEFINER = CURRENT_USER
完整事件创建语句：
CREATE EVENT ev_close_expired_orders ON SCHEDULE EVERY 1 MINUTE DO CALL close_expired_orders();
但更稳妥的写法是：
CREATE DEFINER = CURRENT_USER EVENT ev_close_expired_orders ON SCHEDULE EVERY 1 MINUTE ON COMPLETION PRESERVE ENABLE DO CALL close_expired_orders();
上线前必须验证的边界场景
真实电商环境里，这些情况不测清楚，上线后可能批量关错单：
- 订单创建后立刻支付成功（
status变为paid），但事件恰好在状态变更前一秒执行——靠WHERE status = 'pending'能拦住，这是关键防线 - 服务器时间与数据库时间偏差超过 1 分钟，
NOW()值不准，建议统一 NTP 同步，不要依赖系统时钟 - 事件执行期间发生主从延迟，从库查不到刚插入的订单，但这是事件在主库执行，不影响逻辑；真正要防的是主库事务未提交就被事件扫到，所以更新语句本身必须在事务内完成（MySQL EVENT 默认每个调用是独立事务）
复杂点在于：超时规则往往不是固定 30 分钟，可能按支付方式、用户等级动态变化。这时存储过程就得查配置表，而配置表读取失败会导致整个事件中断——得加 DECLARE CONTINUE HANDLER FOR SQLEXCEPTION 做兜底，否则一次失败，后续所有触发都会跳过。
