查詢計畫與時程

BigQuery 在查詢工作中內嵌了診斷查詢計劃和時間資訊。這與其他資料庫和分析系統中 EXPLAIN 等陳述式提供的資訊類似。這項資訊可從 jobs.get 等方法的回應中擷取。

如果是長時間執行的查詢，BigQuery 會定期更新這些統計資料。這些更新與工作狀態的輪詢頻率無關，但通常不會超過每 30 秒一次。此外，如果查詢作業未使用執行資源 (例如模擬執行要求或可從快取結果提供的結果)，就不會包含額外的診斷資訊，但可能會有其他統計資料。

背景

當 BigQuery 執行查詢工作時，會將宣告式 SQL 陳述式轉換成執行圖，圖中會把執行作業拆分成一系列的查詢階段，而這些階段是由更精細的執行步驟組合所組成的。BigQuery 會使用高度分散的平行架構來執行這些查詢。階段則是模擬許多潛在工作站可能平行執行的工作單元。各階段之間是使用快速的分散式重組架構通訊。

在查詢計畫中，工作單元和工作站這兩個詞彙用於傳達與平行處理相關的資訊。在 BigQuery 的其他位置，您可能會看到「運算單元」一詞，這是查詢執行作業多個層面的抽象表示法，包括運算、記憶體和 I/O 資源。頂層工作統計資料會使用這項抽象會計資料，估算個別查詢的費用。totalSlotMs

查詢執行架構的另一項重要屬性是動態，也就是說，查詢計畫可以在查詢執行期間修改。在查詢執行期間引進的階段，通常是用來改善資料在所有查詢工作站之間的分布狀況。在發生這種情況的查詢計畫中，這些階段通常會標示為「重新分割階段」。

除了查詢計畫外，查詢工作也會顯示執行時程，其中會列出查詢工作站已完成、待處理和作用中工作單位的計算。查詢可以同時有多個作用中工作站，各在不同的階段，因此時程主要是用來顯示查詢的整體進度。

使用 Google Cloud 控制台查看資訊

在 Google Cloud 控制台中，按一下「執行詳細資料」按鈕 (「結果」按鈕附近)，即可查看已完成查詢的查詢計畫詳細資料。

查詢計劃資訊

在 API 回應中，查詢計畫會以查詢階段清單的形式呈現。清單中的每個項目都會顯示各階段的總覽統計資料、詳細步驟資訊和階段時間分類。 Google Cloud 控制台不會顯示所有詳細資料，但 API 回應中可能會包含所有詳細資料。

階段總覽

各階段的總覽欄位可包含下列項目：

每階段時間分類

查詢階段提供相對和絕對兩種格式的階段時間分類。由於每個執行階段均代表一或多個獨立工作站執行的工作，因此提供的資訊會分成平均時間和最長時間兩種。這些時間分別代表某一階段中所有工作站的平均效能，以及指定分類中耗時最長的工作站效能。平均時間和最長時間會進一步分成絕對和相對表示法。在依比例的統計資料部分，會以任一區段中任何工作站所費的最長時間比例提供資料。

Google Cloud 控制台會使用相對時間表示法來呈現階段時間。

階段時間資訊的報告如下所示：

步驟總覽

步驟包含每個工作站在階段中執行的作業，以作業的排序清單呈現。每個步驟作業都有類別，且部分作業會提供更詳細的資訊。查詢計畫中的作業類別如下：

瞭解步驟詳細資料

BigQuery 提供「步驟詳細資料」，說明階段中的每個步驟所執行的動作。瞭解階段中的步驟，有助於找出查詢效能問題的來源。

如要查看階段的步驟詳細資料，請按照下列步驟操作：

1. 在「Query results」(查詢結果) 窗格中，按一下「Execution graph」(執行圖)。

   

2. 按一下感興趣的階段，開啟含有階段資訊的面板。

3. 在含有階段資訊的面板中，前往「步驟詳細資料」部分。

   

每個步驟都包含「子步驟」，說明該步驟執行的動作。子步驟會使用變數說明步驟之間的關係。變數開頭為貨幣符號，後面接著不重複的數字。

以下範例說明階段的步驟詳細資料，其中步驟之間共用變數：

READ
$30:l_orderkey, $31:l_quantity
FROM lineitem

AGGREGATE
GROUP BY $100 := $30
$70 := SUM($31)

WRITE
$100, $70
TO __stage00_output
BY HASH($100)

範例的步驟詳細資料會執行下列操作：

1. 階段分別使用變數 $30 和 $31，從資料表 lineitem 讀取資料欄 l_orderkey 和 l_quantity。

2. 階段會匯總變數 $30 和 $31，並分別將匯總結果儲存到變數 $100 和 $70 中。

3. 這個階段會將變數 $100 和 $70 的結果寫入 shuffle。階段會使用 $100 隨機排序階段結果。

如果查詢的執行圖夠複雜，提供完整的階段步驟詳細資料可能會導致擷取查詢資訊時發生酬載大小問題，因此 BigQuery 可能會截斷步驟詳細資料。

瞭解查詢文字的步驟

如需預先發布版支援服務，請傳送電子郵件至 bq-query-inspector-feedback@google.com。

瞭解階段步驟與查詢的關聯可能很困難。 「查詢文字」部分會顯示部分步驟與原始查詢文字的關聯。

「查詢文字」部分會醒目顯示原始查詢文字的不同部分，並顯示對應至醒目顯示原始查詢文字的步驟。醒目顯示的查詢文字只適用於緊接在醒目顯示部分上方的步驟。

螢幕截圖範例顯示的對應如下：

• 步驟 AGGREGATE: GROUP BY $100 := $30 會對應回查詢文字 select l_orderkey。

• 步驟 READ: FROM lineitem 會對應回查詢文字 select ... from lineitem。

• 步驟 AGGREGATE: $70 := SUM($31) 會對應回查詢文字 sum(l_quantity)。

並非所有步驟都能對應回查詢文字。

如果查詢使用檢視區塊，且階段的步驟已對應至檢視區塊的查詢文字，則「查詢文字」部分會顯示檢視區塊名稱和檢視區塊的查詢文字及其對應項目。不過，如果檢視區已刪除，或是您失去檢視區的 bigquery.tables.get IAM 權限，則「查詢文字」部分不會顯示檢視區的階段步驟對應。

解讀及最佳化步驟

以下各節說明如何解讀查詢計畫中的步驟，並提供查詢最佳化方法。

READ 步

READ 步驟表示某個階段正在存取資料以進行處理。資料可直接從查詢參照的資料表或隨機記憶體讀取。讀取前一階段的資料時，BigQuery 會從隨機存取記憶體讀取資料。使用隨選時段時，掃描的資料量會影響費用；使用預訂時，則會影響效能。

潛在的效能問題

• 掃描未分區資料表時，掃描範圍過大：如果查詢只需要一小部分的資料，這可能表示資料表掃描效率不彰。分割是個不錯的最佳化策略。
• 掃描大型資料表，但篩選比例很小：這表示篩選器無法有效減少掃描的資料。建議您修改篩選條件。
• 溢出至磁碟的隨機位元組：這表示資料未透過叢集等最佳化技術有效儲存，而叢集可將類似資料維持在叢集中。

最佳化

• 目標篩選：策略性地使用 WHERE 子句，盡早篩除查詢中的不相關資料。這樣可減少查詢需要處理的資料量。
• 分區和叢集：BigQuery 會使用資料表分區和叢集，有效找出特定資料區隔。請根據一般查詢模式，確保資料表已分區和分群，盡量減少 READ 步驟期間掃描的資料量。
• 選取相關資料欄：避免使用 SELECT * 陳述式。請改為選取特定資料欄，或使用 SELECT * EXCEPT 避免讀取不必要的資料。
• 具體化檢視表：具體化檢視表可以預先計算及儲存常用的匯總值，進而減少在查詢的 READ 步驟中讀取基礎資料表的需求。

COMPUTE 步

在 COMPUTE 步驟中，BigQuery 會對您的資料執行下列動作：

• 評估查詢中 SELECT、WHERE、HAVING 和其他子句的運算式，包括計算、比較和邏輯運算。
• 執行內建 SQL 函式和使用者定義函式。
• 根據查詢中的條件篩選資料列。

最佳化

查詢計畫可找出 COMPUTE 步驟中的瓶頸。尋找需要大量運算或處理大量資料列的階段。

• 將 COMPUTE 步驟與資料量相互關聯：如果某個階段顯示大量運算作業，並處理大量資料，則該階段可能適合進行最佳化。
• 資料偏斜：如果某個階段的運算上限遠高於運算平均值，表示該階段花費不成比例的時間處理少數資料切片。建議查看資料分布情形，確認是否有資料偏斜。
• 考慮資料類型：為資料欄使用適當的資料類型。舉例來說，使用整數、日期時間和時間戳記，而不是字串，可以提升效能。

WRITE 步

WRITE 步驟會處理中繼資料和最終輸出內容。

• 寫入隨機存取記憶體：在多階段查詢中，WRITE 步驟通常會將處理過的資料傳送至另一個階段，以進行後續處理。這在重組記憶體中很常見，因為這類記憶體會合併或匯總多個來源的資料。這個階段寫入的資料通常是中繼結果，而非最終輸出。
• 最終輸出：查詢結果會寫入目的地或暫時性資料表。

雜湊分區

當查詢計畫中的階段將資料寫入雜湊分區輸出時，BigQuery 會寫入輸出中包含的資料欄，以及選為分區鍵的資料欄。

最佳化

雖然 WRITE 步驟本身可能無法直接最佳化，但瞭解其角色有助於找出早期階段的潛在瓶頸：

• 盡量減少寫入的資料：著重於透過篩選和彙整功能，最佳化先前的階段，以減少這個步驟寫入的資料量。

• 分區：將資料表分區可大幅提升寫入作業的效益。如果寫入的資料僅限於特定分區，BigQuery 就能加快寫入速度。

  如果 DML 陳述式含有 WHERE 子句，且該子句針對資料表分區資料欄設有靜態條件，則 BigQuery 只會修改相關資料表分區。

• 去正規化取捨：去正規化有時會導致中間WRITE步驟的結果集較小。不過，這類做法也有缺點，例如儲存空間用量增加，以及資料一致性問題。

JOIN 步

在 JOIN 步驟中，BigQuery 會合併兩個資料來源的資料。聯結可包含聯結條件。聯結會耗用大量資源。在 BigQuery 中彙整大型資料時，彙整索引鍵會獨立重組，在相同時段對齊，以便在每個時段執行本機彙整。

JOIN 步驟的查詢計畫通常會顯示下列詳細資料：

• 聯結模式：指出使用的聯結類型。每種型別都會定義結果集中包含的聯結資料表資料列數。
• 彙整資料欄：這些資料欄用於比對資料來源之間的資料列。選擇的資料欄會大幅影響彙整作業的效能。

加入模式

• 廣播聯結：當一個資料表 (通常是較小的資料表) 可容納於單一工作節點或時段的記憶體中時，BigQuery 可以將其廣播至所有其他節點，有效率地執行聯結。在步驟詳細資料中尋找 JOIN EACH WITH ALL。
• 雜湊聯結：如果資料表很大或不適合廣播聯結，系統可能會使用雜湊聯結。BigQuery 會使用雜湊和隨機排序作業，隨機排序左側和右側資料表，讓相符的鍵最終位於同一個運算單元，以執行本機聯結。由於需要移動資料，雜湊聯結是成本高昂的作業，但可有效率地比對雜湊中的資料列。在步驟詳細資料中尋找 JOIN EACH WITH EACH。
• 自我聯結：SQL 反模式，其中資料表會聯結至自身。
• 交叉彙整：SQL 反模式，會產生比輸入資料更大的輸出資料，因此可能導致重大效能問題。
• 偏斜的聯結：某個資料表中的聯結鍵資料分布非常偏斜，可能導致效能問題。找出查詢計畫中，最長運算時間遠大於平均運算時間的情況。詳情請參閱高基數聯結和分區傾斜。

偵錯

• 資料量龐大：如果查詢計畫顯示在 JOIN 步驟中處理了大量資料，請調查聯結條件和聯結鍵。建議您篩選或使用更具選擇性的彙整鍵。
• 資料分布不均：分析聯結鍵的資料分布。如果某個資料表非常傾斜，請探索查詢分割或預先篩選等策略。
• 高基數彙整：如果彙整產生的資料列數遠多於左側和右側的輸入資料列數，查詢效能就會大幅降低。避免產生大量資料列的聯結。
• 資料表排序錯誤：請確認您已選擇適當的聯結類型，例如 INNER 或 LEFT，並根據查詢需求，將資料表從大到小排序。

最佳化

• 選擇性彙整鍵：盡可能使用 INT64，而非 STRING 做為彙整鍵。STRING 比較比 INT64 比較慢，因為前者會比較字串中的每個字元。整數只需要單一比較。
• 先篩選再聯結：在聯結前，對個別表格套用 WHERE 子句篩選器。這樣可減少聯結作業涉及的資料量。
• 避免在聯結資料欄上使用函式：避免在聯結資料欄上呼叫函式。您可以使用 ELT SQL 管道，在擷取或擷取後程序中，將資料表資料標準化。這種做法可免除動態修改聯結資料欄的需要，因此能更有效率地聯結，同時確保資料完整性。
• 避免使用自連接：自連接通常用於計算列相關關係。不過，自我聯結可能會使輸出列數增加四倍，導致效能問題。請考慮使用窗型 (分析) 函式，而非依賴自連接。
• 先處理大型資料表：即使 SQL 查詢最佳化工具可以判斷彙整的哪一側應使用哪個資料表，還是要適當排序彙整的資料表。最佳做法是先放置最大的表格，接著是最小的表格，然後依遞減大小排序。
• 去標準化：在某些情況下，策略性地去標準化資料表 (新增多餘資料) 可完全消除聯結。不過，這種做法會導致儲存空間和資料一致性方面的取捨。
• 分區和叢集：根據彙整索引鍵將資料表分區，並將共置資料叢集化，可讓 BigQuery 鎖定相關資料分區，大幅加快彙整速度。
• 最佳化偏移的聯結：為避免偏移的聯結造成效能問題，請盡可能預先篩選資料表中的資料，或將查詢作業拆分成兩個以上的查詢作業。

AGGREGATE 步

在 AGGREGATE 步驟中，BigQuery 會匯總及分組資料。

偵錯

• 階段詳細資料：檢查匯總的輸入和輸出列數，以及重組大小，判斷匯總步驟減少了多少資料，以及是否涉及資料重組。
• Shuffle 大小：如果 Shuffle 大小很大，可能表示匯總期間有大量資料在工作站節點之間移動。
• 檢查資料分布：確保資料均勻分布在各個分區。資料分布不均可能會導致匯總步驟中的工作負載不平衡。
• 檢查匯總：分析匯總子句，確認這些子句是否必要且有效率。

最佳化

• 叢集：在 GROUP BY、COUNT 或其他匯總子句中經常使用的資料欄上，叢集資料表。
• 分割：選擇符合查詢模式的分割策略。建議使用擷取時間分區資料表，減少彙整期間掃描的資料量。
• 提早彙整：盡可能在查詢管道中提早執行彙整作業。這樣可以減少匯總期間需要處理的資料量。
• 重組最佳化：如果重組是瓶頸，請想辦法盡量減少重組。舉例來說，您可以將資料表去正規化，或使用叢集將相關資料放在相同位置。

極端案例

• DISTINCT 聚合：含有 DISTINCT 聚合的查詢可能需要大量運算資源，尤其是針對大型資料集。如要取得近似結果，請考慮使用 APPROX_COUNT_DISTINCT 等替代函式。
• 大量群組：如果查詢會產生大量群組，可能會耗用大量記憶體。在這種情況下，請考慮限制群組數量或使用其他匯總策略。

REPARTITION 步

REPARTITION 和 COALESCE 都是最佳化技術，BigQuery 會直接套用至查詢中的重組資料。

• REPARTITION：這項作業的目的是重新平衡工作節點之間的資料分配。假設在重組後，某個工作站節點的資料量過大，REPARTITION 步驟會更平均地重新分配資料，防止任何單一工作站成為瓶頸。對於聯結等需要大量運算的作業，這一點尤其重要。
• COALESCE：如果資料經過重組後，產生許多小型資料桶，就會執行這個步驟。COALESCE 步驟會將這些 bucket 合併為較大的 bucket，減少管理大量小型資料片段的相關負擔。處理非常小的中繼結果集時，這項功能特別實用。

如果查詢計畫中出現 REPARTITION 或 COALESCE 步驟，不一定表示查詢有問題。這通常表示 BigQuery 主動最佳化資料分配，以提升效能。不過，如果這些作業重複出現，可能表示資料本身有偏差，或是查詢導致過多的資料重組。

最佳化

如要減少 REPARTITION 步驟，請嘗試下列做法：

• 資料分配：確保資料表已有效分區和分群。資料分布越平均，隨機排序後出現顯著不平衡的可能性就越低。
• 查詢結構：分析查詢，找出可能導致資料偏斜的來源。 舉例來說，是否有高度選擇性的篩選器或聯結，導致單一工作站只處理一小部分的資料？
• 合併策略：實驗不同的合併策略，看看是否能讓資料分配更平均。

如要減少 COALESCE 步驟，請嘗試下列做法：

• 匯總策略：考慮在查詢管道中提早執行匯總作業。這有助於減少可能導致 COALESCE 步驟的小型中繼結果集數量。
• 資料量：如果處理的資料集非常小，COALESCE可能就不是重大問題。

請勿過度最佳化。過早最佳化可能會使查詢變得更複雜，但不會帶來顯著效益。

聯合查詢說明

聯合查詢可讓您使用 EXTERNAL_QUERY 函式，將查詢陳述式傳送至外部資料來源。聯合查詢會受到稱為 SQL 下推的最佳化技術影響，查詢計畫會顯示下推至外部資料來源的作業 (如有)。舉例來說，如果您執行下列查詢：

SELECT id, name
FROM EXTERNAL_QUERY("<connection>", "SELECT * FROM company")
WHERE country_code IN ('ee', 'hu') AND name like '%TV%'

查詢計畫會顯示下列階段步驟：

$1:id, $2:name, $3:country_code
FROM table_for_external_query_$_0(
  SELECT id, name, country_code
  FROM (
    /*native_query*/
    SELECT * FROM company
  )
  WHERE in(country_code, 'ee', 'hu')
)
WHERE and(in($3, 'ee', 'hu'), like($2, '%TV%'))
$1, $2
TO __stage00_output

在這個計畫中，table_for_external_query_$_0(...) 代表 EXTERNAL_QUERY 函式。您可以在括號中看到外部資料來源執行的查詢。根據上述步驟，您可以發現：

• 外部資料來源只會傳回 3 個所選資料欄。
• 外部資料來源只會傳回 country_code 為 'ee' 或 'hu' 的資料列。
• LIKE 運算子不會下推，而是由 BigQuery 評估。

為進行比較，如果沒有下推，查詢計畫會顯示下列階段步驟：

$1:id, $2:name, $3:country_code
FROM table_for_external_query_$_0(
  SELECT id, name, description, country_code, primary_address, secondary address
  FROM (
    /*native_query*/
    SELECT * FROM company
  )
)
WHERE and(in($3, 'ee', 'hu'), like($2, '%TV%'))
$1, $2
TO __stage00_output

這次外部資料來源會傳回 company 資料表的所有資料欄和資料列，並由 BigQuery 執行篩選作業。

時程中繼資料

查詢時間軸會報告特定時間點的進度，提供整體查詢進度的快照檢視畫面。時程以一系列的樣本表示，這些樣本報告下列詳細資訊：

查詢範例

下列查詢會計算莎士比亞公開資料集中的列數，而查詢的第二個條件是將結果侷限在參照「哈姆雷特」的列：

SELECT
  COUNT(1) as rowcount,
  COUNTIF(corpus = 'hamlet') as rowcount_hamlet
FROM `publicdata.samples.shakespeare`

按一下「執行作業詳細資料」即可查看查詢計畫：

顏色指標會顯示所有階段中所有步驟的相對時間。

如要進一步瞭解執行階段的步驟，請點選arrow_drop_down展開階段的詳細資料：

在本例中，所有區段中耗費最長時間的是單一工作站在階段 01 等待階段 00 完成的時間。這是因為階段 01 需要有階段 00 的輸入，所以必須在第一個階段將輸出寫入中繼 Shuffle 後才能開始。

錯誤報告

查詢工作可能會在執行中失敗。因為系統會定期更新計畫資訊，所以您可以在執行圖中觀察到失敗的發生位置。在 Google Cloud 控制台中，階段名稱旁的勾號和驚嘆號分別標示著這個階段成功和失敗。

如要進一步瞭解如何解讀及解決錯誤，請參閱疑難排解指南。

API 表示法範例

查詢計畫資訊會內嵌於工作回應資訊，您可以呼叫 jobs.get 擷取這項資訊。舉例來說，下列摘錄的 JSON 回應適用於傳回哈姆雷特查詢範例的工作，其中顯示查詢計畫和時間軸資訊。

"statistics": {
  "creationTime": "1576544129234",
  "startTime": "1576544129348",
  "endTime": "1576544129681",
  "totalBytesProcessed": "2464625",
  "query": {
    "queryPlan": [
      {
        "name": "S00: Input",
        "id": "0",
        "startMs": "1576544129436",
        "endMs": "1576544129465",
        "waitRatioAvg": 0.04,
        "waitMsAvg": "1",
        "waitRatioMax": 0.04,
        "waitMsMax": "1",
        "readRatioAvg": 0.32,
        "readMsAvg": "8",
        "readRatioMax": 0.32,
        "readMsMax": "8",
        "computeRatioAvg": 1,
        "computeMsAvg": "25",
        "computeRatioMax": 1,
        "computeMsMax": "25",
        "writeRatioAvg": 0.08,
        "writeMsAvg": "2",
        "writeRatioMax": 0.08,
        "writeMsMax": "2",
        "shuffleOutputBytes": "18",
        "shuffleOutputBytesSpilled": "0",
        "recordsRead": "164656",
        "recordsWritten": "1",
        "parallelInputs": "1",
        "completedParallelInputs": "1",
        "status": "COMPLETE",
        "steps": [
          {
            "kind": "READ",
            "substeps": [
              "$1:corpus",
              "FROM publicdata.samples.shakespeare"
            ]
          },
          {
            "kind": "AGGREGATE",
            "substeps": [
              "$20 := COUNT($30)",
              "$21 := COUNTIF($31)"
            ]
          },
          {
            "kind": "COMPUTE",
            "substeps": [
              "$30 := 1",
              "$31 := equal($1, 'hamlet')"
            ]
          },
          {
            "kind": "WRITE",
            "substeps": [
              "$20, $21",
              "TO __stage00_output"
            ]
          }
        ]
      },
      {
        "name": "S01: Output",
        "id": "1",
        "startMs": "1576544129465",
        "endMs": "1576544129480",
        "inputStages": [
          "0"
        ],
        "waitRatioAvg": 0.44,
        "waitMsAvg": "11",
        "waitRatioMax": 0.44,
        "waitMsMax": "11",
        "readRatioAvg": 0,
        "readMsAvg": "0",
        "readRatioMax": 0,
        "readMsMax": "0",
        "computeRatioAvg": 0.2,
        "computeMsAvg": "5",
        "computeRatioMax": 0.2,
        "computeMsMax": "5",
        "writeRatioAvg": 0.16,
        "writeMsAvg": "4",
        "writeRatioMax": 0.16,
        "writeMsMax": "4",
        "shuffleOutputBytes": "17",
        "shuffleOutputBytesSpilled": "0",
        "recordsRead": "1",
        "recordsWritten": "1",
        "parallelInputs": "1",
        "completedParallelInputs": "1",
        "status": "COMPLETE",
        "steps": [
          {
            "kind": "READ",
            "substeps": [
              "$20, $21",
              "FROM __stage00_output"
            ]
          },
          {
            "kind": "AGGREGATE",
            "substeps": [
              "$10 := SUM_OF_COUNTS($20)",
              "$11 := SUM_OF_COUNTS($21)"
            ]
          },
          {
            "kind": "WRITE",
            "substeps": [
              "$10, $11",
              "TO __stage01_output"
            ]
          }
        ]
      }
    ],
    "estimatedBytesProcessed": "2464625",
    "timeline": [
      {
        "elapsedMs": "304",
        "totalSlotMs": "50",
        "pendingUnits": "0",
        "completedUnits": "2"
      }
    ],
    "totalPartitionsProcessed": "0",
    "totalBytesProcessed": "2464625",
    "totalBytesBilled": "10485760",
    "billingTier": 1,
    "totalSlotMs": "50",
    "cacheHit": false,
    "referencedTables": [
      {
        "projectId": "publicdata",
        "datasetId": "samples",
        "tableId": "shakespeare"
      }
    ],
    "statementType": "SELECT"
  },
  "totalSlotMs": "50"
},

使用執行資訊

BigQuery 查詢計畫會提供服務執行查詢的方式相關資訊，但服務的代管性質限制了部分詳細資料是否可以直接操作。使用這項服務時，系統會自動執行許多最佳化作業，這與其他環境不同，因為在其他環境中，調校、佈建和監控作業可能需要專門的專業人員。

如需可提升查詢執行和效能的具體技巧，請參閱最佳做法說明文件。查詢計畫和時間軸統計資料可協助您瞭解是否有特定階段霸占資源使用量。舉例來說，如果 JOIN 階段產生的輸出資料列比輸入資料列多很多，可能表示可以在查詢中更早進行篩選。

此外，時間軸資訊有助於判斷特定查詢是否單獨執行緩慢，或是因為其他查詢爭用相同資源而受到影響。如果您發現作用中的單元數在整個查詢生命週期中依然有限，但已排入佇列的工作單元數量卻一直很高，這可能代表減少並行查詢的數量會大幅改善某些查詢的整體執行時間。