MySQL 8.0.34升级后出现锁等待超时问题求助

问题背景 #

将MySQL从8.0.31升级到8.0.34后，执行部分UPDATE语句甚至新表的INSERT语句时，频繁触发lock wait timeout exceeded（错误码：1205）。

已执行的排查操作 #

已完成以下排查但未定位根因：

• 执行SHOW FULL PROCESSLIST排查进程状态
• 禁用了可疑的事件调度器和GTID表压缩任务
• 运行了以下锁相关排查语句：
  • 检查MySQL打开的表：

    SHOW OPEN TABLES WHERE In_use > 0;
    

  • 检查待处理的InnoDB事务：

    SELECT * FROM information_schema.innodb_trx ORDER BY trx_started;
    

  • 检查锁依赖关系：

    SELECT * FROM information_schema.innodb_locks;
    

当前InnoDB事务状态 #

Trx id counter 30988819
Purge done for trx's n:o < 30988811 undo n:o < 0 state: running but idle History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION
---TRANSACTION 283593565281880, not started 0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 283593565281104, not started 0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 283593565280328, not started 0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 283593565279552, not started 0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 283593565278000, not started 0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 283593565277224, not started 1 lock struct(s), heap size 1128, 1 row lock(s)

下一步排查方向 #

1. 聚焦异常锁持有的会话
   状态信息中，事务283593565277224标记为not started却持有1个行锁，属于异常状态。执行以下语句关联查询锁等待关系、锁定资源及对应会话：

   SELECT 
       r.trx_id AS waiting_trx_id,
       r.trx_mysql_thread_id AS waiting_thread,
       b.trx_id AS blocking_trx_id,
       b.trx_mysql_thread_id AS blocking_thread,
       b.trx_query AS blocking_query,
       l.lock_table,
       l.lock_index,
       l.lock_type,
       l.lock_mode
   FROM information_schema.innodb_lock_waits w
   JOIN information_schema.innodb_trx b ON w.blocking_trx_id = b.trx_id
   JOIN information_schema.innodb_trx r ON w.requesting_trx_id = r.trx_id
   JOIN information_schema.innodb_locks l ON w.blocking_lock_id = l.lock_id;
   

   再通过SHOW PROCESSLIST找到对应线程ID，查看线程历史执行语句及当前状态，确认是否存在未正常关闭的连接或遗留事务。

2. 核对版本升级后的锁机制变更
   重点查看MySQL 8.0.32-8.0.34官方文档中关于InnoDB锁、事务的更新内容：

   • 检查innodb_lock_wait_timeout参数是否被意外修改：SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
   • 确认新引入的锁优化参数（如innodb_deadlock_detect默认值）是否影响当前业务场景

3. 排查应用层事务逻辑
   检查应用代码中是否存在未显式提交/回滚的事务，或autocommit属性被意外关闭的情况。针对新表INSERT报错，需确认表的事务属性、索引创建过程是否存在锁冲突。

4. 验证表结构与索引有效性
   对报错的表，检查主键、索引是否正常。InnoDB在无主键时会生成隐式主键，可能导致锁范围扩大，引发超时。

内容的提问来源于stack exchange，提问作者Jeffrey