MySQL行锁会升级为表锁，主要因全表扫描、大量DML操作或间隙锁/临键锁组合导致锁管理开销过大，InnoDB主动升级为意向锁；需通过索引优化、控制事务粒度等方式避免。
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 行为
误用风险：在高并发计数场景中，仅用 LOCK IN SHARE MODE 无法阻止其他事务并发修改同一行，必须用 FOR UPDATE 才能保证后续 UPDATE 不冲突。
锁的粒度、隔离级别、索引设计、事务长度——这四个因素交织在一起，稍有偏差就会让“看起来没问题”的 SQL 在压测时突然卡住。尤其容易忽略的是：间隙锁不是由用户显式触发的，而是 InnoDB 自动加上的，且只在可重复读下生效。