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.1 DEF函数在自助数据集中计算逻辑

当自助数据集中输出一个 DEF 函数的新增公式列。如下图所示：

在计算中， DEF 步骤可拆分为两个：

1. 根据 DEF 中的参数(参数1为聚合指标，参数2为分组，参数3为过滤)创建 DEF 视图，进行分组汇总以及过滤

2. 依据分组信息，将数据编辑中的原始视图与 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.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 层时触发报错。当触发限制条件时，报错如下图所示：