SELECT * FOR UPDATE 是否加行锁？核心结论+分场景详解

你想知道SELECT * FOR UPDATE（当前读）是否加行锁，核心结论是：不一定，锁的类型（行锁/临键锁/表锁）由查询条件是否使用索引、使用何种索引决定，仅在主键/唯一索引精准匹配单行时，才会加纯行级排他锁；其他场景会升级为临键锁或表级排他锁，以下分场景详细拆解，结合规则、原理和实操验证说明：

一、基础前提：SELECT * FOR UPDATE 的锁本质

SELECT * FOR UPDATE是InnoDB的当前读操作，执行时会为匹配的数据加排他锁（X锁），阻塞其他事务对该数据的读（SELECT ... FOR UPDATE/LOCK IN SHARE MODE）、写（UPDATE/DELETE/INSERT）操作；
锁的作用范围并非固定为行，而是由查询条件的索引使用情况和隔离级别（默认RR可重复读）共同决定，行锁是理想情况，非索引场景会直接升级为表锁。

二、分3大场景：明确锁类型（附核心规则）

以下所有场景均基于MySQL默认的可重复读（RR）隔离级别（读已提交RC下锁规则会简化，文末补充），按“索引使用情况”分核心场景，规则可直接落地实操：

场景1：查询条件用主键/唯一索引（精准匹配单行）→ 加行级排他锁（Record Lock）

这是最理想的场景，InnoDB能通过主键/唯一索引快速定位到单行数据，仅为该单行加行级排他锁，不影响其他行的并发操作，锁的粒度最细、并发性能最好。

示例（主键精准匹配）：

-- 表有主键id，精准查询id=1
SELECT * FROM test_lock WHERE id = 1 FOR UPDATE;
-- 仅为id=1这一行加行级排他锁，其他行（id=2/3等）无锁

场景2：查询条件用普通索引（非唯一）→ 加临键锁（Next-Key Lock）

若查询条件使用普通索引（无唯一性约束），即使精准匹配，InnoDB也不会加纯行锁，而是加临键锁（行锁+间隙锁）：

• 对普通索引上匹配的行加行级排他锁；
• 对该索引行前后的间隙加间隙锁（Gap Lock）；
  核心目的：防止其他事务在间隙内插入新行，解决RR隔离级别下当前读的幻读问题（关联之前讲的RR解决幻读的核心机制）。

示例（普通索引查询）：

-- 表有普通索引name，执行以下语句
SELECT * FROM test_lock WHERE name = '测试' FOR UPDATE;
-- 1. 对name='测试'的行加行级排他锁；
-- 2. 对name索引中，'测试'前后的间隙（如'测试'和'测试2'之间）加间隙锁；
-- 3. 其他事务无法修改该行车数据，也无法在间隙内插入name为新值的行

场景3：无索引/索引失效/全表扫描 → 加表级排他锁

这是最糟糕的场景：若查询条件未使用任何索引（如非索引字段）、索引失效（如隐式类型转换、%开头的模糊查询），或查询结果为全表扫描，InnoDB无法定位到具体行，会直接升级为表级排他锁。
表级排他锁会锁定整张表，其他事务对该表的任何行执行读（当前读）、写操作都会被阻塞，并发性能大幅下降，生产环境需严格规避。

示例（无索引/索引失效）：

-- 场景3.1：无索引——name非索引字段
SELECT * FROM test_lock WHERE name = '测试' FOR UPDATE; -- 全表扫描→表锁

-- 场景3.2：索引失效——主键id是INT，传字符串（隐式转换）
SELECT * FROM test_lock WHERE id = '1' FOR UPDATE; -- 索引失效→全表扫描→表锁

-- 场景3.3：全表扫描——无WHERE条件
SELECT * FROM test_lock FOR UPDATE; -- 全表扫描→表锁

三、关键补充：范围查询的特殊情况（主键/唯一索引也会变临键锁）

即使使用主键/唯一索引，若为范围查询（如>/</BETWEEN AND），而非精准匹配，也不会加纯行锁，而是加临键锁，锁定查询条件覆盖的所有行+间隙，阻止其他事务在间隙内插入新行。

示例（主键范围查询）：

-- 主键id，范围查询id>1
SELECT * FROM test_lock WHERE id > 1 FOR UPDATE;
-- 1. 对id>1的所有行（如id=2/3）加行级排他锁；
-- 2. 对id最大行之后的间隙（如id=3之后的所有空区间）加间隙锁；
-- 3. 其他事务无法修改id>1的行，也无法插入id>1的新行

例外：主键/唯一索引的范围查询且精准匹配到唯一行（如id BETWEEN 1 AND 1），仍会降级为行级锁。

四、实操验证：3大场景锁类型差异（直观对比）

基于之前的test_lock表（主键id，新增普通索引name），插入测试数据：

INSERT INTO test_lock (name) VALUES ('测试1'),('测试2'),('测试3');

通过两个会话验证锁的作用范围，核心现象如下：

场景1验证（主键精准匹配→行锁）

会话A（加锁）	会话B（操作其他行）	结果
BEGIN; SELECT * FROM test_lock WHERE id=1 FOR UPDATE;	BEGIN; UPDATE test_lock SET name='修改' WHERE id=2;	成功（仅id=1加锁，id=2无锁）

场景2验证（普通索引查询→临键锁）

会话A（加锁）	会话B（插入间隙行）	结果
BEGIN; SELECT * FROM test_lock WHERE name='测试2' FOR UPDATE;	BEGIN; INSERT INTO test_lock (name) VALUES ('测试1.5');	阻塞（间隙被锁定，无法插入）

场景3验证（无索引查询→表锁）

会话A（加锁）	会话B（操作任意行）	结果
BEGIN; -- 假设age无索引 SELECT * FROM test_lock WHERE age=20 FOR UPDATE;	BEGIN; UPDATE test_lock SET name='修改' WHERE id=1;	阻塞（整张表被锁定，所有行都无法操作）

五、重要注意事项（生产环境避坑）

1. 隔离级别影响锁规则：仅RR（可重复读） 下会出现临键锁/间隙锁；若设置为RC（读已提交），InnoDB会关闭间隙锁，普通索引查询也会加行锁，但会失去幻读防护能力；
2. 优先使用主键/唯一索引精准查询：这是保证加行锁的唯一方式，最大化并发性能；
3. 避免索引失效：写查询条件时，避免隐式类型转换、%开头的模糊查询、函数操作索引字段（如LEFT(name,2)='测试'），防止全表扫描升级为表锁；
4. 缩小查询范围：即使使用范围查询，也尽量缩小条件范围（如id BETWEEN 1 AND 10而非id>0），减少锁定的行和间隙，降低阻塞概率。

六、核心总结

1. SELECT * FOR UPDATE是当前读，必加排他锁，但不一定是行锁，锁类型由索引使用情况决定；
2. 仅主键/唯一索引精准匹配单行→ 纯行级排他锁（最优）；
3. 普通索引查询/主键/唯一索引范围查询→ 临键锁（行锁+间隙锁，解决幻读）；
4. 无索引/索引失效/全表扫描→ 表级排他锁（最差，并发阻塞）；
5. 生产实操核心原则：优先用主键/唯一索引精准查询，避免索引失效，缩小锁定范围，保证锁粒度最细。