提示
Microsoft Fabric Data Warehouse 是一個企業規模的關聯式倉庫，建立在資料湖基礎上，具備未來準備架構、內建 AI 及新功能。 如果你是資料倉儲新手，建議先從Fabric Data Warehouse開始。 現有的 專用 SQL 工作負載可升級至 Fabric，以取得資料科學、即時分析與報告等多項新功能。
本文提供最佳做法的集合，可協助您達到 Azure Synapse Analytics 中專用 SQL 集區的最佳效能。 如果您使用無伺服器 SQL 集區，請參閱 無伺服器 SQL 集區的最佳做法以取得特定指引。 接下來，您會在建置解決方案時，找到要專注於的基本指引和重要領域。 每個區段都會向您介紹概念，然後指向更深入地涵蓋概念的更詳細文章。
專用 SQL 集區載入
如需專用 SQL 集區載入指引，請參閱 載入數據的指引。
透過暫停和縮放來降低成本
如需透過暫停和調整來降低成本的詳細資訊，請參閱 管理計算。
維護統計數據
專用 SQL 集區可以設定成自動偵測和建立欄位的統計資料。 優化器所建立的查詢計劃只與可用的統計數據一樣好。
建議您為資料庫啟用AUTO_CREATE_STATISTICS，並讓統計數據每日或每次載入之後保持更新，以確保查詢中使用的數據行統計數據一律為最新狀態。
若要縮短統計資料維護時間，請選取哪些資料行具有統計資料，或需要最頻繁的更新。 例如，您可能會想更新那些每天可能會新增數值的日期欄位。 將重點放在聯結所涉及的欄位統計資料、WHERE 子句中使用的欄位，以及 GROUP BY 中使用的欄位。
如需統計數據的其他資訊，請參閱管理數據表統計數據、CREATE STATISTICS 和 UPDATE STATISTICS 文章。
調整查詢效能
將 INSERT 語句分組成批次
視您的需求而定，使用 INSERT 語句一次性載入至小型數據表（例如INSERT INTO MyLookup VALUES (1, 'Type 1')）可能是最佳方法。 不過，如果您需要全天載入數千或數百萬個數據列，單一 INSERTS 可能不是最佳的。
解決此問題的其中一種方法是開發一個寫入檔案的程式，然後開發另一個程式來定期載入此檔案。 如需詳細資訊， 請參閱 INSERT 文章。
使用 PolyBase 快速載入和導出數據
專用 SQL 集區支援透過數個工具載入和匯出數據，包括 Azure Data Factory、PolyBase 和 BCP。 對於效能不重要的少量數據，任何工具可能都足以滿足您的需求。
注意
當您載入或匯出大量數據，或需要更快的效能時，PolyBase 是最佳選擇。
PolyBase 載入可以使用 CTAS 或 INSERT INTO 來執行。 CTAS 會將事務歷史記錄降到最低，而且是載入數據最快的方式。 Azure Data Factory 也支援 PolyBase 載入，而且可以達到類似 CTAS 的效能。 PolyBase 支援各種檔案格式，包括 Gzip 檔案。
若要在使用 Gzip 文字檔時將輸送量最大化，請將檔案分成 60 個以上的檔案，以最大化載入過程的平行化。 若要加快總輸送量，請考慮同時載入數據。 本節的其他資訊包含在下列文章中：
- 載入資料
- 使用 PolyBase 的指南
- 專用 SQL 集區載入模式和策略
- 使用 Azure Data Factory 載入數據
- 使用 Azure Data Factory 移動數據
- CREATE EXTERNAL FILE FORMAT（建立外部檔案格式）
- 使用 SELECT 語句建立表格 (CTAS)
載入然後查詢外部資料表
PolyBase 對於查詢而言不是最佳選擇。 專用 SQL 集區的 PolyBase 數據表目前僅支援 Azure Blob 檔案和 Azure Data Lake 記憶體。 這些檔案沒有任何備份的計算資源。 因此，專用 SQL 集區無法委派這項工作，必須將整個檔案載入到 tempdb 後才能讀取數據。
如果您有多個查詢要查詢此數據，最好一次性載入此數據，並讓查詢使用本地資料表。 進一步的 PolyBase 指引包含在 使用 PolyBase 指南一文中。
哈希分配大型數據表
根據預設，資料表會以循環方式分配。 此預設值可讓用戶輕鬆地開始建立數據表，而不需要決定其數據表的散發方式。 循環輪替表可能對某些工作載荷執行得足夠。 但是，在大部分情況下，分散欄可提供更佳的效能。
當兩個大型事實數據表聯結時，最常見的範例是由按欄分布的數據表效能優於迴圈分布的數據表。
例如，如果您有依order_id散發的訂單數據表，而交易數據表也由order_id散發，當您將訂單數據表聯結至order_id上的交易數據表時，此查詢會變成傳遞查詢。 然後會排除資料遷移操作。 較少的步驟表示更快速的查詢。 較少的數據移動也可讓您更快速地進行查詢。
提示
載入分散式資料表時，您的傳入資料不應該在分配鍵上排序。 這樣做會減慢您的工作負載。
下面提供的文章連結將提供有關透過選擇分配欄位來改善效能的更多詳細資訊。 此外，您會發現如何在 CREATE TABLE 語句的 WITH 子句中定義分散式數據表的相關信息：
不要過度分割
雖然通過分割區切換或分割區消除來優化掃描能幫助維護數據，但若分割區過多可能會降低查詢速度。 通常，在 SQL Server 上運作良好的高粒度分割策略，可能無法在專用 SQL 集區上運作良好。
如果每個區段的行數少於一百萬，過多的區段會降低叢集資料行存放區索引的有效性。 專用 SQL 集區會自動將數據分割成 60 個資料庫。 因此，如果您建立具有100個資料分割的數據表，結果會是6,000個數據分割。 每個工作負載都不同，因此最好的建議是實驗劃分，來找出最適合您工作負載的方法。
考慮的其中一個選項是使用低於您使用 SQL Server 實作的數據粒度。 例如，請考慮使用每週或每月分區，而不是每日分區。
有關數據分割的詳細資訊，請參閱 數據表數據分割 一文。
將交易大小降到最低
INSERT、UPDATE 和 DELETE 語句會在交易中執行。 當它們失敗時，必須將它們復原。 為了降低長時間回復的可能性，請盡可能減少每筆交易的大小。 將 INSERT、UPDATE 和 DELETE 陳述式分割成多個部分，即可將交易大小降至最低。 例如，如果您預期 INSERT 需要 1 小時，可以將 INSERT 分成四個部分。 然後，每次執行的時間將縮短為 15 分鐘。
提示
使用特殊的最小記錄案例，例如 CTAS、TRUNCATE、DROP TABLE 或 INSERT 來清空數據表，以減少復原風險。
另一個消除復原的方法，是使用僅限中繼資料的作業，例如分區切換以進行資料管理。 例如，您可以每月分割數據，而不是執行 DELETE 語句來刪除資料表中order_date為 2001 年 10 月的所有數據列。 然後，您可以將具有數據的分割區替換為來自另一個表格的空白分割區（請參閱 ALTER TABLE 範例）。
對於未分割的數據表，請考慮使用 CTAS 來寫入您想要保留在數據表中的數據，而不是使用 DELETE。 如果 CTAS 需要相同的時間，執行會更安全，因為它的事務歷史記錄最少，而且可以視需要快速取消。
本節相關內容的詳細資訊包含在下列文章中：
減少查詢結果大小
減少查詢結果大小可協助您避免因大型查詢結果所造成的客戶端問題。 您可以編輯查詢，以減少傳回的數據列數目。 某些查詢產生工具可讓您將「top N」 語法新增至每個查詢。 您也可以將查詢結果 CETAS 到臨時表，然後使用 PolyBase 匯出進行下層處理。
使用最小可能的數據列大小
定義 DDL 時，請使用支援資料的最小數據類型，因為這樣做會改善查詢效能。 對於 CHAR 和 VARCHAR 數據行而言，這項建議特別重要。 如果資料行中最長的值是 25 個字元，請將您的資料行定義為 VARCHAR(25)。 請避免將所有字元數據行定義為較大的預設長度。 此外，若僅需使用 VARCHAR 而不需 NVARCHAR，請將欄位定義為 VARCHAR。
如需與上述資訊相關的基本概念詳細檢閱，請參閱數據表概觀、數據表數據類型和 CREATE TABLE 文章。
針對暫時性數據使用暫存堆積數據表
當您暫時在專用 SQL 集區上放置數據時，使用堆表通常會使整體過程更快。 如果您只載入資料以暫存數據，再執行更多轉換，將數據表載入堆積數據表會比將數據載入叢集數據行存放區數據表更快。
將數據載入臨時表也會比將數據表載入永久記憶體更快。 臨時表格會以「#」開頭，而且只能由建立它的會話存取。 因此，它們只能在有限的案例中運作。 堆積數據表定義於 CREATE TABLE 的 WITH 子句中。 如果您使用臨時表，請記得也在該臨時表上建立統計數據。
如需詳細資訊，請參閱臨時表、CREATE TABLE 和 CREATE TABLE AS SELECT 文章。
優化叢集列存儲數據表
叢集數據行存放區索引是您可以將數據儲存在專用 SQL 集區中最有效率的方式之一。 根據預設，專用 SQL 集區中的數據表會建立為叢集數據行存放區。 若要取得數據行存放區數據表上查詢的最佳效能，具有良好的區段品質很重要。 當在記憶體壓力下將數據寫入列存儲數據表時，列存儲區段品質可能會受到影響。
區段品質可由壓縮數據列群組中的數據列數目來測量。 如需偵測和改善叢集數據行存放區數據表區段品質的逐步指示，請參閱數據表索引一文中數據行存放區索引品質不佳的原因。
由於高質量的數據行存放區區段很重要，因此最好使用中型或大型資源類別中的使用者標識碼來載入數據。 使用較低的 數據倉儲單位 表示您想要將較大的資源類別指派給載入使用者。
列存儲表通常不會將資料推送至壓縮的列存儲區段，直到每個資料表有超過100萬行為止。 每個專用 SQL 集區資料表均會分佈於 60 個不同的分布。 因此，除非數據表有超過 6000 萬行，否則列存儲表不會有助於查詢效能。
提示
對於少於 6000 萬個數據列的數據表，具有數據行存放區索引可能不是最佳解決方案。
如果您分割數據，每個分割區都必須有1百萬列，才能受益於叢集列存儲索引。 對於擁有 100 個分割區的數據表，至少需要有 60 億行資料才能受益於叢集列存儲（60 個散發度 100 個分割區 各 1 百萬行）。
如果您的數據表沒有 60 億個數據列，您有兩個主要選項。 請減少分割區數目，或改為考慮使用堆積數據表。 也值得嘗試使用具有次要索引的堆積表來取代列存儲表，以查看是否可以獲得更好的效能。
查詢資料行存放區數據表時，如果您只選取所需的數據行，查詢會更快執行。 如需數據表和資料行存放區索引的詳細資訊，請參閱下列文章：
使用較大的資源類別來改善查詢效能
SQL 集區會使用資源群組作為將記憶體配置給查詢的方式。 一開始，所有用戶都會被指派到小型資源類別，為每個分區配置 100 MB 的記憶體。 總是有60個分配。 每個分配至少有 100 MB。 全系統記憶體配置總計為 6,000 MB，或低於 6 GB。
某些查詢，例如大型連接或載入叢集列存儲資料表，將受益於較大的記憶體配置。 某些查詢，例如純掃描，不會受到任何幫助。 使用較大的資源類別會影響並行。 因此，在將所有使用者移至大型資源類別之前，您會想要記住這些事實。
如需資源類別的詳細資訊，請參閱 工作負載管理 的資源類別一文。
使用較小的資源類別來增加並行度
如果您注意到使用者查詢出現長時間延遲，您的使用者可能會在較大的資源類別中執行。 此案例會提升並行位置的耗用量，這可能會導致其他查詢排入佇列。 若要判斷使用者查詢是否已排入佇列，請執行 SELECT * FROM sys.dm_pdw_waits 以查看是否傳回任何數據列。
工作負載管理和sys.dm_pdw_waits文章的資源類別會為您提供詳細資訊。
使用動態管理視圖 (DMVs) 來監視和優化您的查詢
專用 SQL 集區有數個 DMV，可用來監視查詢執行。 下列監控指引會逐步說明如何查看執行中查詢的詳細資訊。 若要快速尋找這些動態管理檢視 (DMVs) 中的查詢，請在查詢中使用 LABEL 選項來協助。 如需其他詳細資訊，請參閱下列清單中所包含的文章：
相關內容
另請參閱 疑難解答 文章以瞭解常見問題和解決方案。
如果您需要本文中未提供的資訊，請搜尋 Azure Synapse 的 Microsoft Q&A 問題頁面，是您向其他使用者和 Azure Synapse Analytics 產品群組提出問題的地方。
我們積極監視此論壇，以確保您的問題是由其他使用者或我們中的使用者回答。 如果您想要在 Stack Overflow 上提出問題，我們也會有 Azure Synapse Analytics Stack Overflow 論壇。