AI/BI 儀錶板是寶貴的數據分析和決策工具，且有效率的載入時間可大幅改善用戶體驗。 本文說明快取和數據集優化如何讓儀錶板更有效能且更有效率。
查詢效能
您可以在工作區查詢歷程記錄中檢查查詢及其效能。 查詢歷程記錄會顯示使用 SQL 倉儲執行的 SQL 查詢。 點擊
在側邊欄中的查詢歷程查看查詢記錄。 請參閱<查詢歷程記錄>。
針對儀錶板數據集，Azure Databricks 會根據數據集的結果大小來套用效能優化。 如需資料集效能臨界值的相關資訊，請參閱 資料集效能臨界值。
數據集優化
您的儀表板會盡可能直接在瀏覽器中執行篩選或視覺化設定驅動的篩選和彙總作業，以最佳化速度。 這些效能最佳化有下列限制：
| 資料集大小 | 處理行為 |
|---|---|
| 小型（≤ 100K 行和≤ 100MB） | 為了獲得最佳儀表板速度，篩選和彙總會在初始資料集載入後在瀏覽器中執行。 由於這些作業會在本機處理，因此會避免與資料倉儲進一步互動，而且不會出現在查詢歷程記錄中。 |
| 大（> 100K 行或 > 100MB） | 過濾和聚合在後端伺服器上處理，而不是在瀏覽器中處理。 初始資料集查詢會包裝在 SQL WITH 子句中，而產生的查詢會出現在查詢歷程記錄中。 |
| 合併查詢 （大型資料集） | 針對傳送至後端的視覺效果查詢，針對共用相同子句和篩選述詞的相同 GROUP BY 數據集，將個別的視覺效果查詢合併成單一查詢進行處理。 在此情況下，使用者可能會在查詢歷程記錄中看到合併查詢，以擷取多個視覺效果或篩選的結果。 |
備註
參數會在執行階段將值直接取代為查詢，因此這些作業一律會出現在查詢歷程記錄中。
快取和數據新鮮度
儀錶板會維護 24 小時的結果快取，以優化初始載入時間，並盡最大努力運作。 這表示，雖然系統一律嘗試使用連結至儀錶板認證的歷程記錄查詢結果來增強效能，但在某些情況下，無法建立或維護快取的結果。 快取的數據沒有特定的記憶體限制或固定的查詢計數。
為了改善載入時間，儀錶板會先檢查儀錶板快取。 如果沒有可用的快取結果，他們會檢查一般 查詢結果快取。 雖然儀錶板快取最多可以傳回 24 小時過時的結果，但查詢結果快取永遠不會傳回過時的數據。 當基礎數據變更時，所有查詢結果快取項目都會失效。
針對多頁儀錶板，適用下列專案：
- 編輯草稿儀錶板會載入並快取所有數據集。
- 當檢視者開啟已發佈的儀錶板時，只會執行並快取支援使用中頁面的數據集。
- 如果已設定排程，則所有數據集都會根據排程重新整理，並快取這些結果。
下表說明快取如何因儀錶板狀態和認證而異：
| 儀表板類型 | 快取類型 |
|---|---|
| 採用共用資料權限發佈的儀表板 | 共用快取。 所有檢視者都會看到相同的結果。 |
| 草稿儀表板或以個別資料權限發佈的儀表板 | 每個使用者快取。 檢視者會根據其數據許可權查看結果。 |
如果基礎數據在最後一個查詢之後維持不變，或是擷取不到 24 小時前的結果，儀錶板會自動使用快取的查詢結果。 如果過時的結果存在，而且參數會套用至儀錶板，除非過去 24 小時內使用相同的參數，否則查詢將會重新執行。 同樣地，將篩選套用至超過 100,000 個數據列的數據集，會提示查詢重新執行，除非過去 24 小時內套用相同的篩選。
目前時間戳記函式與快取無效化
在 SQL 查詢中使用 current_timestamp() 或類似函式並不會使儀表板層級快取失效。 然而，這些函式會使查詢結果快取失效，該快取會檢查 SQL 查詢，並觸發快取刷新。
排程的查詢
將排程新增至具有共用資料許可權發佈的儀表板，可大幅加快所有儀表板檢視者的初始載入程式。
針對每個排程的儀錶板更新，會發生下列情況：
- 定義數據集的所有 SQL 邏輯都會在指定的時間間隔上執行。
- 結果會填入查詢結果快取，並協助改善初始儀錶板載入時間。