最近收到客户反映系统卡顿严重，然后让他截图看了下，最长响应时长居然高达16s,其他3s,4s的接口一大堆，简直是恐怖！
简单来说，这个耗时16s的接口其实是统计一张历史数据表里的数据，这张表大概有三百多万条数据，日增长1万左右，因为客户要求最多留存2年，所以也不必考虑分表了。
看了下查询逻辑，其实也比较简单，就是根据两个字段去数据库里筛选，但是查询出来的数据量比较大，所以不管怎么优化都效果不好；然后我注意到该表使用innoDb存储引擎，考虑到历史数据表查多写少，是不是用Myisam存储更好？想到就做，先导出表结构和数据，直接在sql里修改表引擎，再重新刷一遍。最后在页面上刷新接口，居然只需要1s多就返回了！犀利！
然后其他接口慢大概就是一些比较低级的问题了：
1. 大表查询不加索引
2. 多表关联查询甚至3张，4张表一起join(我只想说这种人真是懒到家了)
3. 一个接口封装了好几个方法，有些方法已经查询过的数据，其他方法又查了一遍
4. 返回树结构数据时直接在mybatis的xml里递归查询(懒!)
5. 一些字段包含大量content文本，一股脑用select * 捞出来
6. 在java循环里查询数据库(懒)
7. 时间范围查询不走索引，可以使用时间戳代替
8. 用大表去驱动小表查询效率低（有个最简单的写法，不要用join on，直接逗号去隔开就行了，让mysql去自行判断）
