本文列舉了幾種常見的更新慢的現象，指導使用者如何優化。
很多使用者只對一張單表進行更新，但是一張單表更新時間很長。
更新一張小小的單表，會引發與它相關的所有聯動表、分析表和聯動一起更新。所以一次簡簡單單的更新任務可能會觸發背後上百張表進行更新。
所以使用者設定了很多個單表更新且任務時間還比較分散的情況下，很容易重複更新。
例如：A 表背後有 100 張相關表，B 表背後也有 100 張相關表，其中有 99 張與 A 表相關表一樣。使用者在 6:00 對表 A 進行單表更新，6:10 對表 B 進行更新。這種情況下有 99 張表在 6:00 更新了一回，然後在 6:10 重複更新了一回。
只要將要更新的表一起更新，就不會出現重複更新的情況，系統會自動去重：
1）儘量採取全局更新，採用每天晚上對所有資料更新一次的方法。
2）若是一定要使用單表更新，將這些單表一起更新：
2019-08-15 版本以前：需要把要更新的單表放置在一個業務包中，對業務包設定更新任務。
2019-08-15 版本以後：僅需要單表的更新時間一致，不需要在一個業務包中，系統就會將它們一起更新。
使用者使用了「SQL資料集、增量更新、增量刪除」 這些需要手動配置 SQL 的功能後，更新速度慢。
SQL 執行速度慢，使用者在資料庫中執行 SQL 語句進行預覽可能都要花一些時間。
而在 FineBI 更新過程中，這些 SQL 都會執行，所以快不了。
優化 SQL 語句。
執行過左右合併的表，更新速度比較慢。
左右合併功能更像資料庫的 join 語句，功能強大，沒有限制，多少資料量都可以做。
但是做完之後資料量會增大。特別是 N:N 的時候，會出現笛卡爾積，千萬級別的表可能會膨脹到幾億級別。
資料量增大後，自然更新就慢了。
幾種左右合併的效能：
交集合併 (inner join, 1:1) > 左合併 (left outer join, N:1) = 右合併 (right outer join, 1:N) >> 聯集合併 (full join，N:N)
小資料量的表可以隨意選擇，但是大數據量的表在進行左右合併時：
若是沒有特殊需要，儘量選擇「交集合並」，避免使用「聯集合並」。
若是一定要使用「聯集合併」，則將一張大寬表按列進行拆分，變成列數比較少的表，這樣做完「聯集合並」後資料量膨脹沒有之前那麼誇張。
步驟順序不同但獲得相同結果的自助資料集，它們更新時間不一致。
自助資料集中有些步驟比如「分組彙總、左右合併、上下合併、複雜的新增列」，計算邏輯比較複雜。
若是使用者先進行了「過濾」，就可以用比較小的資料量來進行這些複雜計算，也減少了合併後膨脹的資料量，最終可以減少更新時間。
建議使用者先完成「過濾、排序、欄位設定」這種簡單的操作，再進行「分組彙總、合併、複雜新增列」這些複雜操作。