在mysql的InnoDB存储引擎中，SELECT FOR UPDATE是实现显式行级锁的常用语句，它的阻塞特性是很多开发者在开发并发业务时需要重点关注的内容。该语句的核心作用是在事务中对查询到的行添加排他锁，阻止其他事务对这些行进行修改或者加锁操作。
SELECT FOR UPDATE的基础原理
SELECT FOR UPDATE属于mysql的显式锁定语句，需要在事务中执行才会生效。当执行该语句时，InnoDB会对符合条件的行添加排他锁（X锁），此时其他事务如果要对这些行执行UPDATE、DELETE或者再次执行SELECT FOR UPDATE语句，就会被阻塞，直到当前事务提交或者回滚释放锁。
需要注意的是，SELECT FOR UPDATE的锁定范围和查询语句的索引使用情况直接相关。如果查询条件命中了索引，那么只会锁定符合条件的行；如果没有命中索引，InnoDB会进行全表扫描，此时会对全表的所有行添加锁，阻塞所有对该表的写操作。
不同场景下的阻塞表现
1. 命中索引的行级锁定场景
假设我们有一张用户表user，结构如下：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) DEFAULT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_age` (`age`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
事务A执行以下语句：
START TRANSACTION; SELECT * FROM user WHERE id = 1 FOR UPDATE;
此时事务A对id为1的行添加了排他锁，如果事务B执行以下语句，就会被阻塞：
START TRANSACTION; -- 该语句会被阻塞，直到事务A提交或回滚 UPDATE user SET age = 20 WHERE id = 1;
如果事务B操作的是id为2的行，由于锁定的行不冲突，事务B的语句可以正常执行，不会被阻塞。
2. 未命中索引的表级锁定场景
如果事务A执行没有命中索引的查询加锁语句：
START TRANSACTION; -- age字段没有索引时，会锁定全表所有行 SELECT * FROM user WHERE age = 20 FOR UPDATE;
此时事务B无论要更新哪一行数据，都会被阻塞，因为全表的所有行都被添加了排他锁。这也是很多线上业务出现性能问题的常见原因，使用SELECT FOR UPDATE时必须确保查询条件命中了合适的索引。
3. 不同事务隔离级别的影响
在READ COMMITTED隔离级别下，SELECT FOR UPDATE只会锁定查询到的行；而在REPEATABLE READ隔离级别下，除了锁定行之外，还会对符合条件的间隙添加间隙锁，防止其他事务插入符合条件的新行，此时阻塞的范围会更大。
显式锁定机制的其他相关语句
除了SELECT FOR UPDATE之外，mysql还有其他显式锁定语句：
SELECT ... LOCK IN SHARE MODE：添加共享锁（S锁），允许其他事务加共享锁，但是阻止其他事务加排他锁，适合需要先读取数据再判断是否需要修改的场景。LOCK TABLES：表级显式锁，会锁定整张表，阻塞所有其他事务对该表的读写操作，一般不建议在InnoDB中使用，会影响并发性能。
使用SELECT FOR UPDATE的注意事项
为了避免不必要的阻塞和性能问题，使用SELECT FOR UPDATE时需要注意以下几点：
- 尽量在事务中短时间使用，执行完相关操作后立即提交事务，减少锁的持有时间。
- 确保查询条件命中索引，避免全表锁定的情况。
- 不要在事务中执行和锁定无关的耗时操作，比如调用外部接口、处理大量业务逻辑等。
- 避免多个事务按照不同的顺序对相同的行加锁，防止出现死锁问题。
总结
mysql的SELECT FOR UPDATE在事务中执行时会产生阻塞，具体阻塞的范围和索引使用情况、事务隔离级别等因素相关。作为显式锁定机制的一部分，它可以帮助开发者在并发场景下保证数据的一致性，但是如果使用不当也会导致严重的性能问题。在实际开发中，需要根据业务场景合理选择是否使用该语句，同时注意优化查询条件，减少锁的影响范围。
SELECT_FOR_UPDATE显式锁定InnoDB行级锁事务隔离修改时间：2026-07-24 09:42:20