1. 使用建議
1.1 DEF 嵌套層數不宜過多
不建議 DEF 函式嵌套層數過多。因為後台計算會生成複雜 SQL ，資料量較大的情況下會影響效能，導致計算時間過長，影響儀表板載入速度。
單一公式中的 DEF 嵌套限制
為了儘量避免此情況發生，管理者可在「系統管理>BI參數」裏限制單一公式嵌套層數（預設 4 層），完成後點選「儲存」。如下圖所示：
多步驟 DEF 嵌套不建議過多
例如，客戶先新增一個 DEF 公式列 DEF1 ，在後續的 DEF 公式列中依賴 DEF1 進行計算，就是 2 層嵌套。嵌套的過多會增加效能負擔，載入過慢，嚴重情況會導致當機。
使用者可調整參數，對自助資料集所有步驟的 DEF 嵌套層數進行檢查，超過進行報錯提醒。詳情見本文第 3.2.3 節。
1.2 自助資料集DEF步驟之間避免穿插join類步驟
原因：FineBI6.1.5版本及之後，若 DEF 步驟之間無 join 類步驟，可實現 DEF 計算速度提升。
join類步驟是哪些：左右合併/上下合併/分組匯總/列轉欄/欄轉列/排序/過濾/刪除重複列/拆分行/欄位設定/其他表新增列
join類步驟特點：會改變資料行數/順序，因而增加後續 DEF 計算複雜度，降低 BI 效能。
2. 功能說明
2.1 DEF函式在自助資料集中計算邏輯
當自助資料集中匯出一個 DEF 函式的新增公式欄。如下圖所示：
在計算中， DEF 步驟可拆分為兩個：
根據 DEF 中的參數(參數1為聚合指標，參數2為分組，參數3為過濾)建立 DEF 檢視表，進行分組匯總以及過濾
依據分組資訊，將資料編輯中的原始檢視表與 DEF 檢視表進行合併，得到最終結果
2.2 DEF步驟造成的複雜度指標上升
前面對DEF的描述中我們提到了兩個檢視表，原始檢視表和 DEF 檢視表。對於一個新增列 DEF 來說，它會基於原始檢視表建立一個 DEF 檢視表用來做分組匯總，並與原始檢視表左右合併。
那麼勢必會導致整個計算的複雜度提升。場景如下：
場景1：DEF步驟之間存在嵌套關係
如 DEF2 嵌套 DEF1 ，如下圖所示：
場景2：DEF之間存在join步驟
其他步驟指的是會影響後續 def 計算的(改變資料行數/順序)：
左右合併/上下合併/分組匯總/列轉欄/欄轉列/排序/過濾/刪除重複列/拆分行/欄位設定/其他表新增列
舉例：由於過濾會導致資料行數發生變化，DEF2 無法與 DEF1 共用主檢視表，需要基於過濾後的檢視表進行計算。
2.3 產品優化
在FineBI6.1.5 中，對於部分 DEF 場景的計算進行優化，避免複雜度上升。
場景說明：多個 DEF 之間無嵌套關係不存在join步驟。
新增公式欄/新增匯總列/新增指派列/條件標籤列/時間差/獲取時間/拆分列這些步驟不會增加 DEF 計算複雜度。
此時多個 DEF 可以基於同一個檢視表計算。由此提升效能。
3. 自助資料集中DEF調優
3.1 問題描述
如果客戶存在大量DEF嵌套步驟，DEF 之間還存在一些 join 步驟時，自助資料集生成的計算描述將非常複雜，在編輯/更新階段都可能導致系統負載過高甚至當機。
3.2 解決方案
3.2.1 更新父表
如果資料集存在父表，更新其父表，避免父表未更新導致引入額外的def複雜度。
3.2.2 調整步驟順序
檢查自助資料集中使用 def 公式的步驟數量，若不影響計算結果，可參考下面的調優方案進行調優。
1）原先的左右合併穿插在 DEF 步驟中間。如下圖所示：
2）將左右合併步驟集中在一起，放在DEF計算的前面。如下圖所示：
3.2.3 調整控制參數
如果需要在一個自助資料集中使用超過限制的DEF步驟，需要調整 FineDB 資料庫中自助資料集 DEF 嵌套層級限制參數 SystemOptimizationConfig.etlDefComplexityLimit 的值
例如，我們對於自助資料集新增列DEF限制參數的值調整為 5 ，DEF步驟的嵌套超過 5 層時觸發報錯。當觸發限制條件時，報錯如下圖所示：
