MySQL事务锁机制与加锁读场景解析

SELECT ... FOR UPDATE：事务中的“精确制导”锁

需要明确一个核心事实：SELECT ... FOR UPDATE 锁定的，仅仅是那些被 WHERE 条件实际命中或可能命中的索引记录。它既不是锁整张表，也不一定是锁所有符合条件的行，前提是查询正确使用了索引。如果查询使用了全表扫描，InnoDB 就会升级为间隙锁加记录锁的组合，锁住整个扫描范围，这很容易引发意外的阻塞。

SELECT ... FOR UPDATE 在事务中锁定的对象

简单来说，它锁定的是“目标”，但这个目标的范围完全由查询方式和索引决定。

• 首先，该语句必须在 BEGIN 或 START TRANSACTION 之后执行，并在 COMMIT 或 ROLLBACK 之前生效，事务结束后锁立即释放。
• 例如，使用主键精确查询（如 WHERE id = 123），则只锁定这一条记录，非常精准。但如果是范围查询，或条件字段没有索引（如 WHERE status = 'pending' 但 status 未建索引），情况就变得复杂，它可能锁定整个相关二级索引 B+ 树的所有叶子节点，影响范围迅速扩大。
• 这种锁是“悲观”的，态度坚决：一旦加锁时发现目标已被其他事务占用，当前事务会一直等待，直到超时（默认50秒，由 innodb_lock_wait_timeout 控制），然后抛出 Lock wait timeout exceeded 错误。

UPDATE 语句自带锁，但不能替代 FOR UPDATE

这里存在一个常见误解：UPDATE 语句不是也会自动加锁吗？没错，它确实会在修改前对目标行加排他锁（X锁）。但问题在于，这个锁只在 UPDATE 语句执行时生效，无法保护从“读取数据”到“决定更新”这个时间窗口。

设想一个经典场景：先执行 SELECT balance FROM accounts WHERE id = 1001 读取余额，在应用代码中计算新值，再执行 UPDATE accounts SET balance = WHERE id = 1001。就在读取和更新的间隙，另一个事务可能已经修改了余额，最终导致超发或数据不一致。这就是典型的“读写竞态”问题。

• 真正安全的做法是：使用 SELECT balance FROM accounts WHERE id = 1001 FOR UPDATE 来读取并锁定该行，然后在同一个事务内完成计算和更新操作。这样，从读取那一刻起，这行数据就被“预定”了。
• 另一个陷阱是，如果 UPDATE 语句的 WHERE 条件与业务逻辑要保护的数据范围不一致，它就起不到保护作用。例如，想保护一批特定状态的订单，却用 ID 去更新，锁自然就加错了地方。
• 还有一点细微差别：UPDATE ... WHERE 如果没匹配到任何行，它不会加任何锁；而 SELECT ... FOR UPDATE 即使没查到数据，在默认的 REPEATABLE READ 隔离级别下，也可能为阻止“幻读”而加上间隙锁。

隔离级别对锁行为的影响：READ COMMITTED 与 REPEATABLE READ

隔离级别不仅决定了能“看见”什么数据，还直接影响锁的粒度和行为方式。在 MySQL 默认的 REPEATABLE READ 隔离级别下，SELECT ... FOR UPDATE 会添加 next-key lock（记录锁加上间隙锁），锁住记录及其前后的间隙。而在 READ COMMITTED 级别下，它通常只加记录锁，不锁间隙。

• 如果业务场景希望减少锁冲突、允许更高的并发插入，并且可以接受“幻读”（即同一事务内两次查询结果集可能不同），那么将事务隔离级别设置为 READ COMMITTED 是一个选项：SET TRANSACTION ISOLATION LEVEL READ COMMITTED。
• 但需要警惕的是，在 READ COMMITTED 下，同一个事务内多次执行相同的 SELECT ... FOR UPDATE，每次看到的数据可能都不一样（因为其他事务的提交立即可见），锁也会重新获取。不能依赖第一次查询到的值在整个事务中保持稳定。
• 反过来看，REPEATABLE READ 虽然通过间隙锁提供了更强的隔离性，但如果业务核心诉求只是防止“更新丢失”，对“幻读”不敏感，那么过度的间隙锁反而会成为吞吐量的瓶颈。

隐式锁与唯一索引冲突的隐藏场景

锁的行为并非总是显式的。一个典型的隐藏场景是唯一索引冲突。当两个事务几乎同时尝试插入同一条唯一键记录时（例如 INSERT INTO users (email) VALUES ('a@b.com')），即使没有显式使用 FOR UPDATE，InnoDB 也会在唯一索引上自动施加隐式的排他锁。

这时，后到达的事务会等待前一个事务完成。如果前者提交，后者则因唯一冲突而失败；如果前者回滚，后者才能成功插入。如果前一个事务因故卡住或崩溃，从现象上看就是“插入操作莫名其妙卡死了”。查看 SHOW ENGINE INNODB STATUS 输出，往往能看到类似 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 后面跟着唯一索引名的等待信息。

• 这并非系统bug，而是数据库为了维护唯一性约束所必需的串行化检查机制。
• 要避免这种“卡死”的直观感受，一种方法是在插入前，先使用 SELECT ... FOR UPDATE 查询该记录是否存在（即“先查后改”模式），但这本身也需要包裹在事务中，并且要处理好从“查无记录”到“执行插入”这个窗口期。
• 如果业务逻辑允许，使用 INSERT ... ON DUPLICATE KEY UPDATE 语句通常更为简洁高效。它在内部同样处理了隐式锁和冲突，但从语法层面封装了等待和决策逻辑，对开发者更友好。

总之，事务中的锁机制不是一个简单的开关，而是一套细粒度的资源协商协议。真正的难点，从来不是语法上写对一句 FOR UPDATE，而是在于厘清几个关键问题：到底需要保护哪几行数据？哪些并发操作可能修改它们？做出修改决策所依据的数据状态是否稳定？忽略一个间隙、错判一次索引选择，或者把锁放在了不匹配的隔离级别下，都足以让高并发的美好设想，瞬间退化成低效的排队等待。