定位问题
刚开始得到是系统慢的反馈，没有将问题点定位到数据库上，查了半天服务是否正常（因为之前有一次Dubbo内存泄漏）。
在将应用服务日志查看了一遍后，没有发现任何异常，只是打了几个警告的日志。
于是又查看了业务运行时的日志，看到日志都提示了一个 Lock wait timeout exceeded; try restarting transaction 的异常。
这时还是没有将重心放到数据库上，认为是代码的原因，导致事务一直没有提交。
重新将代码审阅了一遍，觉得应该不是代码逻辑的问题，而这个时候， Lock wait timeout exceeded; try restarting transaction 这个异常的日志越来越多。
认为是数据库层面出了问题，开始排查数据库。
寻找原因
由于我们的数据库不是用的 云RDS版本，是在一台8核32G的AWS上的安装版本。
使用 top 命令，查看到 Mysql 占用的 CPU 使用率高达 90% 左右。
心里一慌，感觉不妙，这样子高负载的CPU使用率，搞不好服务器都要宕掉。
于是拿出了仅有的一点Mysql基本知识，基本上这次只使用到了下面几个语句：
- 查看当前Mysql所有的进程
show processlist;
- 查看Mysql的最大缓存
show global variables like "global max_allowed_packet"
- 查看当前正在进行的事务
select * from information_schema.INNODB_TRX
- 查看当前Mysql的连接数
show status like 'thread%'
解决
按照上面的几个语句，一步一步跟踪定位下来。
show processlist;下来，我们就可以查看出当前所有的进程，并且得到最耗时的进程。
在当前数据库中，看到处于 Sleep 状态的SQL非常多，而这也是占用CPU过高的重大原因，休眠线程太多，于是配置了一个 wait_time_out 为 600 秒的一个解决方案。
为什么配置600秒，因为我们应用超时时间配置的最大时间就是 600秒，10分钟，这里的配置需要根据业务来具体配置。
select * from information_schema.INNODB_TRX
执行这个语句，看到Mysql中大部分处于 Lock 的SQL是一条 update 的SQL，而且还有一个单条件的SQL，查询居然耗时4分钟，很是惊讶。
于是查看了这张表。
刚一打开结构，差点没忍住口吐芬芳，居然一个索引都没有，数据量超过300W，没有索引查询基本上都要4分钟往上走。
于是准备加上索引，在一阵漫长的等待中，索引终于加上去了。
show status like 'thread%'
索引加上去了之后，查看了一下当前Mysql的连接数，似乎没有之前那么高了，估计是挤压的太多。
然后又查看了下服务器的CPU占用率，这次好了一点，从1%到80%来回跳动，没有出现90&那么高的频率。
总结
Mysql作为使用频率非常高的数据库，对于它的SQL调优真的是一门技术活，而且项目中的一些SQL看的也是想吐，这种调优起来真的难上加难。
其实 information_schema 这个数据库，里面的Mysql日志看起来比业务日志顺眼的很多。