真正卡住update的是锁等待链，而非超时配置；需用explain确认是否因无索引/隐式转换导致全表扫描加锁，并查innodb_trx中trx_state='lock wait'定位阻塞源。
隐式表锁和Gap锁不会直接导致“超时”，而是让UPDATE卡在锁等待队列里，最终触发Lock wait timeout exceeded错误。真正要查的不是“锁类型”，而是“为什么本该走索引的语句退化成了全表扫描或间隙扫描”。
怎么确认是不是隐式表锁（即行锁退化）
隐式表锁本质是InnoDB因无法使用索引，被迫对每一行加锁，表现就是锁住大量无关记录。这不是配置问题，是SQL+索引不匹配的结果：
- 执行
EXPLAIN看目标UPDATE的执行计划：若type为ALL或index、key为NULL、rows远大于实际匹配行数，基本可断定退化 - 检查WHERE条件是否存在隐式类型转换：比如字段是
BIGINT，但传入字符串'123'，MySQL会放弃索引 - 确认字段字符集是否一致：如表用
utf8mb4而参数用latin1，也会导致索引失效 - 不要只看
SHOW PROCESSLIST——它只显示线程状态，看不出是否在等行锁；要立刻查INFORMATION_SCHEMA.INNODB_TRX中trx_state = 'LOCK WAIT'的事务
怎么验证Gap锁是否引发锁等待链
Gap锁本身不阻塞读，但在RR隔离级别下，它会让并发INSERT/UPDATE落在同一间隙时互相等待。典型信号是：报错前刚执行过范围查询（如WHERE id > 100）或非唯一索引等值查询（如WHERE name = 'Alice'）：
- 查
performance_schema.data_locks（MySQL 8.0+）：过滤LOCK_TYPE = 'RECORD'且LOCK_MODE含GAP或NEXT-KEY，再看LOCK_DATA是否出现大跨度（如(100, 200)） - 对比两个冲突事务的
SHOW ENGINE INNODB STATUS\G输出：若都显示lock_mode X locks gap before rec，且lock_trx_id指向不同事务，说明是Gap锁交叉 - 临时改隔离级别验证：把事务改成
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED再重试，如果不再超时，基本锁定是Gap锁问题
UPDATE语句加锁时机与索引路径强相关
InnoDB不是一执行UPDATE就锁全表，而是在引擎层遍历满足WHERE条件的每一条记录时逐个加锁。锁的粒度完全由执行路径决定：
- 主键等值更新（
WHERE id = 123）→ 只加RECORD LOCK，精确到一行 - 非唯一索引等值更新（
WHERE status = 'pending'）→ 加NEXT-KEY LOCK，锁住匹配行 + 前一个间隙 - 无索引字段更新（
WHERE phone = '138...'且phone没索引）→ 全表扫描，对聚簇索引每条记录都加RECORD LOCK，等效于表级阻塞 - UPDATE带子查询或JOIN时，先执行驱动表访问路径，再对被驱动表加锁；若驱动表没走索引，被驱动表可能被反复扫描加锁
真正容易被忽略的是：即使你给WHERE字段建了索引，如果SQL里用了函数（如WHERE DATE(created_at) = '2026-09-30'）、OR条件混入非索引列、或联合索引未满足最左前缀，InnoDB照样退化。诊断必须从EXPLAIN开始，而不是直接调大innodb_lock_wait_timeout——设成300秒只会让用户多等5分钟才失败。
