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