空表执行select for update仍会阻塞，因其加的是间隙锁而非行锁：即使无数据，只要where条件走唯一索引（如id=100），innodb就在对应间隙（如(-∞,+∞)或(99,101)）加锁，防止插入冲突；若未走索引则退化为全表扫描并等效锁表。
空表执行 SELECT FOR UPDATE 为什么还会阻塞？
因为 SELECT ... FOR UPDATE 加的不是“数据行锁”，而是“索引记录锁”或“间隙锁”——哪怕表里没数据，只要查询条件能定位到某个索引范围，InnoDB 就会在对应位置加锁，防止其他事务插入冲突数据。
空表中 WHERE 条件走唯一索引时加什么锁
当表为空，但 WHERE id = 100 中的 id 是主键或唯一索引时，InnoDB 会尝试加“记录锁（Record Lock）”。但由于该记录不存在，它实际加的是“间隙锁（Gap Lock）”，锁定的是 (−∞, +∞) 或相邻索引值之间的空隙。
- 例如：主键为
id，当前无任何数据，SELECT * FROM t WHERE id = 100 FOR UPDATE会锁定间隙 (−∞, +∞)，阻止其他事务插入id = 100的行 - 如果已有
id = 99和id = 101两行，则只锁间隙 (99, 101)，插入id = 100会被阻塞 - 这个行为在
REPEATABLE READ隔离级别下默认触发，READ COMMITTED下间隙锁会被禁用（但仍有临键锁退化行为）
空表全表扫描或无索引条件导致表锁
如果 WHERE 条件没走任何索引（比如 WHERE status = 'pending'，但 status 没建索引），InnoDB 无法精确定位行或间隙，只能退化为全表扫描 —— 此时会为每个已存在的索引页加意向排他锁（IX），并可能升级为表级锁等待机制，导致整个表被逻辑锁定。
- 现象：另一个事务执行
INSERT INTO t VALUES (...)也会被阻塞，哪怕表是空的 - 验证方式：执行
SHOW ENGINE INNODB STATUS\G，查看TRANSACTIONS部分的lock_mode X locks table或lock_mode X locks rec but not gap - 根本原因：没有索引 → 无法使用行锁 → InnoDB 按最保守策略加锁，等效于表锁
为什么事务提交后锁才释放，而不是语句结束就放
SELECT ... FOR UPDATE 的锁生命周期绑定在数据库事务上，不是单条语句。即使查询结果为空，只要事务没 COMMIT 或 ROLLBACK，锁就一直持有。
- 常见误操作：Spring 中用
@Transactional包裹方法，但方法内调用了耗时 RPC 或 sleep(500)，这 500ms 内锁持续占用 - 更隐蔽的问题：事务传播配置为
REQUIRED，但上游已存在事务，导致锁意外延长到整个调用链 - 空表场景下尤其危险：你以为“没数据=没锁”，实际上间隙锁已生效，且没人告诉你它锁了哪段范围
真正容易被忽略的是：锁对象从来不是“数据”，而是“索引结构中的位置”。空表不是安全区，而是间隙锁最活跃的战场。查之前先 EXPLAIN，确保 type 是 const 或 range，且 key 显示走了索引；否则，你面对的可能不是行锁，而是一把沉默的表级枷锁。
