最佳化查詢運算

評估查詢所需的計算時,請考慮所需的工作量。需要多少 CPU 作業時間?您使用的函式是否像 JavaScript 使用者定義的函式那樣需要額外的 CPU 資源?

以下最佳做法提供控制查詢計算的指引。

透過 SQL 查詢避免重複轉換資料

最佳做法: 如果您是使用 SQL 執行 ETL 作業,請避免發生重複轉換相同資料的情況。

例如,如果您是使用 SQL 來刪減字串或使用規則運算式擷取資料,則在目標資料表中將轉換的結果具體化的效能更高。規則運算式之類的函式需要額外的計算。在不增加轉換負擔的情況下查詢目標資料表會更有效率。

避免使用 JavaScript 使用者定義的函式

最佳做法:避免使用 JavaScript 使用者定義的函式,而改用原生 UDF。

呼叫 JavaScript UDF 需要具現化子程序。直接啟動這個程序並執行 UDF 會影響查詢效能。如果可行,請改用原生 (SQL) UDF

使用近似匯總函式

最佳做法:如果您的應用實例支援的話,請使用近似匯總函式。

如果您使用的 SQL 匯總函式擁有等效的近似函式,近似函式將會產生較快的查詢效能。例如,請使用 APPROX_COUNT_DISTINCT(),而不要使用 COUNT(DISTINCT)。詳情請參閱標準 SQL 參考中的近似匯總函式

您也可以使用 HyperLogLog++ 函式來計算近似值 (包括自訂近似匯總)。詳情請參閱標準 SQL 參考中的 HyperLogLog 函式

將查詢作業排序以發揮最佳效能

最佳做法:僅在最外側查詢或 window 子句內 (分析函式) 使用 ORDER BY。將複雜的作業排到查詢的最後面。

如果您需要將資料排序,請先進行篩選,以減少需要排序的值的數量。如果您先將資料排序,則您排序的資料會比所需的多得多。最好是對部分資料進行排序,而不要對所有資料排序並套用 LIMIT 子句。

當您使用 ORDER BY 子句時,它應該只出現在最外側的查詢中。除非是在窗型 (分析) 函式中使用 ORDER BY 子句,否則在查詢的中間放進這類子句會大幅影響效能。

為查詢進行排序的另一種技巧是將複雜的作業 (例如規則運算式和數學函式) 排到查詢的最後面。同樣地,這項技巧可在執行複雜的作業之前盡可能地剪除資料。

將結合模式最佳化

最佳做法: 對於結合來自多個資料表之資料的查詢,請將結合模式最佳化,並從最大的資料表開始。

當您使用 JOIN 建立查詢時,請考慮合併資料的順序。標準 SQL 查詢最佳化工具可以決定哪個資料表應位於結合的哪一邊,但仍建議您適當地為結合的資料表進行排序。最佳做法是先放置最大的資料表,接著放置最小的資料表,然後逐漸減少大小。

將大型資料表放在 JOIN 的左邊,並將小型資料表放在 JOIN 的右邊時,便建立了傳播結合。傳播結合會將較小資料表中的所有資料傳送至處理較大資料表的每個運算單元。建議先執行傳播結合。

如要查看 JOIN 中的資料表大小,請參閱取得資料表相關資訊

修整分區查詢

最佳做法:查詢分區資料表時,使用 _PARTITIONTIME 虛擬資料欄來篩選分區。

查詢分區資料表時,使用 _PARTITIONTIME 虛擬資料欄。使用 _PARTITIONTIME 篩選資料即可指定單一日期或日期範圍。例如,下列 WHERE 子句使用 _PARTITIONTIME 虛擬資料欄指定 2016 年 1 月 1 日至 2016 年 1 月 31 日之間的分區:

WHERE _PARTITIONTIME
BETWEEN TIMESTAMP(“20160101”)
    AND TIMESTAMP(“20160131”)

查詢只會處理該日期範圍指定的分區中的資料。篩選分區可提升查詢效能並降低成本。

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁