背景
银行网贷系统存在这么一个定时任务：
1、针对前一天放款的借据生成应收入账明细入库，例如一笔借据是12个月360天的，那么这笔借据就需要插入360数据库记录。假如当天放款1E，平均每单借款金额3000，那么就会生成3W+笔订单，每笔订单分为12期，等于就需要插入3W+*360=1000+W的数据
2、导出前一天的应收入账明细记录报表，比如前一天放款30000笔，那么输出报表的条数就为30000+以往订单的应收入账明细，每天增加及减少一些条数，数量也大概在十万级别
3、导出前一天的应收入账明细汇总报表，包含两部分数据数据：正常还款的应收入账明细汇总 + 当期提前还款的应收入账明细汇总，这部分数据可以利用第二步查出来的数据按STREM进行汇总。另外是查询逾期明细信息的汇总，这步只能单独查询。
分析耗时
数据插入耗时
首先应收入账明细表的原有数据已经达到2E，并且每天根据放款量还在增长。由于是帮银行方做的系统且基于稳定性考虑，并没有做分表，只是使用了MYSQL分区表以及固态硬盘做了优化，另外对一个月前的报表记录做归档，但表的数据量仍然是E级别。
原代码是每计算出30天应收入账明细记录后利用SQL拼接的方式立即插入30条记录。这是一个优化点。完全可以增加单次插入条数并改成批量方式插入。或者考虑多线程
查询耗时
查询由于业务以及技术限制，基本没有优化空间，明细条数每天最多也就10+W条，但也可以改成通过嵌套查询主键减少回表的方式来优化查询数据。还可以考虑利用多线程CountDownLatch优化
写文件耗时
将IO流改成NIO块，提升写入速度
优化原理
1、插入优化
参考我这篇文章就是当时在优化时候做的笔记
批处理 rewriteBatchedStatements=true
改用JDBC原生或者MYBATIS批处理的方式（实际上使用FOREACH拼接SQL也可，与批处理相比并没有太大差距），内存允许的情况可以3K或者5K条数据批量插入一次，大大缩短插入时间
2、分页查询优化
原理跟这篇文章类似，先查出ID，在使用IN，减少回表次数
一次SQL查询优化原理分析（900W+数据，从17s到300ms）
3、IO转NIO
优化效果
当放款量大的时候基本上可以从几个小时缩短到分钟级别。当没有插入的时候，查询时间也较之前有所缩短。
