InnoDB会在WHERE条件未走索引、优化器放弃索引、显式LOCK TABLES、混合引擎或隐式主键缺失时从行锁升级为表锁；其本质是加行锁成本过高或无法精确定位行所致。
什么时候InnoDB会从行锁升级为表锁
InnoDB默认用行锁，但行锁不是永远“守约”的——一旦条件不满足，它会悄悄升级成表锁，而你可能完全没意识到。这不是bug，是设计使然：当MySQL发现加行锁成本太高、或无法安全加行锁时，就会退回到更粗粒度的表级锁定。
-
WHERE条件没走索引（比如对无索引字段查询、或LIKE '%abc'导致索引失效），InnoDB无法精确定位行，只能全表扫描 → 全表加锁 → 实际等效于表锁 - 语句虽带索引，但优化器判断走索引比全表扫描还慢（例如小表、或索引选择性极差），于是放弃索引 → 同样触发表锁
- 显式执行
LOCK TABLES ... WRITE，哪怕表是InnoDB引擎，也会强制上表级写锁，覆盖原有行锁逻辑 - 事务中混合使用不同引擎的表（如InnoDB + MyISAM），MySQL服务器层可能统一降级为表锁协调
怎么确认当前SQL到底用了行锁还是表锁
不能靠猜，得看实际加锁行为。最直接的方式是查 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCKS（MySQL 5.7+）或用 SHOW ENGINE INNODB STATUS，但后者信息杂乱难读。推荐组合操作：
- 在事务未提交前，执行
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX，看TRX_ROWS_LOCKED和TRX_LOCK_STRUCTS字段值；若前者远大于1且后者为0，大概率已升级为表锁（因为行锁结构没建起来） - 开启锁监控：
SET GLOBAL innodb_status_output_locks = ON，再跑SHOW ENGINE INNODB STATUS，关注 “TRANSACTIONS” 部分里 “lock_mode X locks table” 还是 “lock_mode X locks rec but not gap” - 用
EXPLAIN FORMAT=tree或EXPLAIN ANALYZE看执行计划是否真正走了索引；没走，就别指望行锁
为什么加了索引还是被表锁了
这是最让人困惑的场景：明明 EXPLAIN 显示用了索引，更新却卡住整张表。根本原因在于——InnoDB的行锁对象是索引项，不是记录本身；而二级索引+聚簇索引的双重锁定机制，可能让锁范围意外扩大。
- 更新语句用二级索引定位（如
UPDATE t SET x=1 WHERE name='a'），InnoDB先在name索引上加X锁，再回表到主键索引加X锁；如果name索引非唯一，可能锁住多个主键值 → 锁范围变大，甚至因间隙锁（gap lock）覆盖更多行 - 事务隔离级别为
REPEATABLE READ时，默认启用间隙锁，WHERE条件若落在索引间隙中（比如查不到数据但范围存在），会锁住整个间隙 → 表面看只查一行，实际锁了一片 - 隐式主键缺失：建表没定义主键，InnoDB用隐藏的
GEN_CLUST_INDEX，该索引无业务意义，容易导致锁分布不可控，看似单行操作却引发大面积阻塞
如何避免意外锁升级影响线上服务
锁升级不是性能问题，是稳定性风险——一个慢查询可能让整张表写入挂起几十秒。预防的核心是让InnoDB“愿意且能够”加行锁。
- 所有高频
WHERE、JOIN、ORDER BY字段必须有合适索引；尤其注意UPDATE/DELETE的过滤条件，宁可冗余建索引，也不要赌优化器选对路 - 避免在索引字段上做函数操作，比如
WHERE YEAR(create_time) = 2025→ 改成WHERE create_time BETWEEN '2025-01-01' AND '2025-12-31' - 批量更新控制单次数量，用
LIMIT分页执行；否则大事务可能触发锁升级或长时间持有锁 - 监控关键指标：
table_locks_waited持续上升说明表锁争用严重；Innodb_row_lock_waits突增则提示行锁冲突加剧，两者要交叉看
锁升级往往发生在低频路径或压测盲区，上线前用真实数据量+生产查询模式做一次锁行为验证，比任何文档都管用。
