MySQL在UPDATE中用非索引字段作WHERE条件时，必然锁住所有被扫描的聚簇索引记录，在大表上等效锁全表；根本原因是InnoDB行锁依赖索引定位，无索引则全表扫描并逐行加X锁与间隙锁。
MySQL 在 UPDATE 中用非主键字段（且无索引）做 WHERE 条件时，并不是“会锁全表”，而是“必然锁住所有被扫描的聚簇索引记录”，在大表上效果等同于锁全表——这是 InnoDB 行锁机制的自然结果，不是 bug，也不是配置问题。
为什么没索引的 WHERE 字段会让 UPDATE 锁住几乎所有行
InnoDB 的行锁加在索引上，不是加在“数据行”上。当 WHERE city = 'Beijing' 这类条件没有对应索引时，优化器只能走 type = ALL 全表扫描，引擎层于是对**每一条被 Server 层送过来判断的聚簇索引记录**都加 X 锁（记录锁）+ 间隙锁（Gap Lock），最终锁住整张表的主键范围。
- 哪怕只有一行匹配，InnoDB 也得先扫完全部主键才能确认——所以所有被扫描的主键都被锁了
- 可重复读（RR）隔离级别下，
UPDATE还会自动升级为 next-key 锁，连带锁定值之间的间隙，进一步扩大阻塞面 -
SHOW ENGINE INNODB STATUS里看到trx_rows_locked接近表总行数，就是典型信号
EXPLAIN 看不到索引 ≠ 没建索引，常见失效场景
建了索引但没被用，和根本没建索引，后果一样。以下情况会让索引“形同虚设”：
- 隐式类型转换：
WHERE user_id = '123'（user_id是INT）→ 引擎放弃索引，转全表扫描 - 函数包裹字段：
WHERE DATE(created_at) = '2026-05-01'→ 索引无法命中，必须改写为created_at BETWEEN ... - 字符集/排序规则不一致：比如
utf8mb4列与utf8字符串比较，触发隐式转换 - OR 条件破坏索引选择性：
WHERE status = 'pending' OR is_deleted = 1，即使两字段都有索引，也可能退化为全表扫
强制索引（FORCE INDEX）能绕过这个问题吗
不能。强制索引只影响执行计划选择，不解决底层加锁逻辑：
-
FORCE INDEX (idx_city)对WHERE name = 'alice'（name无索引）直接无效，优化器可能报错或忽略 - 即使强制了一个存在但不匹配查询模式的索引（如用单列
status索引去查WHERE status = ? AND created_at > ?），仍会因不满足最左前缀而退化为索引全扫描，锁大量无关记录 - 真正起作用的是「索引能否让 WHERE 条件精准截断扫描范围」——只有联合索引
(status, created_at)才可能把扫描控制在小范围内
怎么快速验证并修复正在锁全表的 UPDATE
别靠猜，用运行时数据说话：
- 在测试库开事务执行该
UPDATE（不提交），另起连接查：SELECT trx_id, trx_rows_locked, trx_state FROM information_schema.INNODB_TRX WHERE trx_rows_locked > 1000 - 对语句跑
EXPLAIN FORMAT=TRADITIONAL，重点盯三列：type（非ALL）、key（非NULL）、rows（远小于表总行数） - 修复路径唯一：为
WHERE中的字段建高效索引，顺序按等值 → 范围原则排列；建完立刻用EXPLAIN验证，避免统计信息滞后误导判断
最容易被忽略的一点是：锁范围不是由 SQL 执行时间决定的，而是由事务生命周期决定的。哪怕 UPDATE 本身 10ms 完成，只要事务没提交，锁就一直挂着——而 RR 隔离级别下，这些锁还会悄悄带上间隙，把插入新行的路也堵死。
