mysql中基于锁的并发控制与事务控制机制

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

MySQL 的行锁为什么有时会升级成表锁

InnoDB 默认使用行级锁，但不是所有场景都真正锁住单行。当查询条件无法使用索引（比如

WHERE name LIKE '%abc'

），优化器可能放弃走索引，触发全表扫描，此时 InnoDB 会为**扫描到的每一行**加记录锁；更关键的是，如果事务中后续执行了 DML 操作（如

UPDATE

或

DELETE

）且涉及大量数据，或存在间隙锁（

gap lock

）与临键锁（

next-key lock

）组合，死锁检测或锁管理开销上升，InnoDB 可能主动将锁升级为表级意向锁（

LOCK_IS

LOCK_IX

），进而阻塞其他事务对整张表的写入。

避免方式：

确保
WHERE
条件字段有有效索引，用
EXPLAIN
验证是否走了索引避免在事务中执行无过滤的
SELECT ... FOR UPDATE
控制事务粒度，减少长事务持有锁的时间 注意唯一索引和非唯一索引下间隙锁行为差异：唯一索引等值查询不加 gap lock，非唯一索引或范围查询会加

READ COMMITTED 和 REPEATABLE READ 下的锁行为差异

InnoDB 的默认隔离级别是

REPEATABLE READ

，它通过 next-key lock（记录锁 + 间隙锁）防止幻读；而

READ COMMITTED

只使用记录锁（record lock），每次快照读都基于语句开始时的最新已提交版本，不加间隙锁，因此允许幻读，但锁粒度更小、并发更高。

典型影响：

在
REPEATABLE READ
下执行
SELECT * FROM t WHERE id > 10 FOR UPDATE
，会锁住 id > 10 的所有现有记录，以及这些记录之间的间隙（包括可能插入新行的位置）相同语句在
READ COMMITTED
下只锁住当前已存在的满足条件的行，不锁间隙，新行可被其他事务插入
UPDATE
和
DELETE
在两种级别下都会先定位再加锁，但
REPEATABLE READ
会多出间隙保护逻辑

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE; -- 不锁 gap，其他事务仍可 INSERT status='pending'

如何查看当前事务持有的锁和阻塞关系

MySQL 8.0+ 提供了

performance_schema

中的锁视图，比老版本依赖

SHOW ENGINE INNODB STATUS

更结构化。核心是查三张表：

data_locks
：列出每个事务当前持有的锁（包括锁类型、锁模式、锁定的索引/记录）
data_lock_waits
：显示哪个事务在等待哪个事务的哪把锁
innodb_trx
：提供事务 ID、状态、运行时间、SQL 等上下文

常用诊断组合：

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 performance_schema.data_lock_waits w
INNER JOIN performance_schema.data_locks r ON w.BLOCKING_ENGINE_LOCK_ID = r.ENGINE_LOCK_ID
INNER JOIN performance_schema.data_locks b ON w.BLOCKED_ENGINE_LOCK_ID = b.ENGINE_LOCK_ID
INNER JOIN information_schema.INNODB_TRX r_trx ON r.trx_id = r_trx.trx_id
INNER JOIN information_schema.INNODB_TRX b_trx ON b.trx_id = b_trx.trx_id;

注意：

performance_schema

默认可能未启用锁相关采集，需确认配置：

performance_schema = ON

且

setup_instruments

中

wait/lock/innoDB/lock_sys

为

ENABLED

。

显式加锁语句中

FOR UPDATE

与

LOCK IN SHARE MODE

的实际区别

二者都用于在查询时加锁，但锁类型和兼容性完全不同：

SELECT ... FOR UPDATE
加的是排他锁（
X lock
），阻止其他事务对该记录加任何锁（包括 S 和 X）
SELECT ... LOCK IN SHARE MODE
加的是共享锁（
S lock
），允许多个事务同时持有 S 锁，但阻止任何事务加 X 锁在
REPEATABLE READ
下，两者都会触发 next-key lock（即带间隙保护），不只是锁记录本身若查询命中唯一索引且是等值条件，
LOCK IN SHARE MODE
可能退化为仅记录锁（不锁间隙），而
FOR UPDATE
仍保持 next-key 行为

误用风险：在高并发计数场景中，仅用