現狀資料說明：
需求背景介紹：
1. 該文件功能是以 .csv 後綴的文件進行解析後，反查我方數據庫表，取出賬單後做具體的處理業務
2. 該文件功能主要分爲以下幾個環節
- 獲取URL並下載文件
- 文件解析並檢查文件數據的有效性及數據去重
- 取出文件中的具體業務字段進行查詢我方的庫表
- 根據查詢出來的賬單做具體的業務處理
3. 處理百萬量級以上數據時，整體效率偏低，理想情況的是處理百萬量級的數據控制在一個小時左右
注：該文件處理功能是在單線程的情況下執行，暫時不需要考慮太消耗性能來開多線程的處理方案
流程耗時分析：
文件去重後以資產號查詢我方賬單集合，整體是從 7ms ~ 22ms 不等；理論上來說文件數據有多少條就會查詢多少次庫表
結論：通過覈實代碼邏輯，該功能文件的執行文件耗時，均爲在查詢DB這塊佔用耗時較多
如：對到170W+的數據量，需要耗時2個半小時左右執行完。現文件執行流程耗時也算相應合理。也存在要提高文件處理性能的必要性
問題點：
現SQL的查詢邏輯等同於
select * from postloan_#xx#_db.t_asset_bill_#y# where Fstatus=1 and Fasset_id=xxxx
1. 這裏是返回的整個賬單集合；如 asset_id 對應的數據有12條賬單數據，則返回了12條記錄的一個list對象
2. 重新評估業務後，這樣的SQL查詢是可以進一步優化
3. 全量字段查詢是沒有必要的，影響磁盤IO的處理效率
注：該庫表爲百庫十庫，庫表字段數量超過一百個字段
設計方案：
優化思路：
1. 從查詢整個賬單集合返回 --> 查詢最大期賬單返回
2. 全字段賬單數據返回 --> 精簡需要字段的返回
業務邏輯優化：
1. 獲取文件中資產號，通過資產號入參。返回提前結清的賬單的最大期數賬單對象
2. 提供該 getSimpleLastTermBillByAssetId 查詢方法，mapper 文件的查詢SQL同步調整字段精簡返回
-- 根據資產號查詢提前結清最大期數的賬單（字段精簡版本）
select
Fid,Floan_channel_id,Fasset_id,Fbill_id,Fcus_order_id,Finsure_mode_no,Frepay_term,Freal_repay_data,Freal_repay_type
from
postloan_#xx#_db.t_asset_bill_#y#
where
Fstatus=1 and Fasset_id=xxxx and Floan_term＝Frepay_term and freal_repay_type = 30 and Fpostloan_repay_source_type in (0,20)3. 獲取到我方提前結清的賬單對象後（已做字段精簡），對符合退保的賬單進行組裝MQ發出 （現有的處理邏輯中退保校驗條件減少）
注：這裏是將代碼邏輯中的一部分校驗條件前置到SQL查詢中實現，減少業務代碼邏輯
效率提升效果：
扣款回盤文件退保性能提升需求（線上觀察）
a.整體文件處理性能提升 100~110%
b.賬單查詢優化後由 7~22ms 下降到 2~6ms
優化總結：
1. 通常情況下程序中文件處理效率低，都是在解析文件的過程中有查詢DB的情況；若只是解析文件做業務處理話，百萬量級的數據也就只是幾秒鐘程序就能跑完
2. 數據庫表查詢，若非必要，應當根據業務使用場景；第一優先選擇爲需要字段SQL查詢來提高查詢效率，減少磁盤IO與內存的消耗
參考資料：
MySQL：查詢字段數量多少對查詢效率的影響 http://blog.itpub.net/7728585/viewspace-2668552/