如何在MySQL高并发扣减库存时防止死锁-mysql教程-PHP中文网

死锁主因是加锁顺序不一致，而非select for update本身；须确保where条件命中唯一索引或主键，避免全表扫描与间隙锁冲突，并用原子update替代“查-判-更”三步操作。

如何在mysql高并发扣减库存时防止死锁

为什么`SELECT ... FOR UPDATE`在高并发下反而容易死锁

不是锁本身有问题，而是加锁顺序不可控。比如两个事务同时执行：SELECT stock FROM product_stock WHERE product_id = 10086 FOR UPDATE，如果表上没有product_id索引，MySQL会走全表扫描，不同事务可能从不同位置开始扫描、加锁，最终形成“事务A锁了第3行等第7行，事务B锁了第7行等第3行”的循环等待。

更隐蔽的是范围条件：比如WHERE status = 'on_sale' AND product_id = 10086 FOR UPDATE，若只对status建了单列索引，MySQL可能先扫所有on_sale行再过滤product_id，锁住几十甚至上百行——而另一个事务用主键id精确更新同一行，就极易撞上间隙锁或临键锁冲突。

必须确保FOR UPDATE的WHERE条件能命中**唯一索引或主键**，否则锁范围不可预测
避免在同一个事务里混用不同索引路径的语句（例如先按category_id范围查，再按id更新）
不要依赖ORDER BY id LIMIT 1来“控制顺序”——没索引时它不保证加锁顺序，有索引时也得确认id是否是该索引最左前缀

用`UPDATE ... WHERE`原子判断替代“查-判-更”三步

把库存校验和扣减压进一条语句，既省一次网络往返，又彻底消除中间态竞争。典型写法：

UPDATE product_stock 
SET stock = stock - 1, version = version + 1 
WHERE product_id = 10086 AND stock > 0 AND version = 123;

这条语句要么影响1行（成功），要么0行（失败）。应用层只需检查Affected rows，为0就重试或拒绝下单。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

务必给version字段加索引，否则WHERE version = ?可能触发全表扫描
stock > 0条件必须走索引，建议在(product_id, stock)上建联合索引，让查询能快速定位且范围可控
别在UPDATE里做复杂计算（如stock - ? > 0），MySQL可能无法使用索引

如何用`SHOW ENGINE INNODB STATUS\G`快速定位死锁根因

死锁日志里真正关键的不是报错信息，而是LATEST DETECTED DEADLOCK块中两段“HOLDS THE LOCK(S)”和“WAITING FOR THIS LOCK TO BE GRANTED”的对比。比如你看到：

*** (1) HOLDS THE LOCK(S): RECORD LOCKS ... index `idx_product_id` ... lock_mode X locks rec but not gap
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS ... index `PRIMARY` ... lock_mode X locks rec but not gap

说明事务1拿着idx_product_id上的记录锁，却在等主键锁；而事务2反过来——这直接暴露了“同一事务里用了两个不同索引路径”的问题。

运行SHOW ENGINE INNODB STATUS\G后，只盯LATEST DETECTED DEADLOCK部分，其他全是干扰信息
重点比对两个事务各自HOLDS和WAITING FOR的索引名、锁模式（X locks rec是行锁，X locks gap是间隙锁）
如果发现WAITING FOR的是lock_mode X locks gap，基本可以断定是范围查询（如WHERE category_id = 10）引发的间隙锁冲突