InnoDB不存在锁降级，所谓“行锁变表锁”实为未走索引导致全表扫描、逐行加X锁的后果；真正表锁仅来自LOCK TABLES、MyISAM引擎或无主键表的INSERT SELECT等明确场景。
InnoDB 行锁不会主动“降级”为表锁，所谓“退化”其实是优化器放弃索引、被迫全表扫描后，事务不得不对每一行加锁，最终效果等同于表锁——这不是锁类型转换，而是加锁范围失控。
为什么说“锁降级”是误解？
InnoDB 没有运行时将已持有的表锁转成行锁的机制，更不存在把行锁“降级”为表锁的设计。你看到的“行锁变表锁”，本质是：同一事务中，原本想锁几行，结果因条件不走索引，优化器选择全表扫描，于是给所有扫描到的行都加上了行锁——锁的数量爆炸，阻塞效果和表锁无异。
常见误判场景包括：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 执行
UPDATE t SET x=1 WHERE y LIKE '%abc%'，而y列无索引 → 全表扫描 → 每行加 X 锁 → 事务持有数千行锁 → 其他事务更新任意行都被阻塞 - 在
REPEATABLE READ隔离级别下，WHERE条件命中非唯一索引但用了范围查询（如age > 25），触发临键锁覆盖大片间隙，实际锁住的记录+间隙远超预期 - 隐式类型转换导致索引失效，例如
WHERE user_id = '123'（user_id是INT类型），MySQL 自动转成字符串比较 → 索引失效 → 全表扫
真正触发表级锁定的三种明确方式
只有这三类操作会实实在在拿到表锁，和行锁无关：
- 显式执行
LOCK TABLES t WRITE→ 直接获得表级写锁，后续所有 DML（包括SELECT ... FOR UPDATE）都会报错ERROR 1100 (HY000): Table 't' was not locked with LOCK TABLES - 使用 MyISAM 引擎的表 → 默认只支持表锁，
UPDATE或INSERT必然锁整张表 - InnoDB 中对未定义主键/唯一索引的表执行
INSERT ... SELECT或大范围UPDATE，且优化器判定索引代价过高，可能退化为临时表 + 全表加意向锁，配合外部锁等待逻辑，表现如表锁
如何确认是不是真被“锁表”了？
别靠猜测，用这几条命令快速定位：
- 查当前锁等待：
SELECT * FROM performance_schema.data_lock_waits（需开启performance_schema） - 看事务正在执行什么：
SELECT * FROM information_schema.INNODB_TRX，重点关注TRX_ROWS_LOCKED和TRX_QUERY - 检查执行计划：
EXPLAIN FORMAT=tree SELECT ... FOR UPDATE，确认type字段不是ALL或index；如果是，说明没走有效索引 - 观察锁数量突增：
SHOW ENGINE INNODB STATUS\G中的TRANSACTIONS部分，留意 “lock struct(s)” 计数是否异常高（比如 > 5000）
最常被忽略的一点：锁范围不是由 SQL 语句字面决定的，而是由索引结构 + 隔离级别 + 优化器共同决定的。哪怕你写了 WHERE id = 123，只要 id 不是索引列，或该列存在隐式转换，InnoDB 就根本不会按“行”去锁——它连哪一行是目标都找不到。
