innodb锁行为取决于执行计划：主键/唯一索引精确匹配时只加记录锁；范围查询或无匹配记录时加间隙锁；无索引则全表锁定；skip locked/nowait仅影响锁等待策略。
WHERE 条件命中主键或唯一索引时，只锁匹配的行
这是最理想的情况。InnoDB 会精确加 Record Lock（记录锁），仅锁定 WHERE 条件实际查到的那几行。例如：
SELECT * FROM orders WHERE id = 123 FOR UPDATE;
只要 id 是主键或有唯一索引，且该记录存在，InnoDB 就只锁住这一行，其他事务仍可自由操作 id ≠ 123 的所有行。
容易踩的坑：
- 误以为“有索引就行”——必须是被查询条件实际使用的索引；用
EXPLAIN FORMAT=JSON查看key和key_locks字段，确认是否命中预期索引 - 隐式类型转换导致索引失效：比如
WHERE user_id = '123'（字段是INT），MySQL 会转成字符串比较，索引不走，退化为全表扫描
WHERE 条件是范围查询或无匹配记录时，会加间隙锁（Gap Lock）
在默认的 REPEATABLE READ 隔离级别下，InnoDB 不只锁数据行，还会锁住“值之间的空隙”。例如：
SELECT * FROM users WHERE age BETWEEN 20 AND 30 FOR UPDATE;
即使表中只有 age=22 和 age=28 两行，InnoDB 也会锁住区间 (20, 22)、(22, 28)、(28, 30)，阻止其他事务插入 age=25 这样的新记录。
另一个典型场景：
SELECT * FROM products WHERE id = 7 FOR UPDATE;
若表中没有 id=7 的记录，但有 id=5 和 id=10，InnoDB 会加间隙锁 (5, 10)，而非什么都不锁。
注意：READ COMMITTED 下不加间隙锁，但 MySQL 默认不是这个级别。
WHERE 条件没走索引，直接锁整张表
这不是“可能”，而是确定行为。当 SELECT ... FOR UPDATE 执行全表扫描时，InnoDB 会对所有扫描过的聚簇索引记录加排他锁——在 REPEATABLE READ 下，等价于事实上的表级锁定。
常见触发条件：
- 字段无索引，如
SELECT * FROM logs WHERE content LIKE '%error%' FOR UPDATE - 用了函数或表达式，如
WHERE DATE(created_at) = '2026-08-12' - 联合查询中只用到了部分索引列，比如索引是
(user_id, status)，但查询只写了WHERE status = 'pending'
现象包括：SHOW ENGINE INNODB STATUS 显示 lock_mode X locks table，或大量事务卡在 Waiting for table metadata lock。
使用 SKIP LOCKED 或 NOWAIT 改变锁行为
这两个选项不改变“原本要锁哪些记录”，而是控制“遇到已锁行时怎么处理”：
-
SELECT * FROM queue WHERE status = 'ready' ORDER BY priority DESC FOR UPDATE SKIP LOCKED：跳过已被其他事务锁住的行，返回剩余可用行。适合任务队列消费，避免多个消费者争抢同一行 -
SELECT * FROM accounts WHERE id = 100 FOR UPDATE NOWAIT：不等待，立刻报错Lock wait timeout exceeded。适合需要快速失败、重试或降级的场景
注意：NOWAIT 和 WAIT n（MySQL 8.0+）只对锁等待生效，不影响锁本身的范围和粒度。
真正决定“锁哪些记录”的，永远是执行计划——而执行计划取决于索引、隔离级别、WHERE 条件写法这三样。别只盯着语法，先跑一遍 EXPLAIN。
