移库操作必须用select ... for update，因其本质是“从a仓减、向b仓加”的两步原子操作，需通过行级x锁防止并发插手；若仅用普通select+update，易致超卖或负库存，且锁必须基于索引条件，否则退化为表锁。
移库操作为什么必须用 SELECT ... FOR UPDATE
因为移库本质是“从A仓减、向B仓加”，两步必须原子执行，中间不能被其他事务插手。如果只用普通 SELECT 读出库存再 UPDATE，并发时极易出现超卖或负库存——比如两个移库请求同时读到A仓有100件，各自减100，结果A仓变成-100。而 SELECT ... FOR UPDATE 在读的瞬间就对目标行加X锁，后续所有读写都会阻塞，直到当前事务提交或回滚。
必须基于索引条件加锁，否则会升级成表锁
排他锁生效的前提是InnoDB能精确定位到具体行。如果 WHERE 条件没走索引（例如用 LIKE '%xxx'、字段无索引、或用了函数），InnoDB无法做行级锁定，会退化为锁整张表，直接拖垮并发性能。
- ✅ 正确：假设
inventory表有联合索引(warehouse_id, product_id)，则SELECT * FROM inventory WHERE warehouse_id = 1 AND product_id = 1001 FOR UPDATE只锁对应行 - ❌ 危险：若只写
WHERE product_id = 1001且该字段无索引，InnoDB可能扫描全表并锁住所有行 - ⚠️ 验证方式：执行
EXPLAIN看type是否为const或ref，key是否显示实际使用的索引
移库事务中要避免锁等待超时和死锁
移库常涉及两条记录（源仓减、目的仓加），顺序不一致是死锁高发点。比如事务A先锁仓库1再锁仓库2，事务B反着来，就卡死了。
- 统一加锁顺序：始终按
warehouse_id升序处理，即先锁MIN(warehouse_id)行，再锁MAX(warehouse_id)行 - 控制事务粒度：不要在
FOR UPDATE后做耗时操作（如远程调用、复杂计算），锁持有时间越短越好 - 捕获死锁异常：应用层需监听错误码
1213（Deadlock found when trying to get lock），并自动重试整个事务 - 设置合理超时：在连接层设
innodb_lock_wait_timeout（默认50秒），避免一个长事务拖住所有移库请求
为什么不能只靠 UPDATE 隐式锁？
隐式X锁确实会在 UPDATE 时自动加，但它只覆盖“更新成功”的那行。移库前通常需要校验：A仓是否足够、B仓是否存在、商品状态是否可用……这些前置检查若不用 FOR UPDATE 锁住，检查和后续 UPDATE 之间就有时间窗口，校验通过后仍可能被其他事务改掉数据。
- ✅ 安全流程：BEGIN →
SELECT ... WHERE warehouse_id=1 AND product_id=1001 FOR UPDATE（查A仓余量并锁）→ 校验 ≥ 移库数量 →SELECT ... WHERE warehouse_id=2 AND product_id=1001 FOR UPDATE（锁B仓，确保可写）→ 两个UPDATE→ COMMIT - ❌ 危险流程：BEGIN → 普通
SELECT查A仓 → 校验通过 → 执行UPDATE（此时才加锁）→ 中间A仓已被扣减 → UPDATE失败或数据错乱
真正容易被忽略的是：锁的释放时机完全绑定事务生命周期，不是语句执行完就释放。哪怕你只锁了一行、只做一次 UPDATE，只要没 COMMIT 或 ROLLBACK，锁就一直挂着——包括连接空闲、应用卡顿、甚至网络中断未及时通知数据库断连的情况。线上必须配好超时机制，并在代码里显式管理事务边界。
