更新慢排查帮助

本文列举了几种常见的更新慢的现象，指导用户如何优化。

2.1 现象

很多用户只对一张单表进行更新，但是一张单表更新时间很长。

2.2 原因

更新一张小小的单表，会引发与它相关的所有关联表、分析表和关联一起更新。所以一次简简单单的更新任务可能会触发背后上百张表进行更新。

所以用户设置了很多个单表更新且任务时间还比较分散的情况下，很容易重复更新。

例如：A 表背后有 100 张相关表，B 表背后也有 100 张相关表，其中有 99 张与 A 表相关表一样。用户在 6:00 对表 A 进行单表更新，6:10 对表 B 进行更新。这种情况下有 99 张表在 6:00 更新了一回，然后在 6:10 重复更新了一回。

2.3 解决方法

只要将要更新的表一起更新，就不会出现重复更新的情况，系统会自动去重：

1）尽量采取全局更新，采用每天晚上对所有数据更新一次的方法。

2）若是一定要使用单表更新，将这些单表一起更新：

• 2019-08-15 版本以前：需要把要更新的单表放置在一个业务包中，对业务包设置更新任务。

• 2019-08-15 版本以后：仅需要单表的更新时间一致，不需要在一个业务包中，系统就会将它们一起拉起更新。

3.1 现象

用户使用了「SQL数据集、增量更新、增量删除」 这些需要手动配置 SQL 的功能后，更新速度慢。

3.2 原因

SQL 执行速度慢，用户在数据库中执行 SQL 语句进行预览可能都要花一些时间。

而在 FineBI 更新过程中，这些 SQL 都会执行，所以快不了。

3.3 解决方法

优化 SQL 语句。

4.1 现象

执行过左右合并的表，更新速度比较慢。

4.2 原因

左右合并功能更像数据库的 join 语句，功能强大，没有限制，多少数据量都可以做。

但是做完之后数据量会增大。特别是 N:N 的时候，会出现笛卡尔积，千万级别的表可能会膨胀到几亿级别。

数据量增大后，自然更新就慢了。

4.3 解决方法

几种左右合并的性能：

交集合并 (inner join, 1:1)  >  左合并 (left outer join, N:1) = 右合并 (right outer join, 1:N) >> 并集合并 (full join，N:N)

小数据量的表可以随意选择，但是大数据量的表在进行左右合并时：

• 若是没有特殊需要，尽量选择「交集合并」，避免使用「并集合并」。

• 若是一定要使用「并集合并」，则将一张大宽表按列进行拆分，变成列数比较少的表，这样做完「并集合并」后数据量膨胀没有之前那么夸张。

5.1 现象

步骤顺序不同但获得相同结果的自助数据集，它们更新时间不一致。

5.2 原因

自助数据集中有些步骤比如「分组汇总、左右合并、上下合并、复杂的新增列」，计算逻辑比较复杂。

若是用户先进行了「过滤」，就可以用比较小的数据量来进行这些复杂计算，也减少了合并后膨胀的数据量，最终可以减少更新时间。

5.3 解决方法

建议用户先完成「过滤、排序、字段设置」这种简单的操作，再进行「分组汇总、合并、复杂新增列」这些复杂操作。