MySQL 事务里 SKIP LOCKED 为什么会跳过未提交任务

在订单、邮件或异步作业表里，消费者常用 SELECT ... FOR UPDATE SKIP LOCKED 抢一批待处理任务。一个 worker 已经把任务锁住但还没提交时，另一个 worker 读不到这条记录，看起来就像“跳过了未提交任务”。这通常不是数据丢失，而是锁定读为了不等待，主动把被别的事务占用的行排除在本次结果之外。

SKIP LOCKED 跳过的是当前无法取得的行锁，不等于读取未提交数据。队列设计必须接受单次查询结果不完整，并用短事务、租约和补偿扫描保证任务最终有机会被处理。

先分清锁可见性与未提交状态

假设任务 id=42 已经提交，worker A 在事务中用 FOR UPDATE 选中它，并把 status 改成 processing，但还没有提交。此时 worker B 执行同样的锁定读，如果没有 SKIP LOCKED，通常会等待 A 释放行锁；加上它以后，B 立即继续扫描，并把 42 排除在结果集之外。

这里有两个容易混淆的概念：A 的新状态对其他会话尚未提交，属于并发修改；B 没有通过普通查询读到这个“脏状态”，而是根本没有在本轮拿到这行。若是生产者正在插入一条尚未提交的新任务，也不要把 SKIP LOCKED 当成“读取未提交插入”的办法，消费者仍应依赖提交后的可见性。

用两个会话定位领取边界

排查时先准备一个 InnoDB 队列表，两个会话分别执行下面的最小对照。示例故意把提交放在第二个会话之后，便于观察“等待”和“跳过”的区别。

-- 建立一个只用于复现锁行为的队列表
CREATE TABLE task_queue (
  id BIGINT PRIMARY KEY,
  status VARCHAR(20) NOT NULL,
  lease_until DATETIME NULL,
  attempts INT NOT NULL DEFAULT 0
) ENGINE=InnoDB;

-- 会话 A：领取一条后暂不提交，保留行锁
START TRANSACTION;
SELECT id, status FROM task_queue WHERE id = 42 FOR UPDATE;
UPDATE task_queue SET status = 'processing', attempts = attempts + 1 WHERE id = 42;

-- 会话 B：不等待被 A 锁住的行，继续找其他 pending 任务
START TRANSACTION;
SELECT id, status
FROM task_queue
WHERE status = 'pending'
ORDER BY id
LIMIT 10
FOR UPDATE SKIP LOCKED;
-- 领取成功后要尽快提交，避免把锁带进业务网络调用
COMMIT;

如果 B 返回了其他任务而没有 42，首先看 A 是否仍在事务中，不要先改隔离级别。可以在排查窗口查询 performance_schema.data_locks 与 data_lock_waits，确认是行锁冲突；同时检查 B 的 WHERE status='pending' 是否与索引和业务状态一致。锁冲突说明任务暂时被占用，条件不匹配才是另一类问题。

把领取事务做短并保存租约

典型队列不要在事务里调用 HTTP、执行长耗时计算或等待人工确认。更稳的边界是：事务只负责选行、写入领取者和租约、提交；业务处理在提交后进行。这样即使处理进程崩溃，补偿任务也能依据 lease_until 找回超时记录。

-- 领取事务只写入短期租约，时间值由应用按统一时钟计算
START TRANSACTION;
SELECT id
FROM task_queue
WHERE status = 'pending'
   OR (status = 'processing' AND lease_until 

这里的租约不是数据库锁的替代品：它解决的是 worker 已经提交领取、后来却异常退出的情况。处理成功后再把状态更新为 done；失败则增加重试次数并写入下一次可领取时间。若需要严格的业务幂等，还要给任务设置业务唯一键，防止租约到期后的重试与原 worker 并发落库。

回滚、告警与补偿检查清单

worker 在领取事务内发生异常并执行 ROLLBACK 时，状态更新和行锁会一起撤销，任务回到原来的可见状态。若已经提交了 processing，就不能指望回滚找回它，而应由租约补偿把超时任务重新放回领取条件。

• 告警看“租约超时数量、最老 pending 年龄、领取后未完成数量”，不要只看某一次查询返回行数。
• 补偿扫描也使用短事务和 SKIP LOCKED，按批次推进，避免补偿器反过来堵塞正常 worker。
• 记录 worker、attempts、lease_until 和最后错误，才能区分正在处理、已回滚、反复失败和真正的状态遗漏。

MySQL 8.4 手册明确提醒，跳过锁定行的查询会得到不一致视图，适合队列这类“谁先拿到谁处理”的场景。若业务要求一次事务看到完整集合，就不应使用这个选项，而应接受等待或改用其他协调方式。

常见问题

SKIP LOCKED 会不会导致任务永久丢失？

单次领取可能暂时跳过，选项本身不会删除任务。永久丢失通常来自错误的状态更新、没有租约补偿或业务处理不可幂等。

为什么去掉 SKIP LOCKED 后查询变慢？

因为锁定读会等待持锁事务提交或回滚。先缩短领取事务，再决定是否需要跳过锁，不能用调高锁等待时间掩盖长事务。

普通 SELECT 能看到 worker 的 processing 状态吗？

在常见隔离级别下，普通一致性读不会直接读取别的事务未提交版本；它与锁定读的加锁、等待和结果语义也不同，排查时要明确使用的语句类型。

参考：MySQL 8.4 InnoDB Locking Reads、MySQL 8.4 SELECT Statement。