大數據一直被定義爲3V（數量大，速度快，多樣性） ，爲了支撐數據分析服務的正常運行，BI工具的報表快速處理能力也需要與時俱進。
比如億信ABI中，同樣一個查詢需求，爲什麼別人的計算結果獲取時間從1分鐘變成3秒鐘？可能是你不知道ABI具有性能調優的精髓所在。
爲了解決廣大BI工程師的調優難題，今天從SQL個數和過濾條件兩個方面來跟大家分享一下，億信ABI的性能調優小訣竅。
小訣竅之一：並行計算
在數據表格統計分析中，當一張報表中有多個分析報表時，系統需要生成多條SQL語句來完成數據查詢結果。SQL數量的增多，勢必會影響數據分析的查詢效率。爲了解決這個問題，億信ABI優化了“並行計算”的功能。
並行計算就是將多個查詢SQL並行執行，可提升多表格的計算效率；這裏舉幾個例子，讓大家直觀感受一下。
測試場景一：
數據庫與產品共用同一臺PC機資源，耗時由10次重複計算得到的平均耗時：
- PC機配置：雙核四線程，8G內存
- 數據庫：mysql5.0
- 產品：億信ABI
- 物理表數據量：48814條記錄
測試數據如下所示：
測試場景二：
數據庫與產品共用同一臺PC機資源，耗時由10次重複計算得到的平均耗時；
- PC機配置：雙核四線程，8G內存
- 數據庫：mysql5.0
- 產品：億信ABI
- 物理表數據量：100W大數據量
測試數據如下所示：
通過幾個測試場景的對比，可以看出，在多表格多分析區的場景下，開啓並行計算。最大化的利用系統資源，可以讓你的報表計算速度產生質的飛越。那麼設置方式是什麼呢？
無！需！任何設置，億信ABI就會自動進行多表格的並行計算。
BUT，如果由於某種原因，需要關閉並行計算，可以這麼設置：
在“資源管理器”下的目錄：
/root/products/eanalysemgr/conf/setup.conf 下配置屬性值
@set_calc_threadmode值爲none即可，如果不存在對應目錄，可手動自行創建哦。
截圖如下所示：
小訣竅之二：優化過濾條件，善用索引
億信ABI分析表中的過濾條件在報表計算時都會轉換成SQL語句中的where條件，在大數據量的情況下，where條件不夠優化，會直接導致SQL語句運行效率低下，最直接的表現就是SQL語句執行時沒用到索引或者用到的索引不夠好。
那什麼樣的過濾能構成一個質量上乘的where子句？什麼樣的過濾一定會造成where子句效率的損失？我們在編寫BI報表過濾條件時又該注意哪些問題呢？本例以數據庫Oracle爲例來給大家深入解讀一二。
- 杜絕在指標列上使用函數
Oracle使用索引的原則之一是：如果在where條件中的列上使用了函數，就不會使用該列上建立的索引。
舉例如下：
優化前：
主題表ESEN_BI的列pid上有索引，原過濾條件寫法爲：
left(ESEN_BI.pid,1)>='1'
and
left(ESEN_BI.pid,1)<='3'
由於在列上用了left函數並且使用的是不等運算符，因此BI無法直接優化爲like操作，只能將left轉換爲sql中的substr函數，結果就破壞了走索引的可能性；
優化後：
(ESEN_BI.pid like '1%' or
ESEN_BI.pid like '2%'or
ESEN_BI.pid like '3%')
該sql查詢會走索引，在測試環境經過驗證，這個過濾所在的分析表計算速度由原來的7分鐘直接提速到了14秒。
- 優化過濾表達式
養成良好的過濾條件編寫習慣。在理解業務過濾需求的基礎上，儘可能的用簡潔實用的表達式來編寫。編寫過濾條件時，可以使用以下3個小技巧：
- 能用like不用substr（取子串）
- 能用and儘量不要用or
- 儘量不要用 not in、in，有條件的情況下可以用範圍過濾來代替（>，<）
最後再給大家幾個與索引相關的小建議，趕緊拿出你的小本本記下來吧：
- 在索引列上使用函數時不會使用索引，如果一定要使用索引，建議建立函數索引；
- 索引列中有NULL值時，數據庫查詢不會走索引；
- 如果需要排序時，儘量根據已建立索引的列排序；
- 如果發現過濾條件和排序所需要的列沒有索引時，可以申請讓數據庫工程師整體評估具體優化方法；
- 切忌自行隨意增加索引，過多的索引反而會影響性能。