核心是用created_at与数据库服务器时间比对，过滤中间态订单（如pending、confirmed、paying），排除已完成/已取消状态，并加for update锁；存储过程需显式事务控制、row_count()校验及原状态条件更新，避免并发误操作。
怎么判断订单是否过期并需要取消
核心是用 ORDER BY created_at 和当前时间比对，但别直接写 NOW() —— 多数生产环境要求用数据库服务器时间（避免应用层时区不一致），且必须考虑订单状态过滤。常见错误是只查 status = 'pending'，漏掉 'confirmed' 或 'paying' 等中间态，结果该取消的没取消。
- 过期条件建议统一为：
created_at （按业务调，30分钟只是示例） - 必须排除已发货、已完成、已取消的订单：
WHERE status IN ('pending', 'confirmed', 'paying') - 加
FOR UPDATE锁住行，防止并发修改导致重复处理
存储过程里怎么安全更新订单状态
不能裸写 UPDATE orders SET status = 'cancelled' ...，否则可能误更新或丢失数据。MySQL 存储过程中要显式控制事务，并检查影响行数。
- 开头加
START TRANSACTION，结尾配COMMIT或ROLLBACK - 用
ROW_COUNT()判断是否真有订单被更新：IF ROW_COUNT() > 0 THEN ... - 更新时带上原状态条件，避免覆盖其他进程刚改的状态：
SET status = 'cancelled' WHERE id = ? AND status IN ('pending', 'confirmed', 'paying')
为什么不能只靠定时任务触发存储过程
单纯靠 EVENT 每分钟执行一次 CALL cancel_expired_orders() 很危险：如果上一次执行卡住或超时，下次会并发进入，导致同一订单被多次取消；更糟的是，MySQL EVENT 默认不支持跨会话锁，也无重试机制。
- 推荐用外部调度器（如 Linux
cron调mysql -e "CALL cancel_expired_orders();"），并加文件锁或标记表防重入 - 若坚持用
EVENT，必须在过程开头插入一条带唯一时间戳的记录到job_lock表，并用INSERT IGNORE做幂等校验 -
EVENT的ON SCHEDULE EVERY 1 MINUTE实际执行间隔可能漂移，高负载下甚至跳过某次
取消订单时还要同步做什么
只改 orders.status 是半截子操作。真实电商系统里，过期取消必须联动释放库存、回滚优惠券、通知用户——这些不能塞进存储过程里做，否则事务太长、耦合太重、失败难回滚。
- 存储过程只负责原子性地锁定并标记订单为
'cancelled'，返回被更新的order_id列表 - 应用层轮询或监听
orders表的变更（如通过 binlog 或定时查WHERE status = 'cancelled' AND handled = 0），再异步处理后续动作 - 务必给
orders表加复合索引：INDEX idx_status_created (status, created_at)，否则每次扫描全表
真正麻烦的不是写 SQL，而是状态一致性边界——比如库存扣减用了 Redis，订单状态在 MySQL，两者怎么对齐。这部分没法靠一个存储过程兜底，得靠补偿机制和明确的最终一致约定。
