MySQL悲观锁在秒杀中必然串行化，因所有请求竞争同一行X锁且锁持有时间长，导致连接池耗尽、雪崩式积压；根本解法是架构层绕过单行锁，如库存预扣减或分段库存。
MySQL 悲观锁（SELECT ... FOR UPDATE）在高并发秒杀场景下性能极差，根本不是锁本身“慢”，而是它把本该并行的请求，强行塞进一个串行化队列里——所有请求竞争同一行记录的 X 锁，而 InnoDB 不会主动拒绝，只会让它们排队等 50 秒（默认 innodb_lock_wait_timeout），直到连接池耗尽、应用超时、监控失真。
为什么 SELECT ... FOR UPDATE 在秒杀中必然串行化
秒杀的核心是单行热点更新（如 product_stock 表中某商品的库存字段），所有请求都命中同一主键或唯一索引值：
- 即使加了唯一索引，InnoDB 仍只对该行加 record lock（X 锁），但事务提交前锁不释放
- 事务越长（比如 ORM 自动 flush、日志写入、网络延迟），锁持有时间越长，后续请求只能进等待队列
- 没有“跳过已锁定行”的机制（
SKIP LOCKED是 MySQL 8.0+ 才支持，且仅适用于SELECT ... FOR UPDATE分发类场景，不解决单行更新问题） - 应用层若未设
socketTimeout，JDBC 连接还会在网络层继续挂起，加剧连接池饥饿
无索引或范围条件会让问题指数级恶化
一旦 WHERE 条件没走索引，或者用了非唯一字段（如 WHERE status = 'on_sale'），后果远超“慢”：
- 全表扫描 → 对每个聚簇索引记录逐个加 X 锁，或触发大量间隙锁（gap lock）
-
UPDATE t SET stock = stock - 1 WHERE product_id = 10086 AND stock > 0若stock > 0无法使用索引，就会锁住整张表所有行 - 死锁概率飙升：不同事务因扫描顺序/索引路径差异，以不同顺序加锁，形成环形等待
-
SHOW ENGINE INNODB STATUS里会看到几十甚至上百个LOCK WAIT状态，但Threads_connected已打满
连接池 + 锁等待 = 雪崩式积压
这不是数据库 CPU 或磁盘 IO 瓶颈，而是连接资源被无效占用：
- 一个连接卡在
Waiting for table metadata lock或Updating状态，就等于从连接池里永久消失 50 秒 - 假设连接池大小为 100，QPS 8000 → 每秒新增 8000 个请求，但每秒最多只能处理 ~2 条（串行化瓶颈），其余全部堆积
- 应用层重试逻辑若没退避（如立即重试），反而向 DB 注入更多等待事务，加速崩溃
- 监控上看不到慢 SQL（因为语句本身执行快），只看到大量
Lock wait timeout exceeded和连接数暴涨
真正难缠的是锁等待引发的连锁反应
单次锁等待容易定位，但真实线上故障往往由它触发多层坍塌：
- 连接池耗尽后，新请求在应用层就失败（如 HikariCP 的
Connection is not available），掩盖了底层 DB 问题 - 死锁回滚后抛出
Deadlock found when trying to get lock，但业务代码若没捕获并重试，用户直接看到“下单失败” - 多个服务共用同一张库存表，各自按不同字段查再
FOR UPDATE（如按sku_id查 vs 按product_id查），锁顺序天然不一致 - 触发器、外键约束、生成列等隐式操作，会在同一事务内额外引入锁竞争，EXPLAIN 和慢日志完全不可见
最常被忽略的一点：你优化了 SQL、加了索引、调小了事务，但只要还在用 SELECT ... FOR UPDATE 去争抢单行，就仍在原地踏步。真正的出路不在锁参数调优，而在架构层绕过它——比如库存预扣减 + 异步落库、分段库存（分 100 个 slot）、Redis 原子计数 + 最终一致性校验。
