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)
小資料量的表可以隨意選擇，但是大數據量的表在進行左右合併時：
若是沒有特殊需要，儘量選擇「交集合並」，避免使用「聯集合並」。
若是一定要使用「聯集合併」，則將一張大寬表按列進行拆分，變成列數比較少的表，這樣做完「聯集合並」後資料量膨脹沒有之前那麼誇張。