SELECT ... FOR UPDATE 只锁 WHERE 条件实际或可能命中的索引记录，主键查询锁单行，范围查询若无索引则锁全扫描范围；它在事务中加悲观锁，防止读写竞态，比普通 UPDATE 更安全。
SELECT ... FOR UPDATE 在事务里到底锁什么
它只锁住 WHERE 条件实际命中（或可能命中）的索引记录，不是整张表，也不是所有满足条件的行——前提是用了索引。如果 WHERE 走全表扫描，InnoDB 会升级为间隙锁 + 记录锁组合，把整个扫描范围都锁死，容易导致莫名其妙的阻塞。
- 必须在
BEGIN/START TRANSACTION之后、COMMIT或ROLLBACK之前执行，否则锁立刻释放 - 主键查询（如
WHERE id = 123）只锁单条记录；范围查询（如WHERE status = 'pending'）若没走索引，可能锁住整个二级索引 B+ 树的所有叶子节点 - 锁是“悲观”的，一旦加锁失败（被其他事务占着），当前事务会一直等待，直到超时（默认
innodb_lock_wait_timeout = 50秒），报错Lock wait timeout exceeded
UPDATE 语句自带锁，但别误以为它能替代 FOR UPDATE
UPDATE 确实会在修改前对目标行加 X 锁，但它只在语句执行那一刻生效，且不保证你读到的数据没被别人改过——中间存在竞态窗口。比如先 SELECT balance FROM accounts WHERE id = 1001，再根据结果算出新值去 UPDATE，这之间余额可能已被其他事务扣减，导致超发。
- 真正安全的做法是：用
SELECT balance FROM accounts WHERE id = 1001 FOR UPDATE读取并锁住，再在同一事务里做计算和UPDATE - 如果
UPDATE的WHERE条件和你要保护的业务逻辑不一致（比如按状态查但按 ID 更新），它根本锁不住你关心的那批数据 -
UPDATE ... WHERE如果没匹配到任何行，不会加任何锁；而SELECT ... FOR UPDATE即使没查到行，也可能加间隙锁（防止幻读）
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虽然锁得更严，但如果业务只需要防更新丢失（lost update），不关心幻读，过度锁间隙反而拖慢吞吐
容易被忽略的隐式锁与唯一索引冲突
当两个事务几乎同时尝试插入同一条唯一键（如 INSERT INTO users (email) VALUES ('a@b.com')），即使没显式加锁，InnoDB 也会在唯一索引上加隐式 X 锁。这时后到的事务会等前一个事务结束，如果前一个回滚了，后一个才能继续；如果前一个卡住或崩溃，就会表现为“插入卡死”，查 SHOW ENGINE INNODB STATUS 会看到 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 后面跟着唯一索引名。
- 这不是 bug，是唯一约束强制要求的串行化检查机制
- 避免方式不是去掉唯一索引，而是提前用
SELECT ... FOR UPDATE查一遍是否存在，再决定 INSERT 还是 UPDATE（即“select-then-act”模式），但要注意这本身也要在事务里做 - 如果业务允许，用
INSERT ... ON DUPLICATE KEY UPDATE更简洁，它内部也走隐式锁路径，但语法层面屏蔽了等待逻辑
事务里的锁不是开关，是细粒度的资源协商协议。真正难的从来不是写对 FOR UPDATE，而是厘清“我要保护哪几行、谁可能改它们、改的依据是否稳定”。漏掉一个间隙、错估一次索引选择、或者把锁放在错误的隔离级别下，都会让并发变成排队。
