本月总体来说都很忙，本来想抽空做点功课写点工作外的事情来着，实际也实在没找到时间，只是看了下之前保留的一篇博客，是关于java编程各方面资料的整理，
挑选了代码规范一节，看了一下eclipse整合checkstyle的介绍，也没有自己实际操作一下，了解了这种插件的基本使用方式。
本月主要在做的是公司里个人信贷系统性能调优的工作，如下：
1.背景：
随着线上个人消费贷数量的猛增，个贷系统日终跑批时间太长，已不能容忍，必须做优化。
2.解决方案及经验：
我们制定了优化方案，从各个方面进行优化，主要提其中目前对我感触较深的亮点：
1）以前一直以为sql性能调优是一项高级的工作，必须自己对程序有相当的了解，其实不然，在经理指导做了一个sql语句写法的改变后（update设置值时采用了中间sql查询结果集的方式，执行计划中是全表扫描，即使加上索引页不起作用，要改为先把中间sql的查询结果集放入中间表，再用中间表的来设置值，这样就不会走全表扫描了），我开始自己看sql的执行计划，哪个表是全表扫描很容易就可以看出来，通过在测试环境执行sql语句，我也发现了一个全表扫描方式的sql语句执行很慢，进一步分析，原来该表的索引是A B，但查询条件中使用了B作为条件，索引不起作用，于是添加索引B，速度提升了20倍，原先执行600s的sql，只执行不到30s就结束了。
所以，sql性能调优并不是多么复杂的事情，关键是不要被它吓倒，人人都可以写完sql去做自我分析，怎样会更好，你会发现，这是一项很有意思的工作。
2）在性能优化的方案中，有一项措施是迁移历史数据（已结清的贷款）到历史表中，减少数据表中的数据量，但由于迁移时执行的sql语句不准确（应该迁移2015年末前结清的贷款，但sql逻辑实际写成了2015年末前开户且目前结清的贷款），导致多迁移了一部分流水数据，导致的结果就是整个批量中的某些数据不准确了，因为会用到被迁移的数据。
当5月初从报表数据不准问题确认到这个原因时，我基本是很崩溃的，因为数据已经错着跑了好多天的批量，恰当的方式需要把迁移之前时点的数据恢复到测试环境，在测试环境重新跑批，并重新导入生产环境跑错的数据，我最怕的就是根本不知道怎样来恢复。
日终批量的任务很多，逻辑也很多，我几乎认为这是一项做不成的事情。
后来经过与开发人员的讨论，硬着头皮开始看日终应用的代码，整理迁移错误的数据影响到的批次和数据表，一个一个的看过来，发现日终程序没有想象中的那么负责，主要就是加工T-1日的数据或者月末的数据到某个表里，然后再从表里出数，复杂点的经过了好几次中间表的加工或者sql逻辑较长，而且也没有必要对sql逻辑看得太仔细，只要看它是不是按天保留数据及是否与迁移数据表的数据相关即可，这样，很快就整理出了测试环境跑批后需要往生产恢复数据的数据表范围及时间跨度。
感想是遇到难的事情，多跟别人交流讨论，另外就是没有那么复杂的事情，一个事情只要你认真参与，就会很熟悉，对于他人已经做好的较为大的应用，也不要畏惧，平时多看看，遇到问题，就不至于太崩溃，能够淡定有条理地去应对。
另外，针对业务部门提出的一个简单的统一利率的需求做一下开发。
本月的博客就到此为止了，后面仍要加强工作外的学习，平时可能有空的时候反而不知道应该学点什么了，毕竟时间很碎片化，我想，可以一方面多跟身边的一些牛人交流学习他们做的一些东西，还有看一些设计模式并自己动手实践编程之类的，都可以很好地去把时间利用起来，这是目前的想法，后续如果有了更好的方法，会及时地更新出来，如果各位读者也有好的建议或意见，也请不吝赐教。