MySQL 什么时候会触发行锁升级为表锁
MySQL 的 InnoDB 存储引擎本身不支持传统意义上的“锁升级”（如 SQL Server 那样主动将大量行锁合并为一个表锁），但某些操作会**间接导致全表范围加锁**，效果等同于表级阻塞。关键触发点是：
ALTER TABLE、
OPTIMIZE TABLE、缺失有效索引的
UPDATE/
DELETE，以及显式使用
LOCK TABLES。 执行
ALTER TABLE t ADD COLUMN x INT（非 ALGORITHM=INPLACE）时，InnoDB 会获取
MDL（metadata lock）+ 全表
X 锁，阻塞所有 DML 没有
WHERE条件或
WHERE列无索引的
UPDATE t SET a=1，会走全表扫描 → 对每个匹配的聚簇索引记录加
X 行锁，同时可能因 gap 锁膨胀引发大量锁冲突
SELECT ... FOR UPDATE在唯一索引上命中单行时只锁该行；但在普通索引或无索引字段上，可能锁住整个索引范围（包括间隙），看起来像“锁变多”
gap 锁和 next-key 锁如何放大锁影响范围
InnoDB 默认事务隔离级别为
REPEATABLE READ，此时普通
SELECT不加锁，但
UPDATE/
DELETE/
SELECT ... FOR UPDATE会使用
next-key lock（行锁 + 左侧 gap 锁）。这本用于防止幻读，但容易被误认为“锁升级”。 假设
id是主键，当前有记录
(1),(5),(10)，执行
SELECT * FROM t WHERE id > 3 AND id ，实际会锁住区间 <code>(1,5]和
(5,10)—— 即
5这一行 +
(5,10)这个间隙 如果查询条件落在空隙中（如
WHERE id = 7），且
7不存在，则只加 gap 锁
(5,10)，允许其他事务插入
6或
8，但会阻塞插入
7关闭 gap 锁的代价是降级到
READ COMMITTED，此时
UPDATE只加行锁，不加 gap 锁，但幻读风险回归
如何验证当前事务持有的锁类型与范围
不能靠猜，得查
information_schema视图或使用
SHOW ENGINE INNODB STATUS。注意：这些信息只反映最近一次死锁或当前活跃锁状态，不是实时全量快照。 查正在等待的锁：
SELECT * FROM information_schema.INNODB_TRX\G关注
TRX_STATE和
TRX_WAITING_LOCK_ID查锁详情：
SELECT * FROM information_schema.INNODB_LOCKS\G（MySQL 5.7+ 已废弃，建议用
performance_schema.data_locks） 更实用的是：
SELECT * FROM performance_schema.data_locks\G中
LOCK_TYPE为
RECORD表示行锁，
LOCK_MODE含
GAP或
NEXT-KEY表示涉及间隙 若看到
LOCK_DATA显示
supremum pseudo-record，说明锁住了索引末尾间隙，常出现在
ORDER BY ... LIMIT场景中
避免隐式锁膨胀的实际操作建议
多数“锁升级感”来自设计或执行偏差，而非 InnoDB 主动升级。核心思路是：让锁尽量窄、尽量短、尽量可预测。
写UPDATE/
DELETE语句前，务必
EXPLAIN确认是否走了索引；避免在
TEXT/
JSON字段或函数包裹列（如
WHERE UPPER(name)='A'）上过滤 批量更新分页处理：用
WHERE id > ? ORDER BY id LIMIT 1000替代
LIMIT 10000,1000，减少扫描和锁数量 高并发更新同一热点行（如计数器）时，考虑改用
INSERT ... ON DUPLICATE KEY UPDATE或应用层重试，避免长事务持锁 业务允许时，把
REPEATABLE READ改为
READ COMMITTED，可消除 gap 锁，但需同步评估幻读对业务逻辑的影响
真正难排查的从来不是“有没有锁”，而是“为什么这个查询锁了不该锁的范围”——索引失效、隐式类型转换、字符集不一致，都可能让 optimizer 选择全表扫描，继而让行锁数量爆炸。盯着
EXPLAIN输出里的
type和
key字段，比背锁机制管用得多。
