大數據一直被定義為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值時，數據庫查詢不會走索引；
-
如果需要排序時，盡量根據已建立索引的列排序；
-
如果發現過濾條件和排序所需要的列沒有索引時，可以申請讓數據庫工程師整體評估具體優化方法；
-
切忌自行隨意增加索引，過多的索引反而會影響性能。
如果還想要獲取更多億信ABI使用小竅門，收獲大驚喜，記得持續關注億信華辰。當然也可以留言給小億，說出你想要了解的其他應用小知識呢。
（部分內容來源網絡，如有侵權請聯系刪除）
