初級想法
剛拿到任務時，以為就是拿文件的數據與數據庫中的數據比較。沒什么大不了的，可是數據量過大，不管是后台還是數據庫都承受不了，文件導入時文件不可過大，本想在前台進行切割文件然后逐一進行上傳，可是前台也受不了，最后只能人為進行對文件切割每個文件不管是大小和數據量都有限制，不然后台占用訪問長，后台自動斷掉，數據不完整。自己就在讀文件時直接在后台寫入redis緩存中，雖然時間有些長，但是至少數據保存住了，可以進行查詢比較。減少數據庫的訪問次數。
遇到問題：1、導入文件過大、數據量大導致訪問時間長，-----------------人工進行切割，每個文件的數據量在18萬條左右，大小在10m左右。
2、需求不明確，自己沒弄懂---------------開發時，需求是不明確的，自己仍要繼續進行設計，讓整個項目設計滿足需求，每次都是問別人細節問題，殊不知整個需求自己都沒弄懂
3、對比數據量在萬級別，數據全放到后台跑不開，------------導入文件時直接導入redis中（自己使用map類型的有鍵值對的，以比較的關鍵字為鍵），保證一邊數據是完整的，然后從數據庫中取出幾千條數據和redis中數據的鍵比較，一樣的移除留住不一樣的，然后將自己標記的數據遍歷取出來放到頁面中
中級想法
以上比較數據慢，是實時的比較，前台等的時間過長，很有可能直接斷掉。開始在表上做手腳。然后導入文件時直接按條 讀取，每100條數據時就訪問數據庫insert數據，最后將數據保存在數據庫中，所有的對賬直接用SQL跑。語句用的是左連接右連接直接找出兩個表中的差異數據
1 select * from t1 left join t2 where t1.id = t2.id and t2.id is null 2 union 3 select * from t1 right join t2 where t1.id = t2.id and t1.id is null
where 后面的條件自己按需求添加。
遇到問題： 1、SQL跑的時間慢，數據量在百萬級。-----------------首先自己想到的是分頁只差不幾條慢慢展示給用戶。可是SQL跑的是對最后的結果進行分頁，最關鍵的左右連接的時間沒有減少
2、實時對賬時間慢-------------------------直接改變對賬方式，首先需要創建對賬任務（參數設定好，開始任務時直接去）直接查詢可以分多少批（總數/一頁多少條），然后后台用定時任務處理，在每條記錄后添加一個是否比較的字段，一樣的勾上。查詢時直接查勛兩個信息表沒對上的數據，主要是開始了分批跑，取出一批數據（只取關鍵比較的一個字段）時，直接放到list中並在mybatis中遍歷放到in語句里跟另一個表所有數據比較，自己根據自己的查詢條件建立索引，不然相當慢，當所有批都跑完之后修改任務狀態為完成狀態，下次任務就取不到這個任務了
1 update t_pay_core_order t1,t_pay_bill_file_detail t2
2 set t1.is_check = 1,t2.is_check = 1
3 WHERE
4 t1.pay_order_no = t2.pay_order_no 5 and t2.pay_order_no in 6 <foreach item="payOrderNo" index="index" collection="orderlist" open="(" separator="," close=")"> 7 #{payOrderNo,jdbcType=VARCHAR} 8 </foreach> 9 and t1.trans_date >= #{startTime,jdbcType=INTEGER} 10 and t1.trans_date <= #{endTime,jdbcType=INTEGER} 11 and t1.pay_channel_id = #{payChannelId,jdbcType=TINYINT} 12 and t1.trans_type = #{transType,jdbcType=TINYINT}
這是我mybatis里的SQL語句。目前還是可以跑起來的。
后期優化
導入數據使用銀行接口減少人工導入文件的干預，將接口暴露且使用定時任務進行拉取必要的數據（默認為昨天的數據，傳參數指定收款與付款）該接口也可用於頁面的按鈕參數固定，指定日期直接導入數據
ps:關注一下本人公眾號，每周都有新更新哦！