查詢計畫視覺化工具可讓您快速瞭解 Spanner 選擇的查詢計畫結構,藉此評估查詢。本指南說明如何使用查詢計畫,協助您瞭解查詢的執行情形。
事前準備
如要熟悉本指南提及的 Google Cloud 控制台使用者介面部分,請參閱以下內容:
在 Google Cloud 控制台中執行查詢
- 前往 Google Cloud 控制台的 Spanner「Instances」頁面。
-
選取包含要查詢資料庫的執行個體名稱。
Google Cloud 主控台會顯示執行個體的「總覽」頁面。
-
選取要查詢的資料庫名稱。
Google Cloud 主控台會顯示資料庫的「總覽」頁面。
-
在側邊選單中,按一下「Spanner Studio」。
Google Cloud 控制台會顯示資料庫的「Spanner Studio」頁面。
- 在編輯器窗格中輸入 SQL 查詢。
-
按一下「執行」。
Spanner 執行查詢。
- 按一下「Explanation」分頁標籤,即可查看查詢計畫的視覺化資訊。
查詢編輯器導覽
Spanner Studio 頁面提供查詢分頁,可讓您輸入或貼上 SQL 查詢和 DML 陳述式,並針對資料庫執行這些陳述式,以及查看結果和查詢執行計畫。Spanner Studio 頁面的主要元件在下方螢幕截圖中標示為編號。

- 「分頁列」會顯示您已開啟的查詢分頁。如要建立新分頁,請按一下「新分頁」。
分頁列也提供查詢範本清單,您可以使用這些範本貼上查詢,以便取得資料庫查詢、交易、讀取等方面的深入分析資料,詳情請參閱內省工具簡介。
- 編輯器指令列提供下列選項:
- 「Run」指令會執行編輯窗格中輸入的陳述式,並在「Results」分頁中產生查詢結果,以及在「Explanation」分頁中產生查詢執行計畫。使用下拉式選單變更預設行為,以產生「僅顯示結果」或「僅顯示說明」。
在編輯器中醒目顯示某個項目會將「Run」指令變更為「Run selected」,讓您只執行所選項目。
- 「Clear query」指令會刪除編輯器中的所有文字,並清除「Results」和「Explanation」子分頁。
- 「格式化查詢」指令會在編輯器中設定陳述式的格式,方便閱讀。
- 「Shortcuts」指令會顯示可在編輯器中使用的鍵盤快速鍵組合。
- 「SQL 查詢說明」連結會開啟瀏覽器分頁,並顯示 SQL 查詢語法的說明文件。
每次在編輯器中更新查詢時,系統都會自動驗證查詢。如果陳述式有效,編輯器指令列會顯示確認勾號和「Valid」訊息。如果發生任何問題,系統會顯示詳細的錯誤訊息。
- 「Run」指令會執行編輯窗格中輸入的陳述式,並在「Results」分頁中產生查詢結果,以及在「Explanation」分頁中產生查詢執行計畫。使用下拉式選單變更預設行為,以產生「僅顯示結果」或「僅顯示說明」。
- 您可以在編輯器中輸入 SQL 查詢和 DML 陳述式。
這些語句會以顏色編碼,且系統會自動為多行語句新增行號。
如果在編輯器中輸入多個陳述式,除了最後一個陳述式外,每個陳述式後面都必須使用結束分號。
- 查詢分頁的底部窗格提供三個子分頁:
- 「結構定義」子分頁會顯示資料庫中的資料表及其結構定義。在編輯器中撰寫陳述式時,可做為快速參考。
- 當您在編輯器中執行陳述式時,「結果」子分頁會顯示結果。對於查詢,它會顯示結果表格,而對於
INSERT
和 >UPDATE
等 DML 陳述式,它會顯示有關受影響資料列數量的訊息。 - 「Explanation」子分頁會顯示在編輯器中執行陳述式時建立的查詢計畫,以圖表形式呈現。
- 「結果」和「說明」子分頁都提供陳述式選取器,可用來選擇要查看哪個陳述式的結果或查詢計畫。
查看取樣查詢計畫
- 前往 Google Cloud 控制台的 Spanner「Instances」頁面。
-
按一下含有要調查查詢的執行個體名稱。
Google Cloud 主控台會顯示執行個體的「總覽」頁面。
-
在「導覽」選單的「可觀察性」標題下方,按一下「查詢洞察資料」。
Google Cloud 控制台會顯示執行個體的「查詢深入分析」頁面。
-
在「資料庫」下拉式選單中,選取含有要調查查詢的資料庫。
Google Cloud 控制台會顯示資料庫的查詢負載資訊。TopN 查詢和標記表格會依 CPU 使用率排序,列出熱門查詢和要求標記。
-
找出 CPU 使用率高的查詢,並查看取樣的查詢計畫。按一下該查詢的 FPRINT 值。
「查詢詳細資料」頁面會顯示「查詢計畫範例」圖表,其中會顯示查詢的時間變化。您最多可以將時間軸拉到目前時間前七天。注意:查詢計畫不支援從 PartitionQuery API 和 分區 DML 查詢取得的 partitionToken 查詢。
-
按一下圖表中的任一圓點,即可查看較舊的查詢計畫,並以視覺化的方式呈現查詢執行期間採取的步驟。您也可以點選任何運算子,查看運算子的詳細資訊。
圖 8. 查詢計畫範例圖表。
在某些情況下,您可能需要查看取樣的查詢計畫,並比較查詢在不同時間點的成效。如果查詢會消耗較高的 CPU,Spanner 會在 Google Cloud 主控台的「查詢洞察」頁面上,保留取樣的查詢計畫 30 天。如要查看取樣的查詢計畫,請按照下列步驟操作:
查看查詢計畫視覺化工具
下列螢幕截圖中標示了視覺化工具的主要元件,並進一步加以說明。在查詢分頁中執行查詢後,選取查詢編輯器下方的「EXPLANATION」分頁標籤,即可開啟查詢執行計畫視覺化工具。
下圖中資料的流向是自下而上,也就是說,所有表格和索引都位於圖表底部,最終輸出結果則位於頂端。



圖表中的每個節點或資訊卡都代表一個迭代器,並包含下列資訊:
- 迭代器名稱。疊代器會使用輸入的資料列,並產生資料列。
- 執行階段統計資料會顯示系統傳回的資料列數量、延遲時間和 CPU 用量。
- 我們提供以下視覺提示,協助您找出查詢執行計畫中的潛在問題。
- 節點中的紅色長條是視覺化指標,可比較此疊代器的延遲時間或 CPU 作業時間,相對於查詢的總時間所占的百分比。
- 連接每個節點的線條粗細代表列數。線條越粗,傳遞至下一個節點的行數就越多。每張資訊卡和游標懸停在連接器上時,都會顯示實際的資料列數量。
- 在執行完整資料表掃描作業的節點上,會顯示警告三角形。資訊面板中的更多詳細資料包括建議,例如新增索引,或盡可能以其他方式修改查詢或結構定義,以免進行完整掃描。
- 選取企劃書中的資訊卡,即可在右側的資訊面板中查看詳細資料 (5)。
- 「迭代器資訊」會針對您在圖表中選取的迭代器資訊卡,提供詳細資料和執行階段統計資料。
- 查詢摘要會提供詳細資料,說明傳回的資料列數和執行查詢所需的時間。顯著的運算子會顯示明顯的延遲,相對於其他運算子會消耗大量 CPU,並傳回大量資料列。
- 查詢執行時間軸是一種以時間為基準的圖表,顯示每個機器群組執行查詢的時間長度。機器群組不一定會在查詢執行期間的整個期間運作。機器群組在執行查詢的過程中也可能會執行多次,但這裡的時間軸只代表第一次執行的開始時間和最後一次執行的結束時間。
調整效能不佳的查詢
假設貴公司經營的線上電影資料庫包含電影相關資訊,例如演員、製作公司、電影詳細資料等。這項服務在 Spanner 上執行,但最近出現一些效能問題。
您是這項服務的主要開發人員,因此我們請您調查這些效能問題,因為這些問題導致服務的評分不佳。您可以開啟 Google Cloud 控制台,前往資料庫執行個體,然後開啟查詢編輯器。您在編輯器中輸入以下查詢並執行。
SELECT
t.title,
MIN(t.production_year) AS year,
ANY_VALUE(mc.note HAVING MIN t.production_year) AS note
FROM
title AS t
JOIN
movie_companies AS mc
ON
t.id = mc.movie_id
WHERE
t.title LIKE '% the %'
GROUP BY
title;
執行這項查詢的結果如以下螢幕截圖所示。我們選取「FORMAT QUERY」,在編輯器中格式化查詢。畫面右上方也有一則註解,指出查詢有效。

查詢編輯器下方的「結果」分頁顯示查詢在兩分鐘內完成。您決定仔細查看查詢,瞭解查詢是否有效率。
使用查詢計畫視覺化工具分析執行速度緩慢的查詢
目前我們知道,前一個步驟中的查詢需要超過兩分鐘的時間,但我們不確定這項查詢是否盡可能有效率,因此無法判斷這個時間長度是否合理。
選取查詢編輯器下方的「EXPLANATION」分頁,即可查看 Spanner 為執行查詢及傳回結果而建立的執行計畫視覺化表示法。
下圖顯示的規劃圖相對較大,但即使在這個縮放等級,您仍可觀察到下列事項。
根據右側資訊面板中的「查詢摘要」,我們得知系統掃描了近 300 萬列資料,最終回傳的資料列數少於 64, 000 列。
我們也可以從「查詢執行時間軸」面板中看到,查詢涉及 4 個機器群組。機器群組負責執行部分查詢。運算子可在一或多部機器上執行。在時間軸中選取機器群組,即可在視覺化規劃中醒目顯示在該群組上執行的查詢部分。

基於這些因素,您決定將 Spanner 預設選擇的套用彙整改為雜湊彙整,藉此提升效能。
改善查詢
如要改善查詢效能,請使用彙整提示將彙整方法變更為雜湊彙整。這個彙整實作項目會執行以組合為基礎的處理程序。
以下是更新後的查詢:
SELECT
t.title,
MIN(t.production_year) AS year,
ANY_VALUE(mc.note HAVING MIN t.production_year) AS note
FROM
title AS t
JOIN
@{join_method=hash_join} movie_companies AS mc
ON
t.id = mc.movie_id
WHERE
t.title LIKE '% the %'
GROUP BY
title;
以下螢幕截圖顯示更新後的查詢。如螢幕截圖所示,查詢在 5 秒內完成,相較於變更前 120 秒的執行時間,大幅改善。

請查看下圖所示的新視覺規劃,瞭解這項改善功能的相關資訊。

您會立即發現一些差異:
這項查詢的執行作業只涉及一個機器群組。
匯總數量大幅減少。
結論
在這個情境中,我們執行了緩慢的查詢,並查看其視覺化計畫,找出效率不佳之處。以下是變更前後的查詢和企劃書摘要。每個分頁都會顯示已執行的查詢,以及完整查詢執行計畫的簡易視圖。
之前
SELECT
t.title,
MIN(t.production_year) AS year,
ANY_VALUE(mc.note
HAVING
MIN t.production_year) AS note
FROM
title AS t
JOIN
movie_companies AS mc
ON
t.id = mc.movie_id
WHERE
t.title LIKE '% the %'
GROUP BY
title;

之後
SELECT
t.title,
MIN(t.production_year) AS year,
ANY_VALUE(mc.note
HAVING
MIN t.production_year) AS note
FROM
title AS t
JOIN
@{join_method=hash_join} movie_companies AS mc
ON
t.id = mc.movie_id
WHERE
t.title LIKE '% the %'
GROUP BY
title;

在這種情況下,如果有大量資料列符合篩選條件 LIKE
'% the %'
,就表示可以改善。在有這麼多資料列的另一個資料表中尋找資料可能會耗費大量資源。將我們的彙整導入作業改為雜湊彙整,可大幅提升效能。