SELECT FOR UPDATE 会阻塞，但仅当目标行已被其他事务持有冲突的X锁或间隙锁时；若无索引导致全表扫描，或未开启事务，也会引发意外阻塞或失效。
SELECT FOR UPDATE 会阻塞吗？取决于三件事
会，但不是无条件阻塞——它只在目标行已被其他事务加了冲突锁（比如另一个事务正在用 FOR UPDATE 或 UPDATE 锁着同一行）时才阻塞。没冲突就直接拿锁、不等。
- 阻塞的前提是：被查的那行数据当前正被别的事务持有着
X锁（排他锁），且该事务还没提交或回滚 - 如果
WHERE条件没命中任何索引，InnoDB 会全表扫描并给每行加锁，效果上等于锁整张表，这时几乎所有后续涉及该表的写操作都会被阻塞 - 在
REPEATABLE READ隔离级别下，哪怕只查一行，也可能因间隙锁（gap lock）把附近“空隙”也锁住，导致插入新记录的语句被阻塞——这容易被误认为“莫名其妙卡住”
为什么加了 FOR UPDATE 还像没锁一样？
最常见的原因是没开事务，锁加了秒释放，等于白加。
- MySQL 默认
autocommit = 1，单条SELECT ... FOR UPDATE执行完立刻提交，锁同步释放 - 必须显式执行
START TRANSACTION（或SET autocommit = 0），再执行FOR UPDATE，锁才会持续到COMMIT或ROLLBACK - 漏掉
COMMIT会导致锁长期持有，拖垮并发；提前COMMIT则锁过早释放，业务逻辑中间可能被并发修改
哪些 WHERE 条件会让 FOR UPDATE 实际锁全表？
不是语法写错，而是索引没建对，InnoDB 就只能扫全表加锁。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
WHERE name = 'Alice'—— 若name列没索引，或只有低区分度索引（如只有两个值的status字段），优化器可能直接走全表扫描 -
WHERE phone LIKE '%138'—— 左模糊无法走索引，同样触发全表扫描加锁 -
WHERE created_at > '2025-01-01'—— 如果created_at是普通索引但范围太大，InnoDB 可能判定为“不如全扫”，尤其当匹配行数超过约 20% 总行数时
怎么快速确认是不是锁导致的阻塞？
别猜，直接看 InnoDB 的实时锁状态。
- 执行
SHOW ENGINE INNODB STATUS\G，重点看TRANSACTIONS段里的两块：WAITING FOR THIS LOCK TO BE GRANTED:和HOLDS THE LOCK(S): - 若看到
lock_mode X locks rec but not gap waiting，说明正在等某一行的记录锁；若是lock_mode X locks gap before rec，那就是被间隙锁拦住了 - 注意：这个命令输出是快照，且只保留最近一次死锁详情（在
LATEST DETECTED DEADLOCK段），不是实时流
真正难处理的从来不是“锁不锁”，而是“锁了什么、为什么锁、谁在等”。间隙锁和索引失效这两块，最容易在线上静默引发大面积阻塞，却查不出明显慢 SQL。
