SELECT FOR UPDATE锁不释放主因是autocommit=1导致锁瞬时释放；必须用START TRANSACTION显式开启事务、确保WHERE走索引、注意RR级间隙锁影响，且仅在依赖查询结果做条件更新时才前置使用。
SELECT FOR UPDATE锁不释放，大概率是autocommit=1
MySQL默认开启自动提交（autocommit=1），此时SELECT FOR UPDATE执行完就立刻提交、锁随即释放——你根本没机会用它保护后续操作。这不是语法问题，而是事务没真正开启。
必须显式启动事务：
- 执行
START TRANSACTION或BEGIN（推荐前者，语义更明确） - 紧接着执行
SELECT * FROM t WHERE id = 123 FOR UPDATE - 再执行
UPDATE或其他依赖锁的操作 - 最后必须
COMMIT或ROLLBACK；漏掉会导致锁长期悬挂，阻塞全表更新
验证是否生效：查SELECT @@autocommit，返回0才安全；若为1，仅靠SET autocommit = 0不够稳定，仍建议统一用START TRANSACTION包裹。
WHERE条件没走索引，等于锁全表
SELECT FOR UPDATE的锁粒度完全取决于查询是否命中索引。没索引，InnoDB只能全表扫描，给每一行都加X锁——并发直接归零。
检查方法：在语句前加EXPLAIN，重点看三处：
-
type字段不能是ALL或index（全表/全索引扫描）；理想是const（主键等值）或ref（普通索引等值） -
key字段必须显示具体索引名，如PRIMARY或idx_order_no -
rows应接近预期行数；若显示几百上千，说明锁范围失控
常见踩坑点：
- 对字段用函数：
WHERE DATE(created_at) = '2024-01-01'→ 索引失效 - 隐式类型转换：
WHERE user_id = '123'（user_id是INT）→ 可能放弃索引 - 联合索引顺序错配：
WHERE status = 1对索引(user_id, status)无效
锁住不该锁的间隙，INSERT被卡死
在默认REPEATABLE READ隔离级别下，SELECT FOR UPDATE不仅锁行，还锁间隙（Gap Lock），防止幻读。但业务中常不需要这个语义，反而导致无关INSERT被阻塞。
典型现象：
- 表中有
id = 1, 5, 10，执行SELECT * FROM t WHERE id BETWEEN 3 AND 7 FOR UPDATE - 随后
INSERT INTO t (id) VALUES (4)会被卡住——因为间隙(1,5)和(5,10)已被锁
解决路径分场景：
- 若只需精确锁已存在行（如扣减库存、更新订单状态），可临时切隔离级别：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED，此时只锁匹配行，不锁间隙 - 若必须保持RR级别，确保WHERE条件走**唯一索引**（如
order_no有UNIQUE KEY），这样InnoDB能精确定位单行+单间隙，避免锁扩散 - 绝对避免在无索引字段（如
WHERE remark LIKE '%xxx'）上用FOR UPDATE，否则锁整个索引段
事务太长，锁“悬停”数秒甚至更久
锁不是SQL执行完就放，而是在COMMIT或ROLLBACK后才释放。一个事务里混入日志写入、HTTP调用、循环处理等耗时操作，等于把行锁挂起几秒钟——别人全得排队。
缩短锁持有时间的关键动作：
- 把
SELECT FOR UPDATE尽量靠近UPDATE，中间别掺杂任何非DB操作 - 避免在事务内做
SELECT COUNT(*) JOIN ...这类大查询，它会拖慢整个事务节奏 - 高并发“查不存在则插入”场景，优先用
INSERT ... ON DUPLICATE KEY UPDATE替代“查→判→插”，绕过锁逻辑 - 若需读多行再批量更新，改用
SELECT ... FOR UPDATE SKIP LOCKED（MySQL 8.0+），避免被其他事务锁住的行阻塞自己
最易被忽略的一点：很多人盯着“能不能锁住”，却没算过锁实际挂了多久。一次SELECT FOR UPDATE本身毫秒级，但后面跟了个3秒的远程API调用，锁就真成了瓶颈。
