本頁面說明各種 Spanner 查詢最佳化工具版本,並提供相關記錄。目前的預設版本為 7。 如要進一步瞭解查詢最佳化工具,請參閱「關於查詢最佳化工具」。
Spanner 會以新版查詢最佳化工具的形式,推出查詢最佳化工具更新。根據預設,資料庫會在最佳化工具最新版本發布後 30 天內,開始使用該版本。
如果您使用 GoogleSQL 方言資料庫,可以管理查詢使用的查詢最佳化工具版本。在採用最新版本前,您可以比較舊版和最新版本的查詢效能設定檔。詳情請參閱「管理查詢最佳化工具」。
查詢最佳化工具版本記錄
以下摘要說明各版本中查詢最佳化工具的更新內容。
第 8 版:2024 年 10 月 28 日 (最新)
選擇以費用為依據的方案時,系統會考量
WITH
子句。改善分散式交叉套用和索引查詢的效能。
改善
JOIN
重新排序功能。改善含有大型
IN (...)
子句的查詢效能。改善特定情況下的
GROUP BY
效能。其他改善項目,包括更有效率地處理含有外鍵的查詢,以及索引選取。
LIMIT
第 7 版:2024 年 5 月 22 日 (預設)
新增以成本為準的索引聯集方案選取支援。
根據查詢的統計資料,新增對智慧選取搜尋與掃描計畫的支援,這些查詢不具備所有重要部分的搜尋式述詞。
新增支援以成本為依據選取雜湊聯結。
第 6 版:2023 年 9 月 11 日
透過完整外部聯結,改善限制推送和述詞推送。
改善基數估算和成本模型。
針對 DML 查詢啟用以費用為準的最佳化功能。
第 5 版:2022 年 7 月 15 日
改善索引選取、發布管理、排序位置和
GROUP BY
選取的成本模型。新增支援以成本為準的聯結演算法選取功能,可在雜湊和套用聯結之間選擇。合併聯結仍須使用查詢提示。
新增以成本為準的聯結可交換性支援。
第 4 版:2022 年 3 月 1 日
改善次要索引選取功能。
- 改善交錯式資料表彙整時的次要索引使用情形。
- 改善涵蓋次要索引的使用情形。
- 最佳化工具統計資料過時時,改善索引選取作業。
- 即使最佳化工具統計資料無法使用,或報表指出基本資料表很小,也請優先使用在主要索引欄上具有述詞的次要索引。
導入單次傳遞雜湊聯結,並透過新提示
hash_join_execution
啟用。彙整提示:
GoogleSQL
SELECT ... FROM (...) JOIN@{join_method=hash_join, hash_join_execution=one_pass} (...)
PostgreSQL
SELECT ... FROM (...) JOIN/*@ join_method=hash_join, hash_join_execution=one_pass */ (...)
如果 雜湊聯結的建構端輸入內容很大,這個新模式就很有幫助。如果您在查詢執行設定檔中觀察到下列情況,預期單次傳遞雜湊聯結的效能會更好:
- 雜湊聯結右側子項的執行次數,大於雜湊聯結運算子的執行次數。
- 雜湊聯結運算子右側子項的延遲時間也很長。
根據預設 (
hash_join_execution=multi_pass
),如果雜湊聯結的建構側邊輸入過大,無法放入記憶體,建構側邊就會分割成多個批次,我們可能會多次掃描探查側邊。使用新模式 (hash_join_execution=one_pass
) 時,如果雜湊聯結的建構端輸入內容無法放入記憶體,就會溢出到磁碟,且一律只會掃描探查端一次。改良選取用於搜尋的金鑰數量。
第 3 版:2021 年 8 月 1 日
新增合併聯結,這是新的聯結演算法,可使用新的 JOIN METHOD 查詢提示值啟用。
對帳單提示:
GoogleSQL
@{join_method=merge_join} SELECT ...
PostgreSQL
/*@ join_method=merge_join */ SELECT ...
彙整提示:
GoogleSQL
SELECT ... FROM (...) JOIN@{join_method=merge_join} (...)
PostgreSQL
SELECT ... FROM (...) JOIN/*@ join_method=merge_join */ (...)
新增聯結演算法 (推送廣播雜湊聯結),可使用新的 JOIN METHOD 查詢提示值啟用。
彙整提示:
GoogleSQL
SELECT ... FROM (...) JOIN@{join_method=push_broadcast_hash_join} (...)
PostgreSQL
SELECT ... FROM (...) JOIN/*@ join_method=push_broadcast_hash_join} */ (...)
介紹 distributed merge union 運算子,適用時預設會啟用。這項作業可提升查詢效能。
如果 SELECT 清單中沒有 MAX 或 MIN 匯總 (或 HAVING MAX/MAX),掃描作業的效能會略有提升。
GROUP BY
在這項變更之前,即使查詢不需要,Spanner 仍會載入額外的非群組欄。舉例來說,請參考下表:
GoogleSQL
CREATE TABLE myTable( a INT64, b INT64, c INT64, d INT64) PRIMARY KEY (a, b, c);
PostgreSQL
CREATE TABLE myTable( a bigint, b bigint, c bigint, d bigint, PRIMARY KEY(a, b, c) );
在這項變更之前,即使查詢不需要
c
欄,下列查詢仍會載入該欄。SELECT a, b FROM myTable GROUP BY a, b
如果查詢要求以 LIMIT 排序結果,且聯結導入了交叉套用運算子,
LIMIT
就能提升部分查詢的效能。這項變更完成後,最佳化工具會先在交叉套用輸入端套用排序限制。範例:
GoogleSQL
SELECT a2.* FROM Albums@{FORCE_INDEX=_BASE_TABLE} a1 JOIN Albums@{FORCE_INDEX=_BASE_TABLE} a2 USING(SingerId) ORDER BY a1.AlbumId LIMIT 2;
PostgreSQL
SELECT a2.* FROM albums/*@ force_index=_base_table */ a1 JOIN albums/*@ force_index=_base_table */ a2 USING(singerid) ORDER BY a1.albumid LIMIT 2;
透過
JOIN
推送更多運算作業,提高查詢效能。將更多運算 (可能包括子查詢或結構體建構) 推送至聯結。這有助於提升查詢效能,例如:可分散執行更多運算,以及將更多取決於推送運算的作業也推送下來。舉例來說,如果查詢設有限制,且排序順序取決於這些計算結果,則限制也可以透過聯結推送。
範例:
SELECT t.ConcertDate, ( SELECT COUNT(*) FROM UNNEST(t.TicketPrices) p WHERE p > 10 ) AS expensive_tickets, u.VenueName FROM Concerts t JOIN Venues u ON t.VenueId = u.VenueId ORDER BY expensive_tickets LIMIT 2;
版本 2:2020 年 3 月 1 日
- 在索引選取作業中新增最佳化功能。
- 在特定情況下,提升
REGEXP_CONTAINS
和LIKE
述詞的效能。 - 改善特定情況下的掃描效能。
GROUP BY
第 1 版:2019 年 6 月 18 日
包括許多以規則為基礎的最佳化作業,例如述詞下推、限制下推、多餘的聯結和多餘的運算式移除作業等。
使用使用者資料的統計資料,選取要用來存取每個資料表的索引。