MySQL SKIP LOCKED 批量领取任务的并发边界

我在把一张待处理表改成多消费者任务队列时，最容易误判的是：SKIP LOCKED 能减少互相等待，却不会自动保证“每个任务只处理一次”、也不会让查询结果保持完整一致。正确用法是把它限定在短事务里，用行锁暂时占住任务，再把领取状态和租约一起写回。

SELECT ... FOR UPDATE SKIP LOCKED 适合“谁先拿到谁处理”的队列式抢占：已被其他事务锁住的行直接从本次结果中排除。要控制重复领取和宕机恢复，必须继续设计状态、租约、重试次数和提交边界。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/innodb-locking-reads.html

下面只讨论 InnoDB 任务表中的批量领取，不把它扩展成通用的并发控制方案。MySQL 手册明确说明，跳过锁定行会得到不一致视图，适合队列类访问，不适合需要完整结果的事务查询。

先把“跳过锁”理解准确

普通的 FOR UPDATE 在遇到别的事务已经锁住的行时会等待；加上 SKIP LOCKED 后，当前查询不会等待，而是把这些行从结果集中排除。它只对行级锁有效，而且锁会持续到当前事务提交或回滚。

因此，两个消费者可能分别看到任务 101、102 和任务 103、104，但某些行被占用时，本轮结果会少于 LIMIT。应用层不能把“返回不足一批”误判成队列彻底空了，更不能用一次查询结果推断全表状态。

领取动作要放在同一段短事务里

一个实用的表至少需要状态、可领取时间和租约时间。领取时先按稳定顺序挑选待处理行，再在同一事务中改成 processing 并写入 lease_until。事务提交后，其他消费者才会看到这批任务已经被占用。

-- 表结构示意：状态和租约用于识别可重试任务
CREATE TABLE job_queue (
    id BIGINT PRIMARY KEY,
    payload JSON NOT NULL,
    status VARCHAR(16) NOT NULL,
    available_at DATETIME NOT NULL,
    lease_until DATETIME NULL,
    attempts INT NOT NULL DEFAULT 0,
    KEY idx_claim (status, available_at, id)
) ENGINE = InnoDB;

-- 领取与改状态必须属于同一个事务，避免读完后才加锁
START TRANSACTION;

SELECT id, payload
FROM job_queue
WHERE status = 'ready'
  AND available_at 

示例中的 UPDATE 不能把“符合条件的前 20 行”重新猜一遍来代替选中集合，否则第二次语句可能遇到不同的可见行。工程实现通常会先把 id 读到应用内，再用参数化的主键集合更新；如果驱动支持在同一事务中读取并更新，也要保持事务边界不变。

批量领取时，四个边界最容易出问题

尤其要注意处理时间和锁持有时间不是一回事。消费者拿到任务后，如果一直在事务里调用外部接口，数据库锁会随外部延迟持续存在，其他消费者只能不断跳过这批行。更稳妥的做法是提交领取事务，随后在处理完成时用带条件的更新确认自己仍持有这次租约。

用租约和幂等把失败变成可恢复

任务处理成功后，可以用 WHERE id = ? AND status = 'processing' AND lease_until >= NOW() 这样的条件更新为 done；超时扫描则把过期的 processing 任务重新放回 ready，同时增加重试记录。这样即使消费者在提交前退出，也有机会被下一轮重新领取。

-- 处理完成时只确认仍在本次租约内的任务
UPDATE job_queue
SET status = 'done', lease_until = NULL
WHERE id = ?
  AND status = 'processing'
  AND lease_until >= NOW();

-- 定时回收过期租约；生产环境还应结合最大重试次数和失败原因
UPDATE job_queue
SET status = 'ready', lease_until = NULL
WHERE status = 'processing'
  AND lease_until 

租约只能降低“永久卡住”的概率，不能替代业务幂等。外部副作用可能已经完成，但消费者还没来得及把状态改成 done，任务重试后仍可能再次调用外部系统，所以订单号、请求号或业务唯一键应参与幂等设计。

哪些查询不该使用 SKIP LOCKED

如果读者需要完整的库存、余额、报表或校验结果，跳过锁定行会让结果缺少一部分数据，此时不应把它当成“更快的普通查询”。它也不适合用来证明所有任务都已被扫描，因为被跳过的行在当前结果中根本不存在。

另外，MySQL 手册提示使用 NOWAIT 或 SKIP LOCKED 的语句对基于语句的复制并不安全。上线前应结合复制方式、事务隔离级别、索引和故障恢复策略评估；文章中的方案只适合作为 InnoDB 队列式抢占的设计起点。

常见问题

为什么一次只拿到 12 条而不是 LIMIT 20？ 另外的任务行可能正被其他事务锁住，SKIP LOCKED 会直接跳过它们；应用应按空批或小批处理，而不是强行补齐。

领取后能不能一直不提交？ 不建议。事务持续时间越长，锁越久，其他消费者越容易频繁跳过同一批任务；领取、改状态、提交应尽量短。

SKIP LOCKED 能保证任务只执行一次吗？ 不能。它解决的是领取时的等待竞争，不能覆盖消费者崩溃、超时重试和外部副作用，仍需要租约与幂等。