记录一次mysql lock wait timeout exceeded; try restarting transactio异常

线上阿里云环境出现一个异常 lock wait timeout exceeded; try restarting transactio，而且这个异常导致项目短暂时间卡住了。

第一步、分析日志

通过日志分析，有其他定时任务work1在某个时间点大并发的访问某个接口interface1，操作了表B，然后后来的其他的任务work2要访问接口interfac2，而interface2也要更新表B。表现就是接口interfac2报了上面的异常。

第二步、Google问题

google这个问题，大致都得到这样的描述
information_schema这张数据表保存了MySQL服务器所有数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权限等。再简单点，这台MySQL服务器上，到底有哪些数据库、各个数据库有哪些表，每张表的字段类型是什么，各个数据库要什么权限才能访问，等等信息都保存在information_schema表里面。

我们可以用下面三张表来查原因：
innodb_trx ## 当前运行的所有事务
innodb_locks ## 当前出现的锁
innodb_lock_waits ## 锁等待的对应关系。
确实在 innodb_trx发现了wait的事物，而且mysql数据库默认的事务等待时间是50s

show variables like 'innodb_lock%';

在这里插入图片描述

第三步、解决方案

3.1临时解决

通过 innodb_trx查找到等待的事务，kill +事务ID即可。

3.2缓解

  1. 减少高并发，或者调用接口先进入队列，然后按照顺序出兑这样肯定能一定程度缓解这个问题。
  2. 将mysql的innodb_lock_wait_timeout时间加长

3.3代码层面

主要原因还是代码效率不高

  1. 分析发现接口interface1操作的更新表B没有利用到索引，导致在百万表中更新会特表慢。
  2. 其实改接口是单一的，有事务和没有事务都是一样的，没有说必须一起成功或者失败的东西，去掉事务是可行的。
  3. 如果接口效率高了，但是并发量太大，还出现这个问题，我认为这个时候就需要从设计层面考虑这个问题了，比如拆分表B等等。