MySQL 8.0 事件调度器做库存预占回收：幂等更新、锁边界与验收

订单表里经常有一类容易被忽略的脏数据：库存已经扣减，但付款超时后没有及时归还。把回收逻辑塞进应用定时任务当然能跑，不过部署多个实例后容易重复扫表，任务挂掉也很难及时发现。这套方案把回收动作放到 MySQL 8.0 的事件调度器里，只处理仍是 reserved 且已过期的记录，更新本身自带状态条件，就算重复触发也不会把已支付订单改坏。

先把库存预占模型收敛到三张表

示例使用一个商品库存表和一张预占记录表。订单表只保留业务关联，回收任务不需要读取订单详情，这样它的扫描范围更容易控制。

CREATE TABLE inventory_stock (
  sku_id BIGINT PRIMARY KEY,
  available_qty INT NOT NULL,
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
    ON UPDATE CURRENT_TIMESTAMP
);

CREATE TABLE stock_reservations (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL,
  sku_id BIGINT NOT NULL,
  quantity INT NOT NULL,
  status ENUM('reserved', 'paid', 'released') NOT NULL,
  expires_at DATETIME NOT NULL,
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  KEY idx_reclaim (status, expires_at, id),
  KEY idx_order (order_no)
);

idx_reclaim 不是为了让所有查询都变快，而是给回收任务一个稳定的候选取数顺序。把 id 放在末尾，是为了分页或批量取数时有确定的边界。

用一条状态条件保证回收幂等

创建预占时，应用先在事务里减少 inventory_stock.available_qty，再插入 reserved 记录。超时回收时反过来加回库存，并把记录标为 released。核心逻辑不是“扫到了就加库存”，而是只有从 reserved 成功变更为 released 的记录才允许加一次库存。

START TRANSACTION;

UPDATE stock_reservations
SET status = 'released'
WHERE id = 12001
  AND status = 'reserved'
  AND expires_at 

生产实现需要把“状态更新”和“库存归还”放在同一个事务中，并记录影响行数。若状态更新影响行数为 0，说明这条记录已经支付、已经回收，或是还没到期；这时不能再次增加库存。

把回收事件限制在短事务范围内

事件调度器只负责按周期触发 SQL 执行。真正的边界逻辑写在存储过程里：每次取 100 条候选记录，逐条在短事务中完成状态更新与库存归还。这里不建议一口气把全部历史过期记录锁住，订单高峰时段会把普通库存更新也拖慢。

DELIMITER //

CREATE PROCEDURE reclaim_expired_reservations()
BEGIN
  DECLARE finished INT DEFAULT 0;
  DECLARE reservation_id BIGINT;
  DECLARE cur CURSOR FOR
    SELECT id
    FROM stock_reservations
    WHERE status = 'reserved'
      AND expires_at 

光标拿到的只是候选 ID，不代表执行真正更新时这条记录仍然符合条件，所以更新语句会再次校验状态和过期时间。这个重复条件是特意设计的：它把并发支付、手工回收和自动回收之间的竞争，压缩成一次影响行数判断。

创建事件并确认它正常运行

SET GLOBAL event_scheduler = ON;

CREATE EVENT ev_reclaim_expired_reservations
ON SCHEDULE EVERY 1 MINUTE
STARTS CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
ON COMPLETION PRESERVE
ENABLE
DO CALL reclaim_expired_reservations();

在托管 MySQL 服务上，SET GLOBAL 可能被默认禁止，需要通过实例参数打开事件调度器权限。创建完成后先核对事件定义，再查看任务产生的审计记录；只确认事件状态为 ENABLED 是不够的。

SHOW VARIABLES LIKE 'event_scheduler';
SHOW EVENTS LIKE 'ev_reclaim_expired_reservations';
SELECT id, order_no, status, expires_at
FROM stock_reservations
ORDER BY id DESC
LIMIT 10;

用一组固定测试数据验收结果

测试时准备同一个 SKU 的三条记录：一条已过期预占、一条未过期预占、一条已支付记录。执行事件后，只有第一条应该变成 released，库存也会增加对应的数量。

重复触发一次后，再运行后续校验逻辑。第一条记录的状态不会发生变化，库存也不会再次增加。如果库存数量第二次仍然变动，说明归还动作没有和状态跃迁逻辑绑定。

SELECT status, COUNT(*) AS total
FROM stock_reservations
WHERE order_no IN ('ORD-12001', 'ORD-12002', 'ORD-12003')
GROUP BY status;

SELECT sku_id, available_qty
FROM inventory_stock
WHERE sku_id = 90001;

SELECT id, status, expires_at
FROM stock_reservations
WHERE status = 'reserved'
  AND expires_at 

几个容易导致回收任务失控的边界

• 批量不是越大越好：100 条只是参考值，应该结合单条事务耗时和库存写热点情况调整。
• 不要用应用时间代替数据库时间：筛选条件和状态更新都用同一个数据库的 NOW()，避免多台应用服务器时钟漂移引发的异常。
• 多库要指定唯一责任方：读写分离部署时，事件必须建在主库；分库场景要明确哪个分片拥有回收权限。
• 失败情况要可观测：给过程增加回收批次、失败数量和最后运行时间记录，不能只依赖 MySQL 自带的事件列表做监控。

常见问题

事件调度器每分钟执行一次，会不会重复归还库存？

只要库存更新前执行一次带 status = 'reserved' 的条件更新，并且只在影响行数为 1 时执行归还动作，就不会因为重复触发再次增加库存。

为什么事件显示 ENABLED，但过期记录没有变化？

先检查 event_scheduler 是否为 ON，再确认事件所在数据库、过程权限和候选查询是否能找到符合条件的数据。托管实例还要检查参数组是否允许开启事件调度器。

能不能直接把所有过期记录一次性更新？

小表可以临时这样处理，生产环境的业务表更适合按 ID 顺序分批执行，缩短锁持有时间，也给失败重试留下明确的操作边界。

小结：先守住状态跃迁，再调整运行周期

库存预占回收的核心不是把事件改成更高频，而是把“仍可回收”的状态条件、库存归还和事务边界写成一个不可重复的原子动作。先用三条测试数据验证状态和数量逻辑，再观察批次耗时、锁等待与失败记录，最后才决定是一分钟还是五分钟执行一次。这样就算任务偶尔重跑，也只是再次执行检查，不会把库存多加一遍。