MySQL 行锁队列怎样用跳过锁实现取件

我第一次把数据库表当作轻量任务队列时，最容易踩的坑不是 SQL 写不出来，而是多个 worker 都盯着最前面的几行，结果后来的 worker 一直等前一个事务释放锁。对于“谁先拿到谁处理”的队列，已被占用的行本来就可以暂时让开，这正是 SKIP LOCKED 的用武之地。

一句话先说清：在 InnoDB 短事务中用 SELECT ... FOR UPDATE SKIP LOCKED 按顺序挑出少量待处理任务，已被别的事务锁住的行会从结果集中跳过；接着在同一事务里把状态改成 processing 并提交。它适合队列取件，不适合要求完整一致视图的普通业务查询。

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

下面的 SQL 都是原创说明示例，结果为语义推导，不代表本文制作过程中在本机执行过。

普通取件为什么会互相等待

假设有一张 InnoDB 任务表，status = 'queued' 表示还没有被领取。普通的 FOR UPDATE 会锁住搜索遇到的记录；如果第一条符合条件的任务已经被 Worker A 锁住，Worker B 通常会等待，而不是自动跳到下一条。

START TRANSACTION;

SELECT id, payload
FROM job_queue
WHERE status = 'queued'
ORDER BY id
LIMIT 1
FOR UPDATE; -- 普通锁定读：遇到已锁行可能等待

如果任务处理本身还要访问外部服务，持锁时间就会跟着网络延迟一起变长。我在排查这类队列时，会先把“等待”与“没有任务”分开看：前者是锁竞争，后者才是队列真的为空。把等待误判成空队列，会让 worker 数量越加越慢。

最小配方：用 SKIP LOCKED 取一批任务

最小改动是在锁定读末尾加上 SKIP LOCKED。它不会等待已经被其它事务锁住的行，而是返回当前能拿到的行。配合 ORDER BY id 和小批量 LIMIT，每个 worker 都能拿到一组候选任务。

START TRANSACTION;

SELECT id, payload
FROM job_queue
WHERE status = 'queued'
ORDER BY id
LIMIT 10
FOR UPDATE SKIP LOCKED; -- 已锁行直接跳过，不让当前 worker 等待

UPDATE job_queue
SET status = 'processing',
    claimed_at = CURRENT_TIMESTAMP
WHERE id IN (101, 102, 105); -- 应替换为本次 SELECT 实际拿到的主键

COMMIT; -- 尽快提交，释放本次领取持有的行锁

真正的应用代码应使用参数绑定传入主键列表，不能把示例里的数字直接拼接到 SQL。这里故意把领取和状态更新放在同一事务里，保证“看见并锁住的任务”不会在更新前被另一个 worker 抢走。

注意，SKIP LOCKED 返回的是不一致视图：它可能漏掉此刻正被其它事务占用的任务。对队列来说这通常是“稍后再取”，而不是数据错误；对余额、库存汇总或需要完整集合的查询，就不应把它当成通用优化开关。

关键细节：领取事务不要包住慢业务

取件事务的职责是定位任务、占住任务、更新状态和提交，不应该在事务里调用 HTTP、执行长时间文件处理或等待人工操作。任务进入 processing 后，真正的业务处理可以在事务外进行；这样其它 worker 只会跳过已领取的行，不会被一段慢处理拖住。

START TRANSACTION;

SELECT id, payload
FROM job_queue
WHERE status = 'queued'
ORDER BY id
LIMIT 10
FOR UPDATE SKIP LOCKED; -- 只在队列领取阶段持有锁

UPDATE job_queue
SET status = 'processing',
    worker_id = 'worker-a',
    claimed_at = CURRENT_TIMESTAMP
WHERE id IN (101, 102, 105); -- 绑定本次领取的任务主键

COMMIT; -- 先释放锁，再在事务外处理 payload

为了让故障可恢复，状态表还应有超时回收策略：例如由后台任务把长时间停留在 processing 的记录重新置回 queued，或增加重试次数与错误原因。这个回收策略属于业务设计，不能指望 SKIP LOCKED 自动完成。

变体：NOWAIT 和 SKIP LOCKED 怎么选

我通常把这两个选项当成两种不同的产品语义，而不是简单的性能参数。NOWAIT 遇到已锁行会立即报错，适合调用方必须知道“资源当前不可用”的场景；SKIP LOCKED 会把已锁行从结果中排除，适合多个 worker 争抢队列。

官方说明还指出，这两个选项只作用于行级锁；使用锁定读前要确保自动提交已关闭，并在事务提交或回滚时释放锁。若表没有合适索引，扫描范围和锁竞争也可能比预期更大，所以状态、排序列和主键的索引设计仍然要单独检查。

完整片段：把领取骨架交给应用层

下面这段把前面的关键点放在一起：先稳定排序，再跳过已锁行，更新状态后立即提交。实际项目中应让应用层读取返回的主键并绑定参数，同时记录 worker 标识，便于超时回收和问题追踪。

START TRANSACTION;

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

如果本次没有返回行，应用可以短暂退避后再次取件；不要把“本次没取到”直接当成队列永久为空。若处理失败，则由应用记录错误并依据重试策略回收任务；若 worker 崩溃，超时扫描再把过期的 processing 任务放回可领取状态。

复查这类队列 SQL 的清单

• 表是否使用 InnoDB，任务是否有稳定主键和明确状态。
• 领取查询是否有稳定的 ORDER BY，批量大小是否足够小。
• 是否在同一个短事务里完成锁定和状态变更，并及时提交。
• 是否接受 SKIP LOCKED 暂时漏看已锁行的语义。
• 是否有 processing 超时回收、失败重试和 worker 追踪字段。
• 是否把慢业务、外部请求和大批量更新错误地放进持锁事务。

最后的判断很简单：如果任务可以稍后再取，优先用 SKIP LOCKED 让并发 worker 各取各的；如果冲突必须立刻告诉调用方，考虑 NOWAIT；如果业务要求完整一致的锁定集合，就继续使用普通锁定读，并把事务等待纳入设计。

两个容易混淆的问题

用了 SKIP LOCKED，是不是所有任务都一定会被按顺序处理？ 不是。它只保证当前事务不等待已锁行；多个 worker 并发取件时，具体顺序还受到锁竞争、提交时间和回收策略影响。

能不能把 SKIP LOCKED 当成分布式锁？ 不建议。它解决的是同一个 InnoDB 表中锁定读的等待策略，任务租约、超时、重试、幂等和跨服务协调仍需要应用层明确设计。