不能直接解决秒杀行锁争抢，但它是高并发库存扣减的关键解耦工具：通过SELECT ... FOR UPDATE SKIP LOCKED配合主键精确查询与带条件UPDATE（如WHERE id = ? AND stock > 0），避免事务排队阻塞，需检查affected rows并依赖MySQL行级原子性兜底。
MySQL 8.0 的 SKIP LOCKED 真的能解决秒杀行锁争抢吗？
不能直接解决，但它是高并发库存扣减中一个关键的“解耦工具”——前提是用对场景、写对 SQL、避开事务边界陷阱。它不减少锁竞争，而是让多个事务在竞争同一行时“各走各路”，避免排队阻塞。
为什么 SELECT ... FOR UPDATE SKIP LOCKED 在秒杀里容易失效
常见错误是把它当成“原子扣减指令”直接套用，结果发现还是超卖或卡死。根本原因在于：
-
SKIP LOCKED只作用于当前SELECT ... FOR UPDATE语句，不保证后续UPDATE不冲突；如果先SELECT出 id，再UPDATE WHERE id = ?，那这行依然会被其他事务锁住 - 事务未显式控制范围：Spring 的
@Transactional默认传播行为会把整个方法包进一个事务，导致SELECT和UPDATE跨越多行、锁住无关记录 - 没配合唯一约束或主键查询：
SKIP LOCKED对非唯一条件（如WHERE status = 'available'）效果极差，可能跳过大量已锁行后仍返回空，业务误判为售罄
正确用法：必须和“单行更新 + 原子校验”绑定
真正可靠的模式是：用 SKIP LOCKED 拿到一个可扣减的库存记录（带主键），然后用主键做 **带库存条件的 UPDATE**，靠 MySQL 的行级原子性兜底：
START TRANSACTION; SELECT id, stock FROM seckill_goods WHERE id = 123 AND stock > 0 ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED; -- 假设查到 id=123, stock=5 UPDATE seckill_goods SET stock = stock - 1 WHERE id = 123 AND stock > 0; -- 关键：这个 WHERE 条件必须保留！ -- 检查影响行数：如果返回 0，说明已被其他事务抢先扣完 COMMIT;
要点：
- 必须用主键等效精确条件（
WHERE id = ?），不能只靠stock > 0扫描 -
UPDATE必须重复校验stock > 0，否则无法防止 ABA 问题 - 应用层要检查
UPDATE的affected rows，为 0 就立刻失败重试或返回售罄 - 不要在同一个事务里查多条、再批量更新——
SKIP LOCKED不适用于“选 N 条扣 N 库存”的逻辑
和乐观锁、分片方案比，SKIP LOCKED 的真实定位
它不是银弹，而是“轻量级热点缓解手段”，适合中低 QPS（比如 ≤2000）、已有单表结构无法大改的场景：
- 相比
SELECT + UPDATE无锁校验：避免超卖，但有锁开销 - 相比全局
LOCK TABLES或应用层synchronized：吞吐提升明显，且不阻塞读 - 相比库存分片（sharding）：无需改表结构、不增加聚合查询成本，但扩容能力弱
- 相比 Redis 预减库存：不依赖外部组件，一致性更强，但数据库仍是瓶颈点
最容易被忽略的一点：MySQL 8.0.22+ 才完整支持 SKIP LOCKED 在所有隔离级别下的稳定行为；低于该版本，在 READ COMMITTED 下可能跳过本应锁定的行。
