SELECT不加锁却可能阻塞其他事务，因其在REPEATABLE READ下执行SELECT...FOR UPDATE时会加间隙锁，范围超出实际命中记录，导致插入被阻塞。
为什么 SELECT 不加锁却可能阻塞其他事务
InnoDB 的 SELECT 默认走一致性读（consistent read），不加锁，但前提是事务隔离级别为 REPEATABLE READ 或更低。一旦出现 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE，就会触发行级锁，且锁的范围可能超出实际命中的记录——比如在非唯一索引上进行范围查询时，会加上间隙锁（gap lock），导致其他事务在该间隙插入被阻塞。
- 执行
SELECT * FROM t WHERE k BETWEEN 5 AND 10 FOR UPDATE，即使表中只有k=6和k=9两行，InnoDB 也可能锁住 (5,10) 这个间隙，阻止插入k=7 - 若字段
k没有索引，InnoDB 会退化为表锁（实际是给所有聚簇索引记录加 record lock + 给每个间隙加 gap lock），并发性能骤降 -
READ COMMITTED隔离级别下 gap lock 被禁用，但幻读风险上升；REPEATABLE READ下 gap lock 默认开启，是避免幻读的核心机制
INSERT 为什么会触发死锁
InnoDB 在插入新记录前，会先对插入位置的间隙加插入意向锁（insert intention lock），这是一种特殊的 gap lock。当两个事务试图向同一间隙插入不同记录时，它们的插入意向锁并不冲突；但如果其中一个事务已持有了该间隙的 gap lock（比如前一个事务执行了 SELECT ... FOR UPDATE 范围查询），后一个事务的插入意向锁就无法获取，形成等待链。
- 事务 A：执行
SELECT * FROM t WHERE id > 100 FOR UPDATE→ 锁住间隙 (100, +∞) - 事务 B：执行
INSERT INTO t VALUES (101, ...)→ 请求插入意向锁，与事务 A 的 gap lock 冲突，等待 - 事务 C：同样执行
INSERT INTO t VALUES (102, ...)，也等待；若此时事务 A 又去更新某行触发另一把锁，就可能被检测为死锁 - 死锁日志中常见
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: ... insert intention lock ...
如何查看当前事务持有的锁
MySQL 8.0+ 提供了 performance_schema 中的锁视图，比老版本的 SHOW ENGINE INNODB STATUS 更结构化、可查询。关键表是 data_locks 和 data_lock_waits，它们能实时反映行锁、间隙锁、意向锁的归属和等待关系。
- 查本事务锁：执行
SELECT * FROM performance_schema.data_locks WHERE THREAD_ID = (SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID = CONNECTION_ID());
- 查锁等待：执行
SELECT * FROM performance_schema.data_lock_waits;
，输出包含 blocking_trx_id 和 requesting_trx_id，直接定位谁在等谁 - 注意：
performance_schema默认可能未启用锁监控，需确认配置项performance_schema = ON且setup_instruments中wait/lock/innodb/row_lock为ENABLED
UPDATE 没走索引时锁全表的风险
InnoDB 的行锁是建立在索引记录上的。如果 UPDATE 语句的 WHERE 条件未命中任何索引（包括主键、唯一索引、普通索引），优化器会选择全表扫描，此时每条扫描到的记录都会被加上 record lock；更严重的是，还会对每两个相邻记录之间的间隙加 gap lock —— 实际效果接近逻辑上的“锁表”，尤其在大表上极易引发大面积阻塞。
- 典型错误：对没有索引的
status字段执行UPDATE orders SET paid = 1 WHERE status = 'unpaid'，哪怕只改 10 行，也可能锁住数万行 - 验证是否走索引：用
EXPLAIN看type是否为ALL或index，以及key列是否为NULL - 补救方式：添加合适的索引，或改用分批更新（如
WHERE id BETWEEN ? AND ? AND status = 'unpaid'），避免单次扫描过大范围
锁的粒度和行为高度依赖索引结构与隔离级别，不是“用了 InnoDB 就自动高并发”。真正影响线上吞吐的，往往是一条没走索引的 UPDATE，或一个没意识到间隙锁语义的 SELECT ... FOR UPDATE。
