行锁会因无索引扫描、索引失效或大量间隙锁导致InnoDB被动升级为表锁；可通过TRX_ROWS_LOCKED异常高、heap size超1MB、table_locks_waited上升判断。
行锁为什么会自动升级成表锁？
MySQL 的锁升级不是由用户显式触发的“升级命令”，而是 InnoDB 在特定条件下为避免死锁或降低管理开销，**被动地将多个行锁合并为更粗粒度的锁**——最常见的是退化为表锁。这不是标准行为，而是一种“兜底策略”，只在严重资源压力或索引失效时发生。
-
没有可用索引：执行UPDATE users SET status=1 WHERE name='Alice'，但name列无索引 → InnoDB 无法精确定位行，只能扫描全表，此时会为**所有被扫描过的行加锁**；若扫描比例过高（官方未公开阈值，但实测常超 20%~30%），InnoDB 可能直接放弃行锁，对整张表加意向排他锁（IX）并配合隐式表级阻塞逻辑，效果等同于表锁 -
主键/唯一索引失效：比如用函数包装索引字段：WHERE YEAR(create_time)=2025，即使create_time有索引，也无法走索引 → 全表扫描 → 高概率锁升级 -
大量间隙锁叠加：在 RR 隔离级别下，范围查询如SELECT * FROM orders WHERE amount BETWEEN 100 AND 1000 FOR UPDATE可能锁定数百个间隙；当间隙数量过多、内存锁结构膨胀时，InnoDB 可能降级为对整个索引段加锁（表现类似表锁）
怎么判断锁是否已升级？看这三处关键指标
锁升级不会报错，也不会写日志（除非开启 innodb_status_output_locks），必须靠监控和推理。重点盯住以下三项：
- 查
information_schema.INNODB_TRX表：如果TRX_ROWS_LOCKED值异常高（比如几万甚至几十万），而业务实际只改 1~2 行，基本可断定发生了锁范围失控或隐式升级 - 查
SHOW ENGINE INNODB STATUS\G输出中的TRANSACTIONS和LATEST DETECTED DEADLOCK段：若看到 “lock struct(s), heap size 123456” 中heap size超过 1MB，说明锁对象占用内存过大，InnoDB 已倾向简化处理 - 观察
table_locks_waited状态变量：执行SHOW GLOBAL STATUS LIKE 'table_locks%';，若table_locks_waited显著上升（尤其伴随table_locks_immediate下降），说明有非 MyISAM 引擎的语句正在遭遇表级阻塞 —— 很可能是 InnoDB 锁升级后引发的连锁反应
并发卡顿真凶：不是锁多，是锁“乱”
1000 并发不卡，和 10 并发卡死，区别往往不在锁数量，而在锁的**分布模式与等待链长度**。典型陷阱如下：
-
无序更新主键：事务 A 执行UPDATE t SET x=1 WHERE id=100; UPDATE t SET x=1 WHERE id=1;，事务 B 反过来先更新id=1再更新id=100→ 极易形成循环等待，触发死锁检测并回滚，但重试逻辑若没控制好，会反复抢占 → 表现为“慢而不报错” -
全表扫描 + FOR UPDATE：哪怕只改 1 行，只要 SQL 触发了全表扫描再加锁，就会让其他所有想读/写该表的事务排队等待 —— 这是并发吞吐量断崖下跌的最常见原因 -
长事务持有锁：一个事务执行BEGIN; SELECT ... FOR UPDATE;后不做COMMIT或ROLLBACK，哪怕只持锁 5 秒，也会让后续所有冲突语句在innodb_lock_wait_timeout（默认 50 秒）内排队等待 → 大量线程堆积，连接数暴涨
SELECT trx_id, trx_state, trx_started, trx_rows_locked, trx_query FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT';
真正难排查的，并不是“有没有锁”，而是“谁在等谁、为什么等、等了多久”。锁升级只是表象，背后往往是索引设计缺陷、SQL 写法失当或事务边界模糊——这些才是并发性能的隐形天花板。
