在没有命中索引的情况下，InnoDB 并不会真的“自动升级”为表锁，而是因为执行全表扫描时，会对扫描到的记录逐行加锁，最终呈现出与表锁非常接近的效果；本质原因在于 InnoDB 的锁是加在索引上的，没有索引就无法精准定位目标数据，只能扫描并锁住全部聚集索引记录以及相关间隙。

没走索引时，InnoDB 自动升级为表锁

MySQL 的 InnoDB 存储引擎默认采用行锁机制，但前提是查询条件能够借助索引快速定位到目标行。一旦 WHERE 条件字段没有建立索引，或者索引失效，InnoDB 就只能执行全表扫描——它会对扫描过程中命中的每一行加上行锁，因此最终效果看起来就像锁住了整张表。这也是很多人排查 MySQL 表锁问题时最容易忽视的原因。

常见触发场景：

• WHERE phone = '138'，而 phone 字段无索引 → EXPLAIN 显示 type: ALL
• WHERE YEAR(create_time) = 2025 → 对字段使用函数会导致索引失效
• WHERE user_id = '123'（user_id 是 INT 类型）→ 隐式类型转换会让索引无法正常命中
• WHERE name LIKE '%abc' → 左模糊查询通常无法使用 B+ 树索引

显式加锁语句在非事务中不生效

SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 表面上看是在加行锁，但如果这些语句没有放在 BEGIN/START TRANSACTION 这样的事务范围内执行，那么语句一执行完，锁也会立即释放。换句话说，其他事务可能还没来得及感知，这把锁就已经消失了，更谈不上真正实现并发控制。实际使用中，这种情况很容易被误判：看起来像是用了行锁，实际上几乎等于没锁，后续一旦出现并发竞争，还可能进一步造成类似表级阻塞的现象，尤其是在高并发环境下，多个短事务反复扫描同一个未建索引字段时更为明显。

务必确认：

• 当前连接是否已开启事务（查 SELECT @@autocommit，值为 0 才更稳妥）
• 是否在事务内执行了加锁语句，且未提前 COMMIT 或 ROLLBACK
• ORM 框架是否自动包裹事务（如 Django 的 transaction.atomic、Spring 的 @Transactional）

RR 隔离级别下间隙锁放大锁定范围

在默认的 REPEATABLE READ 隔离级别下，InnoDB 遇到范围查询（例如 WHERE id > 100、WHERE created_at BETWEEN '2026-01-01' AND '2026-12-31'）时，通常会使用 Next-Key Lock，也就是“记录锁 + 间隙锁”的组合。如果条件字段没有索引，问题就会被进一步放大：数据库往往需要扫描整张表，并锁住所有相关索引间隙，甚至连最大值之后的“上界间隙”也会一起锁住。这样一来，新数据插入操作几乎会被整体阻塞，表现出来就非常像 MySQL 表锁。

验证方式：

• 执行 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX 查看事务状态和锁等待情况
• 用 SHOW ENGINE INNODB STATUSG 观察 TRANSACTIONS 和 LATEST DETECTED DEADLOCK 部分
• 切换隔离级别测试：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED 后重试，若阻塞消失，基本可以判断是间隙锁导致

ALTER TABLE 或 LOCK TABLES 直接触发表锁

这类 DDL 语句或显式加锁命令不会走行锁逻辑，而是直接申请表级排他锁（X 锁）或共享锁（S 锁）。尤其是在老版本 MySQL 中，ALTER TABLE 往往几乎全程锁表；即使新版本支持在线 DDL，某些操作（例如修改列类型、删除主键）依然需要短时间表锁。

典型表现：

• ALTER TABLE users ADD COLUMN status TINYINT DEFAULT 0 → 可能阻塞所有 SELECT 和 UPDATE
• LOCK TABLES orders WRITE → 其他会话对 orders 表的所有读写立即报错 ERROR 1099 (HY000): Table 'orders' was locked with a READ lock and can't be updated
• MyISAM 表任何写操作（INSERT/UPDATE/DELETE）都默认加表锁，与条件是否走索引无关

真正容易被忽略的一点是：锁的类型并不取决于你写了什么 SQL，而取决于 MySQL 最终选择的执行路径。哪怕你写的是 WHERE id = 100 FOR UPDATE，只要 id 列的索引被误删，或者这张表使用的是 MyISAM 引擎，最后产生的依然可能是表锁。相比反复翻代码，优先查看 EXPLAIN 和 INFORMATION_SCHEMA.INNODB_TRX，通常能更快定位 MySQL 行锁变成“表锁效果”的真正原因。