Mycat占用mysql连接数过多

背景：mariadb，mycat中间件。
问题：DB连接数过多；开发使用程序使用连接池连mycat；
DB待优化项： interactive_timeout，wait_timeout 都是8小时默认值。
mycat配置：100个分片库，和其他业务库。现在分片库用到16分片，后面尚未使用。
当前DB最大连接数：3000
mycat 版本：当前线上的mycat版本是1.5.8版本，推荐以后线上使用最稳定的 mycat1.6.5版本。

经DB和开发碰面了解这两个timeout时间不能缩短，所以常规的优化手段不能使用：
正常DB连接数1000，数据库两个timeout为300--500，参数可以全局动态生效。

公司线上DB前段时间建总出现连接数过多问题，正常来说连接数1000,已经能够满足大部分需求。
正常手段无法使用的时候，那么就要找到DB为啥连接数过多。

1. 审计日志
DB上部署过审计日志，审计日志部署请移步：审计日志部署，审计日志中可以查看到做坏事的坏小子是谁！
因为时间关系，未保存。但是从审计日志中发现大量访问连接sql就是'select 1' ，也是mycat连接mysql的连接。
且该链接连的是大量尚未使用的物理库。
至此审计日志只能判断到这里。
2. DB层面
mariadb物理库 information_schema 中processlist表记录连接相关信息，比如 DB,HOST,INFO,STATUS等。而且能统计具体某个库的连接数。
查询后，发现很多没有使用的DB中连接很多没有释放，大概占总连接数的60%左右，使用脚本 "kill id； "后连接仍旧重新连接。
这种情况很尴尬，找不到原因。
3. 审计日志
再结合审计日志，查看连接从哪来的，还是mycat 发过来的<heartbeat>select 1 </heartbeat>，暂时就可以定位mycat的heartbeat 问题，结合网上查找的heartbeat算法，
其中有一条是关于未用的DB连接算法：如果当前DB一直有访问，那么链接该DB 的heartbeat暂不执行，未用的DB链接300秒重新连接该DB。

这算法是个人的理解，因能力有限，代码阅读能力低，只能理解个大概；现也能判断个大概方向。
4.更改mycat配置