Lock wait timeout exceeded 是 MySQL 主动终止等待锁超时的事务，而非数据库崩溃；它表示事务等待行锁超过 innodb_lock_wait_timeout 时限（默认50秒）后被放弃，与死锁不同，属排队失败。
Lock wait timeout exceeded 是什么信号
这句报错不是数据库崩了，而是 MySQL 明确告诉你：“你这个事务等锁太久了，我放弃了”。背后真实含义是：某个事务正在死等另一事务释放行锁，但等的时间超过了 innodb_lock_wait_timeout 设置的阈值（默认 50 秒），于是主动断开并抛出错误 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction。
注意它和死锁（ERROR 1213）不同——死锁是 MySQL 自动检测并干掉一个事务；而锁等待超时是“纯排队失败”，没人帮你抢资源，只是排太久被踢了。
怎么快速定位谁在卡住你的 SQL
别急着改代码或调参数，先看现场谁在占着锁不放。最直接有效的方式是查 InnoDB 状态：
- 执行
SHOW ENGINE INNODB STATUS\G，重点看TRANSACTIONS和LOCK WAIT部分，它会告诉你当前哪个事务在等哪一行、被谁锁着、持有锁的事务做了什么 - 配合
SELECT * FROM information_schema.INNODB_TRX查活跃事务，关注trx_state（是否 RUNNING 或 LOCK WAIT）、trx_started（是否长事务）、trx_mysql_thread_id（对应线程 ID） - 再用
SELECT * FROM information_schema.INNODB_LOCK_WAITS关联锁等待关系，能精准定位阻塞链
常见陷阱：只看 SHOW PROCESSLIST 是不够的，它看不到未提交事务持有的隐式锁，也看不到间隙锁（Gap Lock）这类“看不见的锁”。
为什么 update/delete 比 insert 更容易锁超时
Insert 通常只争自增锁或主键唯一性校验锁，而 update/delete 的锁行为更复杂且易放大：
- 没走索引时，InnoDB 可能升级为全表扫描 + 行锁堆积，一条
UPDATE t SET a=1 WHERE b=123若b无索引，就会锁住成百上千行，极大提高冲突概率 - 范围条件如
WHERE created_at > '2025-01-01'会触发间隙锁（Gap Lock），不仅锁命中行，还锁住“空隙”，导致并发插入也被堵住 - ORM 自动生成的 SQL 常带冗余条件或顺序混乱（比如 MyBatis 动态 SQL 中
AND条件顺序不一致），让不同事务加锁顺序不统一，埋下死锁+锁等待双重隐患
实操建议：对所有高频 update/delete 的 where 字段，务必确认有对应索引；用 EXPLAIN 看执行计划，警惕 type: ALL 或 rows 过大。
调参 or 改代码？优先级很明确
把 innodb_lock_wait_timeout 从 50 改成 300 并不能解决问题，只是让失败来得更晚——它掩盖了根本矛盾。真正该做的顺序是：
- 检查是否有长事务未提交（
trx_started时间过早、trx_state = RUNNING却无动作） - 确认业务逻辑里是否存在「先 insert 再 update 同一条记录」这种自锁模式（尤其在 Spring @Transactional 方法内）
- 批量操作避免单条循环，改用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO减少锁持有时间 - 高并发写同一张配置表/计数表时，考虑拆成多行（如按 hash 分桶）或引入 Redis 缓冲层，别硬刚 InnoDB 行锁
最容易被忽略的一点：MySQL 8.0+ 的 performance_schema.data_locks 表能实时看到每一把锁的持有者和等待者，比老版本的 INNODB_STATUS 解析更直观——但默认关闭，需提前开启 performance_schema 并启用相关 consumers。
