最近一次项目上线，这个过程中发现许多问题，记录下：
问题1.在授信流程中，执行特别慢，原因涉及额度SQL的计算，犹豫需要查询授信申请表、还款计划明细表、赔款追偿交易明细表的，申请金额、还款金额、追偿金额，追偿金额又涉及放款信息表的计算。并且额度又分总额度、月额度、周额度的计算，每个表中的数据量都是千万级，SQL执行效率低下，整个流程特别慢。
解决1.对还款金额、以及追偿金额的计算逻辑进行优化，由原先在授信过程中，每发起一次授信请求，就计算一次额度信息，改为通过定时任务，改为每天计算一次还款金额、追偿金额、在每次授信请求进来时，直接从数据库所建表中进行取值即可。
【注】之所以还款金额、以及追偿金额能够通过日终定时任务进行计算，是因为还款金额、追偿金额是由每天日终文件同步所引起变化，也就是说这个额度并不是实时变化的，在日终文件同步之后进行计算一次即可。而申请金额是实时变化的，这个则是每次在授信通过时，对额度实时进行相应的减少，这样总的申请额度是能够直接从渠道额度表中进行获取。
而月度申请额度、以及周申请额度还是需要每次从授信表中进行查询，而授信表数量级巨大，在查询时会很慢，由于这个是根据时间进行判断，所以我们在授信表中的创建时间字段上添加了索引，提高了查询效率。
问题2.在压测时发现，二期系统需要调用一期系统的一个接口，在数据量大的时候，会提示连接超时。
解决1：1期系统是内部系统，实时接口比较少，且不存在并发性能要求，但是这个新加的接口，有并发要求，当数据量大时，二期系统会一直等待1期的请求返回，但是1期没有那么多的数据库连接数，就会造成一直等待直至连接超时，通过排查1期系统只有20个连接数，通过改变1期系统连接数大小，这一个问题也得以解决。
活用SQL中的语法、函数等。
月份计算SQL1：
SELECT SUM(sumInsured) FROM cicpx_entry_apply_info WHERE ?2 <= createdTime and createdTime < ?3 " +
"AND applicationStatus IN ('03','05','06','07','08','09') AND teamworkChannel=?1
月份的计算SQL2：
SELECT SUM(sumInsured) FROM cicpx_entry_apply_info WHERE DATE_FORMAT(createdTime,'%Y-%m')=DATE_FORMAT(NOW(),'%Y-%m')\n" +
"AND applicationStatus IN ('03','05','06','07','08','09') AND teamworkChannel=?1
周计算SQL1：
SELECT SUM(sumInsured) FROM cicpx_entry_apply_info WHERE ?2 <= createdTime and createdTime < ?3 " +
"AND applicationStatus IN ('03','05','06','07','08','09') AND teamworkChannel=?1
周计算SQL2：
SELECT SUM(sumInsured) FROM cicpx_entry_apply_info WHERE YEARWEEK(createdTime)= YEARWEEK(NOW()) " +
"AND applicationStatus IN ('03','05','06','07','08','09') AND teamworkChannel=?1
注：使用sql自带的函数进行查询计算时，可能会造成索引的失效，在数据量大时，查询就会特别慢，需要注意。
数据库字段的一些问题
背景：授信表中有个订单状态字段status，代表着订单状态，在马马合作方时使用这个字段。后来又接了一个新的渠道方叫道道合作方，当时开发设计时，不知道为什么又创建了一个新的字段orderStatus，这个字段的业务含义是道道订单状态，如果只是单纯的考虑授信、投保的一套流程，这样建并没有什么问题。
但是系统不仅仅是有正常流程下的业务逻辑，在给决策引擎送在保、在途额度时，就需要统计在保保单使用的额度，以及在途的订单使用的额度，这时候计算就需要订单的状态进行判断，而授信流程中，马马和道道是采用的一套代码，授信的开发人员，在生成道道订单时，会给道道的马马订单状态同样赋值，而后续道道的业务逻辑又同样用到了这个马马订单状态，此时道道的业务就存在了两个订单状态。
在计算马马的额度时，还要考虑到将道道的业务排除在外。
又有交易保、和非交易保的区别。
后续再数据核验时，同样根据需要用这个马马订单状态进行判断，而新增道道订单状态后，又需要考虑到这个状态。
因为后续的开发都是已经完成，正在生产运行，因此在授信新增道道业务时，由于新增了道道订单状态，后续需要考虑很多涉及到订单状态的情况，难免会产生对马马业务有影响的bug，在测试过程中未必能将马马的业务又重新全面的测试一遍。
像这个情况，应该在需求设计、开发设计时，就应该将这两个业务公用一个订单状态字段。通过业务类型对业务进行区分，而不是通过不同的订单状态字段。