1. 概述
本文列举了几种常见的更新慢的现象，指导用户如何优化。
2. 单表更新时间长
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. SQL 执行慢
3.1 现象
用户使用了「SQL数据集、增量更新、增量删除」 这些需要手动配置 SQL 的功能后，更新速度慢。
3.2 原因
SQL 执行速度慢，用户在数据库中执行 SQL 语句进行预览可能都要花一些时间。
而在 FineBI 更新过程中，这些 SQL 都会执行，所以快不了。
3.3 解决方法
优化 SQL 语句。
4. 左右合并导致更新慢
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. 自助数据集操作优化
5.1 现象
步骤顺序不同但获得相同结果的自助数据集，它们更新时间不一致。
5.2 原因
自助数据集中有些步骤比如「分组汇总、左右合并、上下合并、复杂的新增列」，计算逻辑比较复杂。
若是用户先进行了「过滤」，就可以用比较小的数据量来进行这些复杂计算，也减少了合并后膨胀的数据量，最终可以减少更新时间。
5.3 解决方法
建议用户先完成「过滤、排序、字段设置」这种简单的操作，再进行「分组汇总、合并、复杂新增列」这些复杂操作。
