druid监控记录mysql_记一次服务器执行MySQL耗时问题

原标题：记一次服务器执行MySQL耗时问题

MySQL对我说“Too young, too naive!"

大概过程

在测试环境Docker容器中，在跨进程调用服务的时候，A应用通过Dubbo调用B应用的RPC接口，发现B应用接口超时错误，接着通过debug和日志，发现具体耗时的地方在于一句简单SQL执行，但是耗时超过1000ms。

通过查看数据库的进程列表，发现是有死锁锁表了，很多进程状态status处于'sending data'，最后为锁住的表添加索引，并且kill掉阻塞的请求，解除死锁，服务速度恢复正常。

下面记录的是大致排查过程：

通过观察业务代码，确认没有内存溢出或者其它事务问题，于是只能考虑Docker环境的数据库和jvm底层详情了。

使用Druid监控SQL执行状态

通过日志，发现有一句SQL严重超时，一句简单SQL，原本是批量插入多条记录，为了定位问题，测试时Mybatis只插入一条记录，但即便如此，还是耗时10秒

于是打算使用阿里巴巴的数据库连接池Druid进行监控，监控SQL效果如下：