UPDATE卡住不报错主因是锁等待：先查INNODB_TRX中TRX_STATE='LOCK WAIT'的事务，再通过INNODB_LOCK_WAITS定位BLOCKING_TRX_ID，确认阻塞源是否为长事务未提交、隐式锁未暴露或WHERE未走索引导致全表加锁。
执行 UPDATE 语句卡住、无响应、不报错，或直接报 ERROR 1205 (HY000): Lock wait timeout exceeded，基本不是网络或连接池超时（wait_timeout），而是被锁住了——真正卡在锁等待链里，背后大概率是长事务没提交，或隐式锁未暴露。
查 INNODB_TRX 看谁在等、谁在挡
先确认是不是真被锁住：运行 SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT';。如果返回结果，说明当前有事务正在等锁；再用它的 TRX_WAITING_TRX_ID 去关联 INNODB_LOCK_WAITS 表，就能拿到 BLOCKING_TRX_ID ——那个“挡路”的事务 ID 就在这里。
接着查这个阻塞事务：SELECT TRX_ID, TRX_STARTED, TRX_STATE, TRX_QUERY, TRX_MYSQL_THREAD_ID FROM information_schema.INNODB_TRX WHERE TRX_ID = 'xxx';
- 若
TRX_STATE是RUNNING且TRX_STARTED很早（比如几分钟前），极可能是应用忘了COMMIT或ROLLBACK - 若
TRX_QUERY是个慢UPDATE或INSERT，再看它有没有走索引（用EXPLAIN SELECT ...模拟条件） - 若查不到该
TRX_ID对应的记录，说明它可能已退出但锁没释放干净——常见于隐式锁场景，尤其是未提交的INSERT后发生唯一键冲突又回滚不彻底
WHERE 条件没走索引 → 全表扫描 + 行行加锁
UPDATE 语句一旦 WHERE 不命中索引，InnoDB 就会全表扫描，对每行都加记录锁，还可能带上间隙锁。结果不是“锁一行”，而是“锁一片”，别人插数据、改相邻行全得排队。
实操验证方法：EXPLAIN SELECT * FROM your_table WHERE your_condition;（MySQL 不支持直接 EXPLAIN UPDATE）
- 重点看
key字段是否为NULL，rows_examined是否远大于预期行数 - 避免在
WHERE中对字段做函数操作，比如WHERE DATE(created_at) = '2024-01-01'→ 改成WHERE created_at >= '2024-01-01' AND created_at - 联合索引注意最左匹配：有
(status, updated_at)索引，但写WHERE updated_at > 'xxx'就用不上
隐式锁让监控“看不见”锁，但实际已阻塞
隐式锁是 InnoDB 的优化机制：事务插入或修改某行时，不立即加锁，等另一个事务来读/改同一行时才现场转换为显式锁。这会导致 INNODB_TRX 里查不到等待事务，SHOW PROCESSLIST 却显示 updating 状态，看起来像“卡死”，实则是锁还没真正生成。
典型诱因是高并发下 INSERT 和 UPDATE 混用，尤其插入唯一键冲突后回滚残留。
- 强制提前暴露锁行为：在
UPDATE前加同一事务内的SELECT ... FOR UPDATE，把隐式锁转为显式锁，便于定位 - 检查是否有未提交的
INSERT：特别是批量导入中途失败、只部分回滚的情况 - 避免大事务内混用 DML：不要在一个事务里先
INSERT一堆数据，再UPDATE同一张表——拆成独立小事务更可控
真正难排查的从来不是“锁了哪一行”，而是“为什么锁迟迟不释放”——长事务、隐式锁、MDL 锁、甚至备份工具（如 mydumper）或 DDL 操作（ALTER TABLE）都可能成为隐形堵点。别只盯着 innodb_lock_wait_timeout 调大，先搞清锁源在哪，比调参重要得多。
