mysql数据库事务锁超时排查指南_定位根源与解决步骤-mysql教程-PHP中文网

事务锁超时错误表现为“lock wait timeout exceeded; try restarting transaction”，是因事务等待行/页锁超时（默认50秒），而非连接或语法错误；需查innodb_trx与innodb_lock_waits定位阻塞事务，kill blocking_thread而非报错线程，并从应用事务控制、索引优化、配置调优三方面预防。

mysql数据库事务锁超时排查指南_定位根源与解决步骤

事务锁超时错误长什么样？先认准 `Lock wait timeout exceeded`

遇到 Lock wait timeout exceeded; try restarting transaction，基本可以断定是事务在等锁时超时了，不是连接超时、也不是 SQL 语法错。MySQL 默认的锁等待上限是 innodb_lock_wait_timeout=50 秒（注意：这个值不等于 wait_timeout 或 interactive_timeout）。它只控制「一个事务等待另一行/页锁的时间」，超时后当前语句直接报错回滚，但持有锁的那个事务还活着。

常见诱因包括：
– 长事务没提交，一直占着锁
– 应用层异常退出，没显式 COMMIT 或 ROLLBACK
– 手动执行了未提交的 UPDATE 或 DELETE（比如在客户端工具里改了几行就走开了）
– 并发写同一行，且其中一方卡在慢查询、网络延迟或应用逻辑里

怎么立刻查到谁在锁、谁在等？用 `INFORMATION_SCHEMA.INNODB_TRX` 和 `INNODB_LOCK_WAITS`

别急着 kill，先看清楚现场。这两张表是 InnoDB 实时状态快照，比 SHOW PROCESSLIST 更精准（后者看不到锁等待关系）。

常用组合查询：

SELECT 
  t1.TRX_ID waiting_trx_id,
  t1.TRX_MYSQL_THREAD_ID waiting_thread,
  t1.TRX_QUERY waiting_query,
  t2.TRX_ID blocking_trx_id,
  t2.TRX_MYSQL_THREAD_ID blocking_thread,
  t2.TRX_QUERY blocking_query
FROM INFORMATION_SCHEMA.INNODB_TRX t1
INNER JOIN INFORMATION_SCHEMA.INNODB_LOCK_WAITS w ON t1.TRX_ID = w.BLOCKING_TRX_ID
INNER JOIN INFORMATION_SCHEMA.INNODB_TRX t2 ON w.BLOCKING_TRX_ID = t2.TRX_ID;

关键点：
– t1 是正在等锁的事务（报错方）
– t2 是持锁不放的事务（真凶）
– 如果查不到结果，说明锁已释放，或是死锁被自动检测并回滚了（此时日志里会有 Deadlock found）
– 注意 TRX_STARTED 时间，如果某个事务运行了几十分钟，基本就是它的问题

`KILL` 谁？为什么不能只 `KILL` 报错的线程？

报错的线程只是“等锁失败”，真正要 KILL 的是 blocking_thread（即上面查出的 t2.TRX_MYSQL_THREAD_ID）。否则你杀掉等锁的，锁还在，下一个请求照样卡住。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

操作前确认：
– 检查 t2.TRX_STATE 是否为 RUNNING（不是 LOCK WAIT）
– 查 t2.TRX_QUERY 是否合理，避免误杀正在执行重要业务的事务
– 如果 t2.TRX_QUERY 是 NULL，说明它当前没在执行语句，但事务仍开启（很可能是应用没 commit）
– 使用 KILL [thread_id]，不是 KILL QUERY [thread_id]（后者只中断当前语句，事务仍活跃）

怎么避免下次再踩坑？从代码和配置两头压

锁超时本质是资源争用 + 时间失控，得从源头控时长、缩范围、早释放。

应用侧必须做到：
– 所有数据库操作包在 try...catch 里，无论成功失败都确保 COMMIT 或 ROLLBACK
– 写操作尽量用主键或唯一索引更新，避免全表扫描加锁（UPDATE ... WHERE non_indexed_col = ? 会锁整张表）
– 高并发场景下，考虑用乐观锁（如 version 字段）替代长事务悲观锁
– 日志里打上 TRX_ID 或线程 ID，方便出问题时快速关联

数据库侧可调：
– 临时调低 innodb_lock_wait_timeout（比如设为 5），让问题更快暴露，而不是拖几十秒才报错
– 开启 innodb_print_all_deadlocks=ON，把死锁详情写进 error log（默认只记第一条）
– 监控 Innodb_row_lock_time_avg 等状态变量，持续偏高说明锁竞争已成常态

最常被忽略的是：事务里混了远程调用、文件读写、sleep 等非数据库操作。这些时间全算在锁持有时间内——哪怕只等 3 秒 HTTP 响应，也可能让下游所有写同一行的请求排队超时。