database Troubleshooting

MySQL Lock wait timeout exceeded 排查

MySQL 报 Lock wait timeout exceeded; try restarting transaction 时，用 SHOW ENGINE INNODB STATUS 看 LATEST DETECTED DEADLOCK，通过 information_schema.innodb_trx 与 data_lock_waits 找 blocking 事务，短期 kill 会话，长期缩短事务并补索引避免大范围锁。

锁等待超时通常是另一个事务长时间持有锁。先找 blocking transaction，再决定 kill 会话、优化 SQL 或修复事务边界。

适用环境Linux / 数据库 / 连接池

风险等级中

最后验证2026-06-30

建议权限普通用户

2026-06-30 更新·约 3 分钟阅读

Scenario

这篇文章解决什么问题

适用于应用报 Lock wait timeout exceeded、写入或更新接口卡住、数据库连接逐渐堆积的场景。核心是找到阻塞事务，而不是只调大超时时间。

Symptoms

典型现象

应用 SQL 等待很久后失败。
SHOW PROCESSLIST 里有大量 updating、Locked 或长时间事务。
某些表更新集中超时，但读请求可能仍正常。

Before Debugging

排查前先确认

先区分连接、认证、锁、慢查询、连接池、内存或持久化问题。
记录数据库端时间、应用实例数、连接池大小和报错 SQL。
任何 kill/调参前先确认是否影响正在执行的业务事务。

Root Causes

常见根因分层

连接池与数据库容量失配

实例数乘以每个实例连接池上限，可能远超数据库 max_connections；连接泄漏和慢查询会进一步放大问题。

统计来源用户和主机
查看 Sleep 与活跃连接比例
核对应用连接池配置

事务、锁和慢查询堆积

锁等待、长事务、缺索引更新和慢 SQL 会拖住连接，最终表现成连接数耗尽或接口超时。

查 processlist / innodb_trx
看 deadlock 和 lock waits
定位 blocking session

缓存或内存策略失控

Redis 大 key、无 TTL、noeviction、MySQL buffer/临时表配置都可能让系统进入持续抖动。

先看内存水位和策略
找大 key/慢查询
评估数据模型是否合理

Diagnosis Path

分步诊断流程

1. 固定现场，避免追着变化状态跑

先记录故障时间、影响入口、完整错误和最近一次变更。MySQL Lock wait timeout exceeded 排查这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。

截图或保存完整错误文本
记录请求域名/IP/端口/namespace/服务名
标出最近发布、配置、证书、镜像或依赖变更

1. 固定现场，避免追着变化状态跑

mysql -e "SHOW ENGINE INNODB STATUS\G"
mysql -e "SELECT * FROM information_schema.innodb_trx\G"

2. 在故障发生的同一位置复现

很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。

从报错服务所在机器执行测试
必要时加 Host、SNI、namespace 或代理参数
把成功路径和失败路径的输出并排比较

2. 在故障发生的同一位置复现

mysql -e "SELECT * FROM information_schema.innodb_trx\G"
mysql -e "SHOW FULL PROCESSLIST"
mysql -e "SELECT * FROM performance_schema.data_lock_waits\G"

3. 读取服务端证据，而不是只看客户端提示

客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。

确认报错 SQL 和表名，记录发生时间。
查看 InnoDB status 中 LATEST DETECTED DEADLOCK 和 TRANSACTIONS。
找出长事务、等待事务和阻塞会话。

3. 读取服务端证据，而不是只看客户端提示

mysql -e "SHOW FULL PROCESSLIST"
mysql -e "SELECT * FROM performance_schema.data_lock_waits\G"
mysql -e "KILL <thread_id>"

4. 做最小修复并立即回归验证

每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。

找出长事务、等待事务和阻塞会话。
短期可 kill 明确异常且可重试的阻塞会话。
长期要缩短事务、补索引、避免大批量更新和交互式事务悬挂。

4. 做最小修复并立即回归验证

mysql -e "SELECT * FROM performance_schema.data_lock_waits\G"
mysql -e "KILL <thread_id>"

Commands