MySQL 更新范围很小却锁住很多行怎么排查索引和范围

MySQL 里一条 UPDATE 只改几行，却让其他请求长时间等待，最常见的误判是“锁按命中的行计算”。InnoDB 实际按执行过程中访问到的索引记录加锁；如果 WHERE 条件没有形成有效索引路径，或者范围条件落在非唯一索引上，锁住的可能是更宽的索引区间，甚至包含 gap。排查顺序应是：先看 UPDATE 的执行计划，再看当前锁的索引与状态，最后检查事务是否把锁持有得太久。

先用 EXPLAIN 确认更新到底扫描了哪些索引记录

先把真实 UPDATE 复制出来，只替换参数，不要直接在生产环境试改。MySQL 支持对 UPDATE 使用 EXPLAIN；重点关注 type、key、key_len、rows 和 Extra。range 表示在索引区间内扫描，ALL 则说明没有找到可用的访问路径。这里的 rows 是优化器估算的扫描量，不等于最终修改行数，但它能提示锁范围为什么会比业务条件想象得大。

-- 只查看计划，不执行这条 UPDATE
EXPLAIN UPDATE orders
SET    status = 'closed'
WHERE  tenant_id = 42
  AND  created_at 

如果现有索引是 (tenant_id, created_at)，而业务还要按 status 过滤，MySQL 可能先扫描租户和时间范围，再逐条判断状态。若索引是单列 status，则可能扫描大量 pending 记录。不要只凭索引“存在”就认定它合适，还要核对列顺序是否贴合最常用的等值条件和范围条件。

再用 data_locks 还原锁住的索引与等待链

执行计划只能告诉你“可能扫描什么”，不能告诉你“此刻谁挡住了谁”。锁等待发生时，先查当前等待锁，再把锁请求和持有者的事务 ID 对上。data_locks 会给出对象、索引、锁类型、锁模式和 GRANTED 或 WAITING 状态；data_lock_waits 用于表达阻塞关系。

-- 只筛 InnoDB 的当前锁，避免把无关对象混在一起
SELECT ENGINE_TRANSACTION_ID,
       OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME,
       LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA
FROM performance_schema.data_locks
WHERE ENGINE = 'INNODB'
ORDER BY OBJECT_SCHEMA, OBJECT_NAME, ENGINE_TRANSACTION_ID;

-- 把等待者和阻塞者连接起来，先确认阻塞链再处理会话
SELECT w.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_trx,
       w.BLOCKING_ENGINE_TRANSACTION_ID   AS blocking_trx,
       r.OBJECT_SCHEMA, r.OBJECT_NAME, r.INDEX_NAME,
       r.LOCK_MODE AS waiting_mode,
       b.LOCK_MODE AS blocking_mode
FROM performance_schema.data_lock_waits AS w
JOIN performance_schema.data_locks AS r
  ON r.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID
JOIN performance_schema.data_locks AS b
  ON b.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID;

看到 INDEX_NAME 后，再回头对照表结构。非唯一索引上的范围更新可能涉及记录锁与间隙锁；在默认隔离行为下，InnoDB 会用 next-key locking 组合记录锁和 gap lock 来防止幻读。因此“只更新一条业务状态”并不自动等于“只影响一条索引记录”。

按范围、隔离级别和事务边界缩小影响面

隔离级别要放在证据之后讨论。它会改变读操作的可见性和部分锁行为，却不能替代正确索引；MySQL 官方也建议为 UPDATE 和锁定读使用合适索引、缩短事务，并让多事务按相同顺序访问资源。不要为了消除一次等待就全局修改隔离级别，先在同样数据量和并发下复现计划与锁链。

把死锁与超时处理成可恢复的运行手册

普通锁等待通常是一个事务持有锁、另一个事务等待；死锁则是多个事务互相等待，InnoDB 会检测并回滚其中一个事务。遇到 1205 或 1213，应用需要回滚当前事务再按退避策略重试，不能只重发最后一条 SQL。排查期可用 SHOW ENGINE INNODB STATUS 查看最近一次死锁；若问题频繁，再临时打开 innodb_print_all_deadlocks 收集错误日志，复盘完成后关闭。

相关问题

为什么影响行数很小，锁等待却很长？

影响行数是最终修改结果，等待时间取决于访问路径、先取得的锁以及阻塞事务何时提交。先看 EXPLAIN UPDATE 和 data_locks，不要用影响行数代替锁范围判断。

加了索引后还会锁很多行吗？

会。索引只能改变访问路径；范围条件、非唯一索引、gap lock、事务未提交和其他索引维护仍可能造成等待。需要重新确认实际使用的索引和锁模式。

能不能直接调小 innodb_lock_wait_timeout？

它只改变等待多久后报错，不会减少锁范围，也不能解决死锁结构。先修正事务边界和访问顺序，再把超时作为故障暴露与重试策略的一部分。