MySQL SELECT FOR UPDATE未锁定目标行，如何确保行锁定生效？

我之前处理并发业务时也踩过这个坑，咱们一步步拆解问题，找到根因和解决办法：

1. 先确认：SELECT FOR UPDATE必须在事务中执行 #

这是最容易忽略的核心点！MySQL默认autocommit=1，如果你单独执行SELECT * FROM table WHERE id=4 FOR UPDATE;，语句执行完就会自动提交事务，锁会立刻释放——这就难怪其他线程还能操作目标行。

正确的用法是把它包裹在事务块里：

START TRANSACTION; -- 或者用 BEGIN 开启事务
-- 锁定目标行
SELECT * FROM your_table WHERE id=4 FOR UPDATE;
-- 在这里执行你的更新/其他业务操作，比如：
UPDATE your_table SET status=1 WHERE id=4;
COMMIT; -- 最后提交事务，释放锁

如果是在应用层（比如Java、Python）操作，要确保框架是开启事务后再执行SELECT FOR UPDATE，别让单条语句自动提交。

2. 检查查询条件是否命中主键/唯一索引 #

InnoDB是行级锁，但只有当查询条件命中主键或者唯一索引时，才会精准锁定目标行。如果查询条件没用到索引（或者索引失效），InnoDB会触发全表扫描，要么锁定大量无关行，要么因为没精准定位到目标行导致锁不住。

这些情况会导致索引失效，你可以自查：

• 数据类型不匹配：比如id是INT类型，但你写了WHERE id='4'（字符串），MySQL会做隐式转换，直接跳过索引。
• 使用左模糊查询：比如WHERE id LIKE '%4'（针对非全文索引）。
• 查询条件嵌套函数：比如WHERE SUBSTRING(id,1,1)='4'。

可以用EXPLAIN命令验证索引是否生效：

EXPLAIN SELECT * FROM your_table WHERE id=4 FOR UPDATE;

看type列是不是const（主键命中）或者eq_ref（唯一索引命中），如果是ALL（全表扫描），那就是索引的问题。

3. 别混淆「快照读」和「当前读」 #

你提到“在执行更新操作前仍能查询该行”，这里要明确：普通SELECT语句是快照读，不会被行锁阻塞。

InnoDB的MVCC（多版本并发控制）机制，会让普通SELECT读取历史快照，所以即使行被锁住，其他线程还是能用普通SELECT查到该行——但如果其他线程尝试用SELECT FOR UPDATE、UPDATE、DELETE这些「当前读」操作目标行，就会被阻塞，直到锁释放。

如果你的需求是让其他线程连未提交的修改都看不到，那需要把隔离级别调到SERIALIZABLE，但一般不建议，会严重拖慢性能。

4. 检查数据库隔离级别 #

虽然默认的REPEATABLE READ（RR）已经支持行锁，但如果你的数据库被改成了READ UNCOMMITTED（读未提交），SELECT FOR UPDATE的锁机制会直接失效。可以用下面的命令检查：

SELECT @@transaction_isolation;

如果不是RR或者READ COMMITTED，请调整回正常的隔离级别。

5. 验证查询确实命中了目标行 #

最后确认一下：你的SELECT ... WHERE id=4确实能查到数据。如果目标行根本不存在，SELECT FOR UPDATE只会加间隙锁，不会锁定任何实际的行，其他线程自然能操作该位置的数据。

总结一下，最常见的原因就是没在事务中执行SELECT FOR UPDATE，或者索引失效导致没精准锁定目标行。按照上面的步骤排查，应该能解决问题。

内容的提问来源于stack exchange，提问作者forJ