根本原因是事务A未提交导致X锁未释放，事务B的JOIN需等待该锁；若orders.user_id无索引，B会全表扫描并加大量间隙锁，扩大阻塞范围。
为什么JOIN查询会卡在UPDATE后面
不是JOIN本身慢，而是它被前面未提交的UPDATE锁住了。比如事务A执行UPDATE orders SET status = 'shipped' WHERE id = 123后没COMMIT，事务B紧接着跑SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.id = 123——这时B会在o.id = 123这行等X锁释放，状态变成LOCK WAIT。
常见错误现象：SHOW ENGINE INNODB STATUS里看到WAITING FOR THIS LOCK TO BE GRANTED指向某张表的主键或二级索引，而HOLDS THE LOCK(S)显示另一个事务正持着同位置的X锁。
- 确认阻塞源头：查
information_schema.INNODB_TRX，按TRX_STARTED倒序，找TRX_STATE = 'LOCK WAIT'的记录，再用它的TRX_WAITING_TRX_ID关联INNODB_LOCK_WAITS找到BLOCKING_TRX_ID - 别急着
KILL：先看那个BLOCKING事务的TRX_QUERY字段，它可能只是忘了COMMIT，也可能是正在调HTTP接口卡住 - JOIN条件字段必须有索引：如果
orders.user_id没索引，B的JOIN会触发全表扫描+大量间隙锁，让等待范围从“一行”扩大到“整段索引区间”
UPDATE和SELECT共用同一WHERE条件时怎么避免互相锁
典型陷阱是业务逻辑写成“先查再更”，比如SELECT * FROM stock WHERE sku = 'ABC' FOR UPDATE → 计算库存 → UPDATE stock SET qty = ? WHERE sku = 'ABC'。只要中间计算耗时，其他并发请求就全堵在FOR UPDATE上。
真正要的是原子性更新，不是锁住再算。直接用单条带条件的UPDATE更安全：
UPDATE stock SET qty = qty - 1 WHERE sku = 'ABC' AND qty >= 1;
这样要么成功扣减，要么影响行为0（说明库存不足），不需要额外锁、不依赖事务外逻辑。
- 确保
sku有唯一索引，否则WHERE sku = 'ABC'会升级为间隙锁，多个并发请求可能争抢同一间隙 - 避免在WHERE里用函数：
WHERE UPPER(sku) = 'ABC'会让索引失效，退化成全表扫描加锁 - 如果真需要复杂校验（比如跨表判断），把校验逻辑放到应用层做只读查询，结果传入UPDATE的WHERE条件中，而不是放在事务内
多表JOIN更新时死锁高发，怎么统一加锁顺序
死锁不是并发高导致的，是两个事务对同一组行以相反顺序加锁。例如事务A执行UPDATE users SET balance = balance - 100 WHERE id = 100; UPDATE orders SET paid = 1 WHERE user_id = 100，事务B同时执行UPDATE orders SET paid = 1 WHERE user_id = 100; UPDATE users SET balance = balance - 100 WHERE id = 100——A拿了users锁等orders，B拿了orders锁等users，立刻死锁。
- 所有涉及多表修改的代码，强制按主键升序处理：先查出要改的
users.id和orders.id，排序后统一先更新users（小id优先），再更新orders（小id优先） - 用
SELECT ... FOR UPDATE ORDER BY id ASC预取并锁定，确保加锁顺序和后续UPDATE一致；但注意ORDER BY必须走索引，否则Using filesort会让加锁顺序不可控 - 高频小更新表可禁用锁升级：
ALTER TABLE orders SET (LOCK_ESCALATION = DISABLE)（SQL Server）或innodb_lock_wait_timeout = 5（MySQL），防止行锁意外升为页锁
应用层重试时为什么越重试越卡
捕获到死锁错误（MySQL的1213，SQL Server的1205）后立即重试，常导致雪崩。因为所有线程在同一毫秒级时间窗口重试，再次以随机顺序争抢资源，死锁概率反而升高。
- 必须加退避延迟：第一次重试前
sleep(50ms)，第二次sleep(100ms)，第三次sleep(200ms)，上限不超过1秒 - 重试前检查幂等性：UPDATE语句要带版本号或状态校验，比如
UPDATE order SET status = 'paid' WHERE id = ? AND status = 'unpaid'，避免重复扣款 - 别在重试循环里重新生成业务参数：比如库存扣减量要在重试外算好，否则每次重试都可能用新值覆盖旧值
锁等待问题从来不是单点优化能解决的，它暴露的是事务边界是否清晰、索引是否覆盖查询路径、以及应用层有没有把非DB操作拖进事务里——这些细节比SQL写法本身更容易被忽略。
