mysql中InnoDB存储引擎的并发事务控制-mysql教程-PHP中文网

select不加锁却可能阻塞其他事务，因其在repeatable read下执行select...for update时会加间隙锁，范围超出实际命中记录，导致插入被阻塞。

mysql中innodb存储引擎的并发事务控制

为什么 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，它们能实时反映行锁、间隙锁、意向锁的归属和等待关系。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

查本事务锁：执行

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'），避免单次扫描过大范围