背景：
目前负责的系统在业务逐渐恢复以后出现在业务高峰的时候大量获取db连接失败，且SQL响应严重劣化。查看db性能报表显示，thread running队列高达500多，较平时增加增加100多倍，MySQL宿主机cpu达到70%，较平时增加50%左右，SQL执行量较平时增加10%左右。
排查过程：
查看MySQL的慢SQL日志，通过日志定位到主要的应用服务代码，然后查看接口的请求量报表，可以确定是接口请求量增高导致，但是通过数据库报表看SQL执行量并没有增加太多，所以可以推断SQL有性能问题。
解决方案：
1. 为了隔离对别人db的影响，给我们的db单集群部署，防止我们的请求量高导致别人的服务也出现问题。
2. 找出慢日志里比较多的SQL，对相应的表增加索引。
3. 为了解决峰值时大量创建连接导致获取连接失败，对数据库连接池的最小连接数进行设置，保证连接池有足够连接使用。因为底层依赖的是tomcat-jdbc连接池，所以设置minIdle和initialIdle。
遇到问题：
在设置连接池属性时只设置了minIdle和initialIdle，没有设置maxIdle，由于默认maxIdle小于initialIdle，导致设置的initialIdle没有生效，所以还需要同时设置maxIdle。
连接池属性设置了以后发现重启后数据库连接数上去了，但是马上又都销毁了，但是连接池内部还有都存在的，最后定位到是因为MySQL服务端有session timeout属性，公司封装的dal框架默认给设置了120s，所以过了这个时间就自动销毁了，后来设置了session timeout属性后，连接池就比较稳定了。
效果：
1. 高峰时没有连接报错问题
2. SQL响应时间平均提高200%
3. 数据库thread running长度保持在10左右
4. 数据库峰值cpu保持在20%左右