当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL SKIP LOCKED 批量领取任务的并发边界

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

来源：17golang原创 2026-11-13 12:24:57 0浏览收藏

我在把一张待处理表改成多消费者任务队列时，最容易误判的是：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 后，当前查询不会等待，而是把这些行从结果集中排除。它只对行级锁有效，而且锁会持续到当前事务提交或回滚。

MySQL SKIP LOCKED 在任务队列中连接消费者、行锁和待处理任务的静态结构图 — 图1：结构说明图，查看消费者、任务行锁与可领取集合之间的边界；这不是运行截图或执行证据。

因此，两个消费者可能分别看到任务 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 读到应用内，再用参数化的主键集合更新；如果驱动支持在同一事务中读取并更新，也要保持事务边界不变。

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

边界	实际影响	处理方式
返回数量	锁定行被跳过后可能少于 LIMIT	把空批次当作“本轮没有可见任务”，按退避重试
排序与索引	扫描范围不稳定会让领取顺序难以预期	使用 available_at、id 的稳定排序和匹配索引
提交时机	处理业务期间长时间持锁会放大冲突	领取事务只做选取和状态变更，处理逻辑放到提交后
消费者崩溃	任务可能停留在 processing	用 lease_until 定期回收，并限制 attempts

MySQL 任务队列表、状态字段、租约字段和消费者处理边界的静态关系图 — 图2：关系说明图，查看 ready、processing、lease_until、attempts 与消费者之间的静态关系；这不是运行截图或运行结果。

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

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

任务处理成功后，可以用 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，任务重试后仍可能再次调用外部系统，所以订单号、请求号或业务唯一键应参与幂等设计。