InnoDB从不主动将行锁升级为表锁，所谓“锁升级”实为WHERE条件未走索引导致全表扫描、逐行加X锁或Next-Key锁，锁范围等效于表锁。
没走索引时，InnoDB 实际加的是大量行锁，不是“升级”成表锁
MySQL InnoDB 从不主动把行锁“升级”为表锁。所谓“退化为表锁”，是全表扫描时对每行都加 X 锁（或 Next-Key Lock）的副作用——效果等同于表锁，但底层仍是行锁机制在运行。
关键点在于：InnoDB 的行锁对象是 索引记录，不是数据行本身。WHERE 条件字段没索引 → 优化器选 type: ALL → 聚簇索引全扫描 → 对扫描到的每一行都加锁。500 行？加 500 个 X 锁；50 万行？加 50 万个 X 锁。并发事务一来，就卡死。
常见触发场景包括：
-
WHERE phone = '138'，但phone是VARCHAR字段，传了整数138→ 隐式转换导致索引失效 -
WHERE SUBSTRING(name, 1, 2) = '张'→ 函数使索引无法下推 -
WHERE city = 'SZ'，但联合索引是(name, city)→ 最左前缀不匹配 -
WHERE name LIKE '%admin%'，且name无索引 → 只能全扫
RR 隔离级别放大锁范围：Next-Key Lock 让“锁几行”变成“锁一片”
可重复读（RR）是 MySQL 默认隔离级别，它用 Next-Key Lock（记录锁 + 间隙锁）防幻读。哪怕你只更新一行，只要 WHERE 条件涉及范围或非唯一索引，InnoDB 就会锁住值本身 + 后续间隙。
例如：UPDATE orders SET status = 2 WHERE created_at > '2026-01-01'，created_at 有索引但不唯一 → InnoDB 不仅锁所有匹配记录，还锁住这些记录之间的所有间隙，甚至可能覆盖未插入的未来时间点。这在业务上表现为：明明只改几单，却阻塞了新订单插入。
对比读已提交（RC）：
- RC 下，同一语句只锁实际匹配的行，不加间隙锁，执行完即释放不匹配行的锁
- RR 下，同样语句锁整个索引区间，范围可能远超预期
怎么确认是不是真没走索引？别只看执行计划
EXPLAIN 显示 type: ALL 或 key: NULL 是强信号，但还不够。真正要验证锁行为，得看 performance_schema.data_locks（MySQL 8.0+ 唯一可靠来源）：
执行完可疑 SQL 后，立即查：
SELECT ENGINE_TRANSACTION_ID, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_DATA FROM performance_schema.data_locks WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table';
如果看到大量 RECORD 类型锁，且 LOCK_DATA 是不同主键值，说明确实是逐行加锁；若出现 TABLE 类型锁，则是显式锁表（如 LOCK TABLES）或 DDL 触发，和索引无关。
注意：SHOW ENGINE INNODB STATUS\G 只显示最近一个事务的锁信息，静默持有者会被漏掉。
MyISAM 的表锁和 InnoDB 的“伪表锁”本质不同
MyISAM 的写操作天然就是表级锁，不管条件有没有索引、是否命中，UPDATE 就是整表排他。而 InnoDB 在无索引时的“表锁感”，是大量行锁叠加 + RR 级别间隙锁共同作用的结果，资源消耗更高、死锁风险更大、排查更隐蔽。
最容易被忽略的一点是：这种“伪表锁”在高并发下会快速耗尽锁内存（innodb_row_lock_waits 上升），进而触发更激进的锁等待策略，让问题雪球式恶化。线上一旦发现慢 UPDATE 伴随大面积阻塞，第一反应不该是调参，而是立刻检查 WHERE 字段是否有有效索引、是否被隐式转换或函数污染。
