死锁主因是加锁顺序不一致，而非SELECT FOR UPDATE本身；须确保WHERE条件命中唯一索引或主键，避免全表扫描与间隙锁冲突，并用原子UPDATE替代“查-判-更”三步操作。
为什么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就重试或拒绝下单。
- 务必给
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）引发的间隙锁冲突
事务粒度要小，但不能“小到拆成独立SQL”
有人为了“减少锁时间”，把逻辑拆成：SELECT stock FROM ... FOR UPDATE → 应用层判断 → UPDATE ...。这反而更危险：两次SQL之间存在时间窗口，库存可能已被改写，且两次加锁分离，极大增加死锁概率。
- 正确做法是：把所有操作封装在一个短事务里，从
START TRANSACTION到COMMIT不超过几毫秒 - 如果业务逻辑复杂（比如要查用户优惠券、计算运费），把非数据库操作提到事务外，只在事务内做“读库存+扣减+写订单”这三件事
- 避免在事务里调用外部HTTP接口或发消息——网络延迟会让锁持有时间不可控
死锁排查最耗神的地方，往往不在SQL写法，而在多个业务模块共用同一张表时，各自按不同索引路径访问——比如订单服务用user_id查，库存服务用product_id更新，风控服务又用status范围扫。这种隐式耦合，比单条SQL写错更难发现。
