记一次 MySQL出现“Lock wait timeout”错误的原因

蝉动

已于 2023-01-30 17:50:10 修改

阅读量6.9k

点赞数 3

文章标签： mysql 数据库 java

于 2022-11-21 12:26:14 首次发布

本文链接：https://blog.csdn.net/daiwqaq/article/details/127958645

版权

先说原因：手动开启事务，由于处理业务时间过长，既不提交也未报错回滚，长时间占用事务就会出现这种情况，错误
关键字：trx_state为 running

故障场景：在测试环境中，在修改订单中偶现Lock wait timeout，且一直重复出现
初步定位：采用下列命令排查
select * from INFORMATION_SCHEMA.innodb_locks;
SELECT * FROM sys.innodb_lock_waits;
SELECT * FROM INFORMATION_SCHEMA.innodb_trx;
SELECT * FROM INFORMATION_SCHEMA.processlist;

innodb_locks中发现互斥锁，且等待语句仅仅为
update order set status = ‘1’ where id = ‘1593507966307274753’;
发生死锁的事务在这里插入图片描述
定位到锁住的事务 trx_id 340312222，发现事务running时间过长，且trx_query为null，这个是事务既没有提交也没有回滚的含义，那么就知道是事务340312222 一直占用order表，导致其他的DML操作无法继续进行下去，且超时等待
ps：没有选择直接延长lock wait time的时间，是因为没有数据库super权限
SELECT * FROM INFORMATION_SCHEMA.innodb_trx;

在这里插入图片描述
发现是订单表被锁了，且应该不是行锁，行锁只是锁住当前行，单条update主键语句，如果被锁，我的思路是应该是整表被锁了或者页锁，经过排查是表锁
进一步发现被等待的事务，是当天晚上19:40开始的，且一直未commit和rollback，长时间开启事务，除非连接断开或者被回收，才会关闭事务，排查事务原因，由于没有其他信息，故在系统业务日志中查看19:40左右的提交日志，定位到是手动开启的事务，

    transactionStatus = dataSourceTransactionManager.getTransaction(transactionDefinition);

	//todo 更新了订单数据
    //手动提交事务
    dataSourceTransactionManager.commit(transactionStatus);
} catch (Exception e) {
    dataSourceTransactionManager.rollback(transactionStatus);
    e.printStackTrace();
    return Result.error("推送材积信息失败，请联系管理员！");
}

且在逻辑中有查询和修改订单的逻辑，且有大批量处理数据，时间过长，导致既不提交也不会滚的情况，长时间的占用事务

参考文章：
MySQL出现“Lock wait timeout exceeded”错误的原因是什么?
mysql 事务一直running_事务一直running？记录一次事务异常导致的下单阻塞