mysql执行SQL过程中会不会加锁_mysql锁流程解析

来源：这里教程网时间：2026-02-28 20:49:48 作者：

MySQL执行SQL时会不会加锁？取决于语句类型和隔离级别

会加锁，但不是所有SQL都加锁，也不是所有场景都加同一类锁。核心判断依据是：

SELECT

是否带

FOR UPDATE

或

LOCK IN SHARE MODE

、

UPDATE

DELETE

是否命中索引、当前事务隔离级别（尤其是

READ COMMITTED

和

REPEATABLE READ

）。

哪些SQL会触发行级锁？重点看WHERE条件是否走索引

MySQL的InnoDB引擎只在能通过索引精确定位记录时才加行锁；否则会升级为表锁或锁住索引范围（间隙锁）。常见情况如下：

UPDATE t SET x=1 WHERE id = 100
：如果
id
是主键或唯一索引，只锁这一行
UPDATE t SET x=1 WHERE name = 'alice'
：如果
name
无索引，可能锁全表；有普通索引则锁匹配的索引项+对应主键行
SELECT * FROM t WHERE id > 50 FOR UPDATE
：在
REPEATABLE READ
下会加临键锁（next-key lock），即行锁 + 间隙锁，防止幻读
INSERT INTO t VALUES (101, 'bob')
：插入前会检查插入位置的间隙是否被锁定，可能触发插入意向锁（insert intention lock）等待

锁类型和兼容性怎么影响并发？别只盯着“行锁”二字

实际执行中，InnoDB常组合使用多种锁：记录锁（Record Lock）、间隙锁（Gap Lock）、临键锁（Next-Key Lock）、插入意向锁（Insert Intention Lock）。它们之间有明确的兼容矩阵，比如：

两个事务对同一行加
SELECT ... FOR UPDATE
：第二个会被阻塞（记录锁互斥）事务A锁了
id=5
，事务B执行
INSERT INTO t VALUES (6, 'x')
：若A持有
(5,10)
的间隙锁，B会等插入意向锁
SELECT ... LOCK IN SHARE MODE
与
SELECT ... FOR UPDATE
不兼容，但多个S锁之间兼容

特别注意：

READ COMMITTED

隔离级别下，InnoDB只加记录锁，不加间隙锁（除外键检查和唯一约束检查），因此幻读可能发生，但锁冲突概率降低。

如何观察正在发生的锁？别只靠猜，用系统表查真实状态

直接查

information_schema

里的锁视图最可靠，但需有

PROCESS

权限：

SELECT 
  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  r.trx_query waiting_query,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread,
  b.trx_query blocking_query
FROM information_schema.INNODB_LOCK_WAITS w
INNER JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;

再配合：

SELECT * FROM information_schema.INNODB_TRX
看当前活跃事务
SELECT * FROM information_schema.INNODB_LOCKS
（MySQL 8.0.1之前）或
performance_schema.data_locks
（8.0.1+）看具体锁对象执行
SHOW ENGINE INNODB STATUS\G
获取最近的死锁详情（含事务堆栈和锁模式）

间隙锁和临键锁不会单独出现在