使用表格級儲存優化 DirectQuery 模型
DirectQuery 是一種獲取資料的方法 Power BI Desktop。 DirectQuery 方法涉及從內部直接連接到其來源儲存庫中的資料 Power BI Desktop。 它是導入資料的替代方案 Power BI Desktop。
使用 DirectQuery 方法時，整體使用者體驗在很大程度上取決於底層資料來源的效能。 緩慢的查詢 回覆 時間將導致負面的使用者體驗，在最壞的情況下，查詢可能會逾時。此外，任一時間開啟報表的使用者數量都會影響資料來源上的負載。 例如，如果您的報表中有 20 個視覺對象，並且有 10 人正在使用該報表，則資料來源上將存在 200 個或更多查詢，因為每個視覺對像都會發出一個或多個查詢。
不幸的是， Power BI 模型的效能不僅會受到底層資料源性能的影響，還會受到其他不可控因素的影響，例如：
網路延遲；更快的網路可以更快地傳回資料。
資料來源伺服器的效能以及該伺服器上有多少其他工作負載。 例如，考慮當數百人出於不同原因使用相同伺服器時發生伺服器刷新的影響。
因此，使用 DirectQuery 會為模型的效能品質帶來風險。 為了在這種情況下優化效能，您需要控製或存取來源資料庫。
有關更多詳細信息，請參閱 中的 DirectQuery 模型指南 Power BI Desktop。
使用 DirectQuery 的意義
最佳做法是將資料匯入 Power BI Desktop，但由於以下原因之一（DirectQuery 的優點），您的組織可能需要使用 DirectQuery 資料連線模式：
它適用於數據頻繁變化且需要近即時報告的情況。
它可以處理大數據，無需預先聚合。
它應用資料主權限制以遵守法律要求。
它可以與包含 SAP Business Warehouse (BW) 等度量的多維資料來源一起使用。
如果您的組織需要使用 DirectQuery，您應該清楚地了解其行為 Power BI Desktop 並了解其限制。 然後，您將能夠採取措施盡可能優化 DirectQuery 模型。
DirectQuery 連線的行為
當您使用 DirectQuery 連線 存取 Power BI Desktop 中的資料時，該連線的行為方式如下：
當您首次使用 中的 取得資料 Power BI Desktop功能時，您將選擇來源。 如果您連線 到關係來源，則可以選擇一組表，每個表將定義一個邏輯上傳回一組資料的查詢。 如果選擇多維來源，例如 SAP BW，則只能選擇來源。
載入資料時，不會將任何資料匯入 Power BI Desktop，僅載入架構。 當您在 Power BI Desktop中建立視覺物件時，查詢將傳送到底層來源以檢索必要的資料。 刷新視覺效果所需的時間取決於基礎資料來源的效能。
如果對基礎資料進行更改，由於快取的原因，這些更改不會立即反映在現有視覺效果中 Power BI 。 您需要執行刷新才能看到這些變更。 每個視覺效果都存在必要的查詢，並且視覺效果會相應更新。
當您將報表發佈到 Power BI 服務時，它將在 Power BI 服務中產生語義模型，與導入時相同。 但是，該語義模型中不包含任何資料。
當您在 Power BI 服務中開啟現有報表或建立新報表時，系統會再次查詢底層來源以擷取必要的資料。 根據原始來源的位置，您可能必須設定本機資料網關。
您可以將 釘選 視覺效果或整個報告頁面作為儀表板圖塊。 這些圖塊會按計畫（例如每小時）自動刷新。 您可以控制此刷新的頻率以滿足您的要求。 開啟儀表板時，圖塊會反映上次刷新時的數據，可能不包括對基礎資料來源所做的最新變更。 您可以隨時刷新打開的儀表板以確保其是最新的。
DirectQuery 連線的限制
使用 DirectQuery 可能會產生負面影響。 限制會有所不同，具體取決於所使用的特定資料來源。 您應該考慮以下幾點：
效能 - 如前所述，您的整體使用者體驗在很大程度上取決於底層資料來源的效能。
安全性 - 如果您在 DirectQuery 模型中使用多個資料來源，則了解資料如何在基礎資料來源之間移動以及相關的安全性影響非常重要。 您還應該確定安全規則是否適用於基礎來源中的數據，因為， Power BI，每個用戶都可以看到該數據。
資料轉換 - 與匯入的資料相比，源自 DirectQuery 的資料在應用資料轉換技術時有其限制 Power Query 編輯。 例如，如果您 連線 到 OLAP 來源（例如 SAP BW），則根本無法進行任何轉換；整個外部模型取自資料來源。 如果要對資料進行任何轉換，則需要在基礎資料來源中執行此操作。
建模 - 使用 DirectQuery 時，匯入資料的某些建模功能不可用或受到限制。
報表 --幾乎所有匯入資料的報表功能都支援 DirectQuery 模型，前提是基礎來源提供適當的效能等級。 但是，當報告在 Power BI 服務中發佈時，不支援快速洞察和問答功能。 此外，使用 Excel 中的「瀏覽」功能可能會導致效能下降。
有關使用 DirectQuery 的限制的更多詳細信息，請參閱 使用 DirectQuery 的影響。
現在您已簡要了解 DirectQuery 的工作原理及其所帶來的限制，您可以採取措施來提高效能。
最佳化效能
繼續使用 Tailwind Traders 場景，在查看語意模型期間，您發現查詢使用 DirectQuery 連線 Power BI Desktop 來取得來源資料。 DirectQuery 的這種使用是使用者遇到報告效能不佳的原因。 載入報表中的頁面花費的時間太長，並且在進行某些選擇時表格刷新速度不夠快。 您需要採取措施來優化 DirectQuery 模型的效能。
您可以檢查發送到底層來源的查詢，並嘗試找出查詢效能不佳的原因。 然後，您可以對 Power BI Desktop 和底層資料來源進行變更以最佳化整體效能。
優化數據在 Power BI Desktop
當您盡可能優化資料來源後，您可以使用 Power BI Desktop 效能分析器 在中採取進一步的操作，您可以在其中將查詢隔離到驗證查詢計劃。
您可以分析傳送到基礎來源的查詢的持續時間，以識別載入時間較長的查詢。 換句話說，您可以確定瓶頸所在。
優化 DirectQuery 模型時不需要使用特殊方法；您可以套用與匯入資料相同的最佳化技術來調整來自 DirectQuery 來源的資料。 例如，您可以減少報表頁面上的視覺物件數量或減少視覺物件中使用的欄位數量。 您也可以刪除不必要的列和行。
有關如何最佳化 DirectQuery 查詢的更詳細指南，請參閱： Power BI Desktop 中的 DirectQuery 模型指南和 成功使用 DirectQuery 的指南.
優化底層資料來源（連接資料庫）
您的第一站是資料來源。 您需要盡可能地調整來源資料庫，因為您為提高來源資料庫的效能所做的任何事情都會反過來改善 Power BI DirectQuery。 您在資料庫中採取的操作將發揮最大作用。
考慮使用以下適用於大多數情況的標準資料庫實務：
避免使用複雜的計算列，因為計算表達式將嵌入到來源查詢中。 將表達式推回來源會更有效，因為它避免了下推。 您也可以考慮向維度類型表新增代理鍵列。
檢查索引並驗證目前索引是否正確。 如果您需要建立新索引，請確保它們合適。
請參閱資料來源的指導文件並實施其效能建議。
自訂查詢縮減選項
Power BI Desktop 使您可以選擇發送更少的查詢並禁用某些交互，如果生成的查詢需要很長時間才能運行，這些交互將導致糟糕的體驗。 應用這些選項可以防止查詢持續存取資料來源，從而提高效能。
在此範例中，您編輯預設設定以將可用的資料縮減選項套用至您的模型。 您可以透過以下方式存取設定：選擇 檔案>選項和設定>選項，向下捲動頁面，然後選擇 查詢減少 選項。
可以使用以下查詢減少選項：
減少 發送的查詢數量 - 預設情況下，每個視覺物件都會與其他視覺物件互動。 選取此複選框將停用該預設交互。 然後，您可以使用 編輯互動 功能選擇相互互動的視覺效果。
切片器 - 預設情況下，選擇 立即套用切片器變更 選項。 若要強制報表使用者手動套用切片器更改，請選擇 為每個切片器新增應用程式按鈕，以便在準備就緒時套用變更 選項。
過濾器 - 預設情況下，選擇 立即套用基本過濾器變更 選項。 若要強制報表使用者手動套用篩選器更改，請選擇替代選項之一：
在所有基本篩選器中新增應用程式按鈕，以便在您準備好時套用更改
在 篩選窗格 新增應用程式按鈕以立即套用變更 (預覽版)
