发生背景
最近上线的一个项目几乎全是查询业务，并且都是大表的慢查询，sql优化是做了一轮又一轮，前几天用户反馈页面加载过慢还时不时的会timeout，但是我们把对应的sql都优化一遍过后，前台响应还是很慢，数据库测试sql运行时间在3s以内但响应的时候要么500要么就超时了，这时猜测可能是服务器出了问题，于是让运维监测了下GC情况，结果令人吃惊，近15小时发生了237次FGC,每次耗时近4000秒；于是我就让他把内存快照dump给我了
通过MAT分析内存快照
常用名词介绍
Leak Suspects
相当于一个总览，通过饼图的方式展示了可能造成内存溢出或泄露的对象使用的内存大小，并且会分析是哪个类加载器加载的哪个类占用了多少字节；如图：
Dominator Tree
列出了对象与其自身的引用关系，并且倒序列出了对象占用的内存大小以及百分比；通过这些能很清晰的定位到占用内存的对象
shallow heap
浅堆；对象没有引用其他对象时自身的大小
retained heap
深堆；对象自身的大小加其引用对象的大小，即对象被回收时垃圾回收器能回收到的内存大小
快照分析
通过Leak Suspects分析得出占用内存最大的是DruidDataSourceWrapper实例，这是连接池的类竟然不是业务代码，然后通过Dominator Tree 观察到底是哪个对象占用的内存较大，如图：
发现竟然是软引用占用了大量内存空间，此时瞄了一眼DruidDataSourceWrapper的源码就短短数行并没有什么可能造成溢出的因素，奈何又没看过mybatis和连接池的源码，只能结合这个软引用猜测，软引用一般被用在缓存的场景，而我们每次查询的结果集都是5w以上的数据量，直接放内存就算会OOM的话应该也不会用到缓存，于是猜测mybatis的xml里是否用到了fetchSize，全局搜索果然发现了有使用fetchSize，值竟然是一万，于是将fetchSize改为500发布后问题解决
记一次印象深刻的SQL优化
上面也提到了，这次问题排查对很多查询sql进行了优化，下面举个实例以作备忘；有一张六千多万的数据表T1，其共有45列数据，有a,b,c,d四个列涉及到查询，查询sql为：
select b,c,d,count(1) from T1 where a=123 group by b,c,d
优化时执行sql响应时间大概在20多秒左右，检查索引情况发现a、b、c、d均建立了普通索引，通过执行计划分析发现只命中了a的索引，于是考虑将b、c、d建立一个联合索引，但是查询速度依然不理想，于是考虑利用稀疏索引的原理来创建一个a、b、c、d的联合索引，结果发现查询结果直接0点几秒，全结果集扫描共4万多条记录也只用了五秒左右，优化完成
