我有一条sql在数据库执行，很长时间，刚好的delete操作，然后这边项目中刚好执行一条批量新增的sql，两者超时冲突了。
所以说这两者就涉及到事务锁的问题的了，接口响应时间超长，耗时几十秒才返回错误提示，后台日志中出现Lock wait timeout exceeded; try restarting transaction的错误，出现了高并发现象。
那么我们来说说如何解决方案：
当务之急，也是要看看数据库中有没有比较长时间执行的sql：
show processlist;
当前所运行的所有事务
SELECT * FROM information_schema.INNODB_TRX;
当前所有的锁
SELECT * FROM information_schema.INNODB_LOCKs;
锁等待的对应的关系
SELECT * FROM information_schema.INNODB_LOCK_waits;
那么我们看到事务表中INNODB_TRX，里面是否有正在锁定的事务线程，看看ID是否在show processlist里面的sleep线程中，如果有，那么就证明了这个休眠的线程事务一直没有commit（提交）或者roolback（回滚）而是卡住了，所以，我们需要人为介入，kill掉。
如果发现了好多事务任务，那最好都kill掉。
命令为
select concat('KILL ',id,';') from information_schema.processlist where user='cms_bokong';
通过information_schema.processlist表中的连接信息生成需要处理掉的Mysql连接的语句临时文件，然后执行文件中生成的指令。然后我们获取到了对应任务的id，一个一个 kill id就行了。
然后我们再去找还在进行事务的任务，就会发现空掉了。
应急处理完成后，我们就需要核对原因，防止以后再出现：
1.mysql的引擎检查，可以检查一下数据库引擎是不是InnoDB（mysql5.5.5以前默认是MyISAM,Mysql5.5.5以后默认是InnoDB），show engines；#检查命令
如果不是INNDB，那么就改为InnDB；
命令为：
查看表使用的存储引擎
show table status from db_name where name='table_name';
修改表的存储引擎
alter table table_name engine=innodb;
