UPDATE没走索引会锁全表，因InnoDB行锁加在索引上，无索引时退化为聚簇索引全扫描并加X锁，RR级别下还触发Gap Lock和Next-Key Lock，逻辑上锁整表。
为什么 UPDATE 没走索引会锁全表
MySQL InnoDB 的行锁本质是加在索引上的，不是加在数据行上。当 UPDATE 或 DELETE 语句的 WHERE 条件无法命中任何索引（比如字段没建索引、用了函数、类型隐式转换、或 OR 导致索引失效），InnoDB 就无法精确定位目标行，只能退化为聚簇索引全扫描 —— 也就是遍历所有主键记录，并对每一条都加 X 锁。
在默认的可重复读（RR）隔离级别下，这种全扫描还会触发间隙锁（Gap Lock）和临键锁（Next-Key Lock），把所有扫描过的索引间隙也锁住，结果就是逻辑上“锁了整张表”。这不是 MySQL 主动升级，而是锁机制在无索引场景下的自然表现。
- 典型错误写法：
UPDATE users SET status = 1 WHERE SUBSTRING(phone, 1, 3) = '138'（函数导致索引失效） - 常见隐式转换：
WHERE user_id = '123'（user_id是INT，传字符串会放弃索引） - 排查方法：执行
EXPLAIN看type是否为ALL，key是否为NULL
gap lock 和 next-key lock 如何扩大锁范围
RR 隔离级别下，InnoDB 用临键锁（Next-Key Lock = Record Lock + Gap Lock）防止幻读。这意味着哪怕你只更新一行，只要 WHERE 条件涉及范围（如 BETWEEN、>=、LIKE 'abc%'），它就可能锁住“值本身 + 后面的间隙”，甚至跨行锁定。
例如：UPDATE orders SET paid = 1 WHERE created_at > '2026-04-01'，若 created_at 有索引但无唯一性，InnoDB 会锁定所有满足条件的记录，以及这些记录之间的间隙 —— 如果索引页里存在多个时间点，实际锁住的可能是几十甚至上百行，远超你的预期。
- 关键点：
SELECT ... FOR UPDATE或写操作在 RR 下都会触发临键锁，RC 下则只锁匹配行，不锁间隙 - 验证方式：查
information_schema.INNODB_TRX和INNODB_LOCKS（MySQL 5.7+ 已移除，改用performance_schema.data_locks） - 影响：锁范围越大，事务等待越久，死锁概率越高
唯一索引 vs 普通索引对锁粒度的影响
同样是等值查询，唯一索引（含主键）和普通索引的锁行为完全不同。唯一索引能精确锚定单行，InnoDB 只加 Record Lock；而普通索引即使查到唯一值，也可能先锁二级索引项，再通过主键回表，过程中若涉及范围扫描或未提交事务，就可能多锁几行。
更隐蔽的是：如果 WHERE 条件用了普通索引字段，但该字段允许 NULL，InnoDB 在 RR 下会把所有 NULL 值所在间隙也纳入 Gap Lock 范围 —— 这些间隙往往被忽略，却是并发冲突高发区。
- 示例：
UPDATE users SET name = 'a' WHERE email = 'x@y.z'，若email是普通索引且有大量NULL，可能意外锁住一堆空值间隙 - 优化建议：高频等值更新字段尽量建唯一索引；非唯一字段更新时，确认是否真需要 RR 隔离级别
- 注意：
INSERT ... ON DUPLICATE KEY UPDATE在唯一冲突时会加 insert intention lock，也可能与 gap lock 冲突
如何快速判断当前 SQL 锁了哪些行/间隙
不能只看 SQL 表面逻辑，得结合执行计划、索引结构、事务隔离级别三者交叉验证。最直接的方式是复现问题后立刻查 performance_schema.data_locks（MySQL 8.0+）或 INNODB_ENGINE_STATUS 输出（5.7）。
例如执行 SELECT * FROM performance_schema.data_locks WHERE LOCK_TRX_ID = 'xxx';，返回中 LOCK_MODE 为 X,REC_NOT_GAP 是纯行锁，X,GAP 是间隙锁，X,NEXT-KEY 是临键锁 —— 后两者才是真正容易引发阻塞的“隐形范围锁”。
- 别依赖
SHOW PROCESSLIST，它只显示线程状态，不反映锁对象 -
SELECT ... FOR UPDATE在 RR 下也会锁间隙，和写操作一样危险 - 最易被忽略的一点：长事务未提交，会让它持有的所有锁（包括早已执行完的语句所加的锁）一直不释放
