先说原因： 手动开启事务，由于处理业务时间过长，既不提交也未报错回滚，长时间占用事务就会出现这种情况，错误
关键字：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？记录一次事务异常导致的下单阻塞
来源地址：https://blog.csdn.net/daiwqaq/article/details/127958645
