SELECT FOR UPDATE必须在显式事务中执行，否则锁立即释放；需走索引避免表锁；RR级别下加临键锁，RC级别仅加记录锁；多事务须按相同顺序加锁防死锁。
FOR UPDATE 必须在显式事务中执行
单独写 SELECT ... FOR UPDATE 不会持久锁住行，锁在语句执行完就释放。这会让“查-判-改”逻辑完全失效，比如库存判断为 1 后，另一事务立刻扣减到 0，当前事务还按 1 继续操作。
正确做法是用 START TRANSACTION 或 BEGIN 显式开启事务，并在 COMMIT 或 ROLLBACK 后才释放锁：
START TRANSACTION; SELECT stock FROM goods WHERE id = 123 FOR UPDATE; -- 此时其他事务对 id=123 的 UPDATE / SELECT FOR UPDATE 会被阻塞 UPDATE goods SET stock = stock - 1 WHERE id = 123; COMMIT;
- 漏掉
START TRANSACTION是最常见误用，锁秒放，等于没锁 - 使用
AUTOCOMMIT=0全局关闭自动提交也可，但不推荐——易遗忘恢复，污染连接状态 - 应用层需确保异常时调用
ROLLBACK，否则锁长期持有，拖垮后续请求
WHERE 条件必须走索引，否则可能锁全表
FOR UPDATE 的锁粒度不是由语句本身决定的，而是由 MySQL 执行计划中实际扫描的行决定的。没索引或索引失效，就会退化为全表扫描+全扫描行加锁，等效于表级阻塞。
- 主键或唯一索引查询（如
WHERE id = 123）→ 只锁匹配行 - 普通索引查询（如
WHERE status = 'pending'）→ 锁匹配行 + 对应间隙（临键锁），防幻读 - 无索引字段查询（如
WHERE name LIKE '%abc'）→ 全表扫描，锁所有扫描行，高并发下极易卡死 - 用
EXPLAIN确认type是const/ref，而非ALL或index
多行加锁必须固定顺序，否则必现死锁
两个事务分别按不同顺序执行 SELECT ... FOR UPDATE，MySQL 检测到循环等待后会随机回滚一个，并报错：Deadlock found when trying to get lock; try restarting transaction。
例如：
- 事务 A：先
SELECT ... WHERE id = 100 FOR UPDATE，再SELECT ... WHERE id = 200 FOR UPDATE - 事务 B：先
SELECT ... WHERE id = 200 FOR UPDATE，再SELECT ... WHERE id = 100 FOR UPDATE
解决方式只有两种：
- 所有业务路径统一按相同顺序加锁，比如始终按
ORDER BY id ASC查询 - 应用层捕获死锁异常，重试整个事务（注意幂等性，避免重复扣款）
- 用
SELECT ... FOR UPDATE SKIP LOCKED跳过已被锁的行，适合队列类场景（如抢券、任务分发）
READ COMMITTED 和 REPEATABLE READ 隔离级别影响锁行为
默认隔离级别 REPEATABLE READ 下，FOR UPDATE 会加临键锁（Next-Key Lock），既锁行也锁间隙；而 READ COMMITTED 下只锁实际命中的行，不加间隙锁。
- 想减少锁范围、降低死锁概率，可设为
READ COMMITTED（需确认业务能接受不可重复读） - 若依赖间隙锁防幻读（如防止重复插入某范围内的记录），则不能降级
- 修改会话级别：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; - 注意：即使
READ COMMITTED，无索引查询仍会锁全表扫描行
锁的实际行为高度依赖执行计划和隔离级别，不看 EXPLAIN、不测死锁路径、不验索引有效性，只靠语法写 FOR UPDATE，和裸奔没区别。
