資金項目性能優化

1、項目背景

    該項目是一個對資金還、回款改造的項目。之前的作法是，在簽約或者發生標轉讓的時候生成回款信息，直接插入回款表，下次回款時從回款表裏面查找。如今這張表有2億+條數據，100G的數據量，而且還在快速增加，隨時都有可能爆發出問題。改造的邏輯是，按照投資人投資的金額佔比來實時計算回款。

 

2、性能優化

       一、緩存優化

        針對咱們這種應用場景，大部分狀況是投資人查看本身投了某一個標的回款狀況。這裏，能夠根據標和投資人作一個回款記錄的緩存，在service層就能夠把用戶請求給作掉。爲了保證數據一致性，在實際發生回款的時候，刷新這條緩存數據。

 

      二、多線程優化

       線上的服務器通常都多核的，徹底能夠開多個線程同事跑，充分利用計算資源。在這個項目中，對歷史數據作訂正的時候，同時開了20個線程併發修復歷史數據。這裏要注意一點，涉及到資金的數據一致性要求很高，通常會用到事務，這裏多線程要防止發生死鎖。

 

     三、對經常使用的字段建索引

      本次項目中涉及到幾個表關聯查詢，幾張表有1000w-2000w條數據，對關聯的字段創建索引以後，單次查詢時間由原來的1.5s降到了200ms左右。查詢效率提升了好幾倍。

 

    四、Ibatis表達式優化

       單個查詢中，一個SQL上千個字符，若是直接把sql裸露在<select> </select>關鍵詞中間，其實ibatis要作不少檢查的工做，若是這些sql是純查詢語句，不涉及到ibatis關鍵字，能夠用這個<![CDATA[       ]]> 括起來，性能能夠提升不少。個人一個測試用例中，由原來的700ms壓縮到200ms。

 

    五、SQL結構優化

      簡單的SQL結構優化空間可能不大，複雜的SQL尤爲是涉及關聯查詢或嵌套查詢的，若是單表數據量比較大，結構優化空間就很大了。每一次關聯就是笛卡爾乘積，若是兩張表都有必定的數據量，則乘積的數據量就很大了。這裏，咱們能夠遵照幾條原則：

      5.1  條件儘可能用到儘量多下降笛卡爾積的子查詢中，使得總得笛卡爾積最小化。好比說：A表中有20條數據；B標中有10條數據。若是過濾條件放在A中查詢能過濾15條數據，一樣的過濾條件放在B中查詢能過濾7條數據，則把過濾條件放在A中過濾，由於放在A中整體笛卡爾積只有有50，而放在B中笛卡爾積則有60條數據。

     5.2 查詢條件儘量的走索引。好比一樣的查詢條件，能夠拆分開，使得其中部分查詢能夠走某一張表的索引，則拆開查詢。

    5.3 能不要加括號的則不要加括號。增長了括號會限定執行的順序。其實數據庫自身會根據查詢條件優化查詢的。若是增長沒必要要的括號，會限定查詢的順序，使得數據庫沒法優化查詢。

   5.4 構建組合索引，索引字段順序問題。構建組合索引，經常使用來查詢的字段放在前面，部分查詢字段順序保持跟索引字段順序一致。

  5.5 刷選最多的條件優先執行。把刷選數據最多的條件放在最早執行的位置。

  5.6 慎用merge into語句。批量執行merge into時，當符合條件就更新，不符合條件就插入。這種狀況性能不好。能夠把整個list放到數據庫過濾一把，存在的就批量更新，不存在的，就批量插入，這種方式，性能更好。

 

   今天想到的就這些，先寫這麼多。