重點摘要
- Import 會把資料載入語意模型,通常具有較完整功能與較佳互動效能。
- DirectQuery 保留資料在來源端,報表互動時再向來源送出查詢。
- DirectQuery 適合大型或接近即時需求,但受來源效能與功能限制影響。
- 連線到內部部署來源並發佈至 Service 時,通常還要規劃資料閘道。
Power BI 選擇 Import 或 DirectQuery,不能只看資料量。應一起評估更新時效、來源系統負載、網路延遲、模型功能、治理政策及維運能力;多數一般分析報表可先從 Import 開始,再確認是否真的需要 DirectQuery。
Import 與 DirectQuery 的核心差異是什麼?
Import 模式會將選取的資料複製到 Power BI 語意模型,報表互動主要由模型回應;DirectQuery 模式不匯入明細資料,而是在使用者篩選或操作視覺效果時查詢底層來源。
| 比較項目 | Import | DirectQuery |
|---|---|---|
| 資料位置 | 載入語意模型 | 保留在來源端 |
| 報表互動 | 通常較快 | 受資料庫、網路與查詢影響 |
| 資料時效 | 依重新整理頻率 | 可接近即時,但不是毫無延遲 |
| 模型功能 | 通常較完整 | 部分功能或轉換受限制 |
| 來源負載 | 重新整理時集中讀取 | 每次互動可能產生來源查詢 |
| 維運重點 | 容量與重新整理 | 查詢效能、併發、逾時與閘道 |
哪些情境適合使用 Import?
如果資料能在可接受時間內重新整理,且報表需要快速互動、完整建模功能或來源系統不適合承受大量即時查詢,Import 通常是較單純的起點。
- 每日、每小時或固定批次更新已足夠。
- 使用者人數多,希望降低每次操作對來源資料庫的壓力。
- 需要較完整的 Power Query、DAX 與模型功能。
- 原始資料是匯出的 Excel、CSV 或封存檔案。
哪些情境才需要考慮 DirectQuery?
DirectQuery 適合資料量大到不宜完整匯入,或業務需要比排程重新整理更接近即時的情境。但來源資料庫必須能有效支援報表查詢,否則使用者每次點選篩選器都可能等待。
- 資料規模經縮減後仍不適合載入模型。
- 必須依來源端權限或治理要求保留資料。
- 報表需要接近即時的資料狀態。
- 資料庫已建立適當索引、彙總與監控機制。
DirectQuery 不是「永遠最新」的保證。快取、視覺查詢、來源交易狀態及網路都會影響畫面,仍需定義可接受的延遲。
如何做連線模式決策?
先用業務需求建立判準,再進行小型效能測試。不要在正式專案後期才發現 DirectQuery 的查詢速度或功能限制不符合需求。
前置條件
- 確認資料來源是否支援 DirectQuery。
- 取得測試環境、唯讀帳號與資料庫管理者協助。
- 定義可接受的更新延遲、報表回應時間及同時使用人數。
- 確認發佈後是否需要內部部署資料閘道。
操作步驟
- 在 Power BI Desktop 選取「取得資料」並連接支援的資料來源。
- 若畫面提供模式選擇,先建立 Import 測試版本。
- 記錄模型大小、重新整理時間與常用視覺效果回應時間。
- 再建立 DirectQuery 測試版本,使用相同頁面與篩選條件比較。
- 透過效能分析器及資料庫監控找出慢速查詢。
- 減少不必要視覺效果、欄位與高成本查詢,必要時建立來源端彙總。
- 發佈測試工作區,設定閘道及認證後再次測試。
- 將結果與業務更新時效一起評估,再決定正式模式。
如何確認結果正確?
- Import 重新整理後與來源系統在同一截止時間的總計一致。
- DirectQuery 在相同篩選條件下回傳正確結果。
- 測試尖峰同時使用時的資料庫負載與回應時間。
- Service 中的認證、閘道與權限設定皆能持續運作。
示範情境:庫存分析要不要即時連線?
某企業的管理報表只需每天早上更新,Import 可提供穩定而快速的互動;倉庫作業畫面則要求接近即時庫存,因此評估 DirectQuery。團隊先建立來源端彙總表,限制明細查詢範圍,再透過資料閘道連線。限制是 DirectQuery 會把效能責任延伸到來源資料庫,不能只調整報表端。
常見錯誤與排除方式
- DirectQuery 報表很慢:減少頁面視覺效果,檢查來源索引、查詢折疊及高基數欄位。
- Desktop 可用、Service 無法連線:檢查閘道叢集、資料來源對應與認證。
- 模式切換後功能消失:確認 DirectQuery 的功能限制;不要假設兩種模式完全等價。
- Import 資料太舊:檢查排程重新整理、來源更新時間與重新整理歷程。
常見問題
DirectQuery 一定比 Import 節省資源嗎?
不一定。它減少模型內匯入資料,但會增加來源端查詢、網路與併發負擔。應衡量整體架構,而不是只看 PBIX 或模型大小。
Import 可以直接改成 DirectQuery 嗎?
通常不能把既有 Import 模型直接切回 DirectQuery。Microsoft 文件指出,部分情況可由 DirectQuery 切換為 Import,但反向切換不受支援,設計前應先確認。
DirectQuery 是否一定需要資料閘道?
不一定。是否需要取決於資料來源位置及 Service 能否直接連線。內部部署來源通常需要閘道;部分受支援的雲端來源可以直接建立連線。
延伸閱讀
- Power BI Desktop、Service、Mobile 與資料閘道怎麼分工?
- Power BI 匯入 CSV 的編碼與資料型別處理
- Excel 超過百萬列資料的正確處理方式
- Power BI 數據分析完整指南
參考來源
- Microsoft Learn(繁體中文):Power BI 中的 DirectQuery—何時使用、限制與替代方案
- Microsoft Learn(繁體中文):在 Power BI Desktop 中使用 DirectQuery
- Microsoft Learn(繁體中文):Power BI 服務中的語意模型模式
- Microsoft Learn(繁體中文):內部部署的資料閘道
- 本文另依課程逐字稿與實務操作經驗整理;實際支援模式依連接器而異。
作者:施文華 企業自動化顧問/講師。專注於 Excel、Power BI、Power Automate 與企業流程自動化。 作者介紹:/about 最後更新:2026-09-05 適用版本/測試環境:Windows 10/11、Power BI Desktop、Power BI Service

