SelectDB最佳化查詢 - ApsaraDB for SelectDB

ApsaraDB for SelectDB通過Nereids最佳化器與Pipeline執行引擎實現查詢自動最佳化，同時支援手動最佳化查詢（如索引加速、高並發點查、物化視圖及 Join 最佳化）以滿足高效能查詢情境需求。

自動最佳化查詢規劃

在SelectDB中，Nereids最佳化器和Pipeline執行引擎是其內建的兩項核心的查詢處理技術，分別針對查詢最佳化和執行階段進行深度最佳化，顯著提升複雜查詢效能和資源使用率。以下是Nereids最佳化器和Pipeline執行引擎在SelectDB如何對一條SQL最佳化的大致流程：

各技術主要特性如下所示，如需瞭解更多，您需查閱相關文檔。

技術名稱	特性說明
Nereids全新最佳化器	更好地支援多層子迴圈嵌套等複雜查詢與多表Join查詢。減少了最佳化規則出現邏輯錯誤的可能。
Pipeline執行引擎	提高了CPU利用效率。減少了大查詢對小查詢的資源擠占問題。

手動最佳化查詢

如果SelectDB內建的Nereids全新最佳化器和Pipeline執行引擎仍未能滿足您的查詢需求，您可以通過統計資訊分析查詢資料，並根據分析結果選擇合適的最佳化策略，以最佳化您的查詢。

最佳化方式	使用情境	使用限制
高並發點查最佳化	適用於高並發的點查詢最佳化。說明點查詢是指從資料庫中檢索滿足特定條件的少量資料，通常通過主鍵或高基數列進行檢索。	開啟行存模式需要消耗額外的儲存空間。 PreparedStatement目前只支援主鍵點查。
物化視圖	適用於重複且耗時較長的複雜查詢的最佳化。	物化視圖針對Unique資料模型，只能改變列順序，不能起到彙總的作用，所以在Unique模型上不能通過建立物化視圖的方式對資料進行粗粒度彙總操作。單表上過多的物化視圖會影響資料匯入的效率。更多限制，請參見物化視圖的局限性。
索引加速	適用於任何情境下快速過濾或地位元據的最佳化。	不同的索引，會有不同限制，更多詳情，請參見索引加速。
Bucket Shuffle Join	Join最佳化。	Join條件中需存在左表的分布式列，且左表在執行時只使用了單分區的資料。
Colocation Join	Join最佳化。	Join條件中需存在左表的分布式列，且左右屬於同一個Colocate Group。
Runtime Filter	大表Join小表的最佳化。	使用Runtime Filter時Join語句需同時滿足以下兩個要求。左表大右表小：構建Runtime Filter需要承擔計算成本，包括一些記憶體的開銷。 Join 結果集小：結果集小說明這個Join語句可以過濾掉左表的絕大部分資料。
BITMAP精準去重	去重結果必須精確，且資料基數在百萬級以內，或儲存資源充足的情境。	類型限制僅直接支援整數類型（TINYINT/SMALLINT/INT/BIGINT）。非整數類型（如字串）需通過全域字典映射為整數後使用，但會增加維護成本。記憶體限制：高基數（如十億級）時，BITMAP 需要儲存一個巨大的位元組，記憶體壓力顯著，可能導致記憶體不足。
HLL近似去重	需處理海量資料（如十億級），且允許結果一定誤差（如分析類指標），或需在分布式系統中高效合并結果的情境。	精度損失：無法得到精確結果，誤差率會隨著基數的增加而降低（例如基數越大，誤差率相對越小）。需合理配置參數：HLL 的精度由參數（如寄存器數量、雜湊位元）決定，參數設定不當可能影響結果準確性。