一、问题现象
接口响应时间超长，耗时几十秒才返回错误提示，后台日志中出现Lock wait timeout exceeded; try restarting transaction的错误。
二、问题场景
- 在同一事务内先后对同一条数据进行插入和更新操作；
- 多台服务器操作同一数据库；
- 瞬时出现高并发现象；
三、问题原因
- 在高并发的情况下，Spring事务造成数据库死锁，后续操作超时抛出异常。
- MySQL数据库采用InnoDB模式，默认参数innodb_lock_wait_timeout设置锁等待的时间是50s，一旦数据库锁超过这个时间就会报错。
四、解决方法
- 查看数据库当前的进程，看一下有无正在执行的慢SQL记录线程。
mysql> show processlist;
- 查看当前的事务
当前运行的所有事务：
mysql> SELECT * FROM information_schema.INNODB_TRX;
当前出现的锁：
mysql> SELECT * FROM information_schema.INNODB_LOCKs;
锁等待的对应关系：
mysql> SELECT * FROM information_schema.INNODB_LOCK_waits;
解释：看事务表INNODB_TRX，里面是否有正在锁定的事务线程，看看ID是否在show processlist里面的sleep线程中，如果是，就证明这个sleep的线程事务一直没有commit或者rollback而是卡住了，我们需要手动kill掉。
搜索的结果是在事务表发现了很多任务，这时候最好都kill掉。
- 批量删除事务表中的事务
这里用的方法是：通过information_schema.processlist表中的连接信息生成需要处理掉的MySQL连接的语句临时文件，然后执行临时文件中生成的指令。
mysql> select concat('KILL ',id,';') from information_schema.processlist where user='cms_bokong';
+------------------------+
| concat('KILL ',id,';') |
+------------------------+
| KILL 10508; |
| KILL 10521; |
| KILL 10297; |
+------------------------+
18 rows in set (0.00 sec)
当然结果不可能只有3个，这里我只是举例子。参考链接上是建议导出到一个文本，然后执行文本。而我是直接copy到记事本处理掉 ‘|’，粘贴到命令行执行了。都可以。
kill掉以后再执行SELECT * FROM information_schema.INNODB_TRX; 就是空了。
这时候系统就正常了
五、故障排查
- mysql都是autocommit配置mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
| 0 |
+--------------+
1 row in set (0.00 sec)
如果是0 ，则改为1
mysql> set global autocommit=1;
- mysql的引擎检查，可以检查一下数据库引擎是不是InnoDB（mysql5.5.5以前默认是MyISAM，mysql5.5.5以后默认是InnoDB）
show ENGINES;
查看表使用的存储引擎：show table status from dbName where name='tableName';
修改表的存储引擎：alter table tableName engine=innodb;
