没走索引时，InnoDB不会自动升级为表锁，而是因全表扫描对所有扫描行加行锁，导致实际效果等同于表锁；根本原因是锁加在索引上，无索引则无法精确定位，被迫扫描并锁定全部聚集索引记录及间隙。
没走索引时，InnoDB 自动升级为表锁
MySQL 的 InnoDB 引擎默认用行锁，但前提是查询能通过索引快速定位数据。一旦 WHERE 条件字段没建索引，或者索引失效，InnoDB 就得全表扫描——它会把扫描过程中碰到的每一行都加上行锁，实际效果等同于锁住整张表。
常见触发场景：
-
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，即记录锁 + 间隙锁。如果条件字段没索引，它会扫描全表，并对所有索引间隙加锁——包括最大值之后的“上界间隙”，导致新插入被全面阻塞，现象上极像表锁。
验证方式：
- 执行
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX查看事务状态和锁等待 - 用
SHOW ENGINE INNODB STATUS\G观察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）都默认加表锁，与条件是否走索引无关
真正容易被忽略的点是：锁类型不取决于你写了什么语句，而取决于 MySQL 实际执行路径。哪怕你写了 WHERE id = 100 FOR UPDATE，只要 id 列被意外删了索引，或者该表用了 MyISAM 引擎，结果就是表锁。查 EXPLAIN 和 INFORMATION_SCHEMA.INNODB_TRX 比翻代码更快定位问题。
