StarRocks 查詢優化器深度解析

StarRocks 查詢優化器概覽

1. Development History of StarRocks

過去五年，StarRocks 發布了三個大版本：

StarRocks 1.0：通過向量化引擎和 CBO，打造極速 OLAP 數據庫。
StarRocks 2.0：通過主鍵模型、數據湖分析和查詢引擎優化，進一步打造極速統一的 OLAP 數據庫。
StarRocks 3.0：通過存算分離、物化視圖和數據湖分析，打造 Open LakeHouse。

2.StarRocks Architecture

StarRocks 的整體架構分為 Frontend 和 Compute Node 兩個核心組件：

FE：主要負責元數據管理、查詢優化和調度，由 Java 實現。
CN：作為查詢執行引擎并存儲 Lake 數據的 Data Cache ，由 C++ 實現。

3.StarRocks Optimizer overview

上圖展示了 StarRocks 優化器的整體架構。StarRocks 優化器的設計框架基于 Cascades 和 Columbia 兩篇論文實現，其搜索框架、Rule 框架以及 Property Enforce 機制均與 Cascades 架構保持一致。

圖中展示了 StarRocks 優化器更為詳細的優化流程，同時也體現出與 Cascades 框架的差異。

首先，StarRocks 優化器采用多階段優化流程，依次包括：Logical Rewrite、Cost-based Optimization、Physical Rewrite 和 Feedback Tuning。

其中，Logical Rewrite?是一種樹到樹的轉換過程（tree-to-tree transformation），涵蓋了多種常見的重寫規則，如子查詢改寫、CTE Inline 改寫、謂詞下推、列裁剪等。

Cost-based Optimization?基于 Cascades Memo 實現，包含多個關鍵的 cost-based rules，如 Join 重排序、Join 分布策略、聚合分布策略以及 MV Rewrite 等。

該階段的輸出是一棵分布式的物理執行樹。隨后，Physical Rewrite?階段會進行少量對成本無影響的物理改寫操作，例如 Global Dict Rewrite 和公共表達式復用等。

最后，Feedback Tuning?是在 2024 年引入的新功能，后續內容將介紹該機制如何根據運行時反饋信息動態調整執行計劃。

在對 StarRocks 及 StarRocks Optimizer 有了整體了解之后，接下來我們將深入探討 StarRocks Optimizer 的核心能力，主要包括三個具有代表性的優化手段，以及應對成本估算常見問題的三項解決方案：

三項代表性優化：Multi Left Join Colocate、Global Dict Optimization、Partition MV Union Rewrite
三項成本估算應對策略：Query Feedback、Adaptive Execution、SQL Plan Management

三項代表性優化

1.Multi Left Join Colocate

在了解 Multi Left Join Colocate 之前，我們先來看看什么是 Colocate Join。

在分布式數據庫中，Join 的執行策略主要包括：Shuffle Join、Broadcast Join、Replication Join 和 Colocate Join。

Shuffle Join 是指在執行 Join 之前，需要根據 Join 的 Key 對兩張表的數據進行 Shuffle，使其分布到相同的執行節點上。
Colocate Join 則是指兩張參與 Join 的表，其數據已根據 Join 的 Key 預先分布在相同的節點上，因此可以在本地直接執行 Join，不需要網絡傳輸。

在 StarRocks 中，我們依靠 Distribution Property Enforcer 來決定 ?join 的分布式策略。

左側是 Shuffle Join Enforcer 的示例，join 需要 hash(T1.a) 和 hash(T2.b) 的分布屬性，因為 T1 和 T2 是常規表，不滿足 hash(T1.a) 和 hash(T2.b) 的分布要求，因此會在 Scan T1 和 Scan T2 的操作符上強制執行 shuffle 的交換節點。

右側是 Colocate Join Enforce 的示例，join 同樣需要 hash(T1.a) 和 hash(T2.b) 的分布屬性，但由于 T1 和 T2 是 colocate 表，并且它們已按照 T1.a 和 T2.b 的 hash 分布，因此滿足 join 需求的屬性，無需添加 shuffle 節點，可以直接進行本地 join。

接下來，我們討論多表 Inner Join 的 colocate。圖中可以看到，當 T1、T2 和 T3 根據各自的 bucket column 進行 colocate 后，多個表的 join 過程與兩表的 join 相同，均可以直接進行 colocate。因為在 T1 和 T2 進行?Inner Join 后，join 結果的物理分布與 T1 或 T2 完全一致。

在介紹 Multi Left Join Colocate 之前，我們先確認一下 Left Join 和 Inner Join 的核心區別：

Left Join 會保留左表的數據，而右表中無法匹配的記錄將被填充為 NULL。如圖所示，T2 表 C1 列的第二行數據變為 NULL。

因此，當應用多表 Left Join 分布屬性 enforce 時，Left Join 后得到的 T2 表的 C1 列與原始 T2 表的 C1 列不同，這阻止了 Colocate Join 的執行。

然而，我們進一步分析該 Left Join SQL，看看是否確實無法執行 Colocate Join。

如上圖左側表格所示，它展示了該 Left Join SQL 的正確執行結果。

接著看右側表格，請思考 T2.C1 中的 NULL 值在 Colocate Join 和 Shuffle Join 情況下，是否會導致不同的結果。我們知道，對于 SQL 中的 NULL 值，NULL 與任意值進行等值比較時，結果均為 NULL。因此，無論 T2.C1 中的 NULL 值與 T3.C1 是否分布在同一節點，Join 的結果都將為 NULL。

由此可以得出結論：NULL 值的分布不會影響 T2 與 T3 是否可以執行 Colocate Join。

由于 T2 與 T3 表中除 NULL 以外的值滿足 Colocate 分布要求，因此兩表依然可以進行 Colocate Join。

為了使 distribution property enforcer 能夠支持上述場景，StarRocks 在分布屬性（distribution property）中引入了 NULL relax 和 NULL strict 兩種模式。

對于包含 null-rejecting 的 join on 謂詞，StarRocks 會生成 NULL relax mode，在分布屬性比較時會忽略 NULL 值的影響。

對于使用 null-safe equal join 的場景，StarRocks 會生成 NULL strict mode，在分布屬性比較時不允許忽略 NULL 值。

在引入 NULL-relaxed 和 NULL-strict 模式之后，我們可以重新審視多表 Left Join 的分布屬性 enforce 過程。

由于 T2.C1 處于 NULL-relaxed 模式，在執行過程中其分布屬性被視為滿足父節點的要求，因此能夠支持執行 Colocation Join。

2.Low Cardinality Global Dict Optimization

接下來我們來看低基數全局字典優化。在此之前，先了解什么是字典優化。字典優化指的是對編碼數據直接進行操作（Operations on Encoded Data），即對經過字典編碼的數據，在不進行解碼的情況下直接執行計算操作。

如圖所示，platform 在存儲層經過字典編碼，因此針對該列的過濾操作可以直接在編碼后的整型數據上執行。與字符串相比，整型的比較操作性能更高。

存儲層的字典優化在 StarRocks 1.0 中已經支持，但僅限于 filter 操作，適用場景較為有限。

因此，從 StarRocks 2.0 開始，系統引入了對全局低基數字典的優化支持。

全局字典優化的關鍵在于其適用“低基數”列。因為在分布式系統中，如果列的基數過高，維護全局字典的開銷將變得非常昂貴。因此，當前 StarRocks 對基數設定了較低的限制，默認值為 256。對于大多數生產環境中的維度表字段，這一默認值已能夠覆蓋絕大部分字符串列的需求。

值得注意的是，StarRocks 的全局字典機制對用戶完全透明。

引入全局字典后，字典優化不僅局限于過濾操作，還擴展支持了更多算子與函數，包括：Scan、Agg、Join，以及常用的字符串函數。

圖中展示了一個全局字典優化下的 group by 示例。StarRocks 首先為 city 和 platform 兩列構建全局字典，當執行 group by 操作時，會將基于字符串的分組轉換為基于整型的分組。這樣一來，Scan、Hash、等值比較（equal）以及內存復制（memcpy）等操作都能顯著提速，整體聚合查詢性能提升可達約 3 倍。

由于本文聚焦于優化器的機制，我們重點關注 StarRocks 如何利用全局字典進行執行計劃的改寫。

圖中展示的是全局字典改寫執行計劃的整體流程示意。該改寫發生在?Physical Rewrite?階段，基于 CBO 生成的最優分布式 Physical Plan，將可進行低基數優化的字符串列替換為對應的 int 列。

要完成這類改寫，需要同時滿足兩個條件：

執行計劃中的字符串列為低基數列；
FE 內存中已存在該字符串列對應的全局字典。

改寫成功后，系統會將低基數字符串列對應的全局字典與執行計劃一并下發至查詢執行器。

上圖展示了全局字典在執行計劃中改寫的具體流程示意。目前，StarRocks 支持對?STRING?和?ARRAY<STRING>?類型進行全局字典優化（理論上也可擴展至其他數據類型）。

該改寫基于 physical tree 進行，采用自底向上的（bottom-up）方式：當某個字符串列被識別為低基數列時，會被改寫為對應的 int 列。此過程中，所有使用該列的字符串函數、聚合函數等操作也將同步改寫為支持編碼后的整型列的版本。

若在某個節點發現后續操作無法繼續基于整型列執行優化，系統將自動插入一個 decode 節點。在 decode 節點中，整型列會被解碼還原為原始的 string 列。

Partitioned MV Union Rewrite

StarRocks 自 1.0 版本起即支持同步物化視圖，自 2.0 起將 MV 提升為核心特性，全面引入異步 MV 支持。MV 能力也從最初的單表擴展至多表場景，并在查詢自動改寫方面進行了大量優化和增強。

本文將聚焦于 MV 查詢改寫部分。

目前，StarRocks 已支持多種場景下的自動查詢改寫，包括聚合 Rewrite、多種 Join Rewrite、Union Rewrite、Nested MV Rewrite、復雜 SQL 的 Text-Based Rewrite，以及 View-Based Rewrite 等。

本文將重點介紹 Union Rewrite?

首先，我們來看為什么需要支持 MV Union Rewrite：

第一個場景是 Query on Lake。StarRocks 支持直接查詢多種 Data Lake 表格式。為了實現亞秒級的查詢性能，用戶通常會基于 Data Lake 中的熱點數據構建 MV。大多數情況下，用戶只關注最近一周或一月的數據，因此僅對這部分數據構建 MV 即可。然而，當用戶偶爾查詢近兩周或兩月的數據時，優化器需要能夠自動改寫查詢，將 MV 中的增量數據與 Data Lake 中的歷史數據進行 Union。

第二個場景是實時分析。在高并發（如上萬 QPS）的實時分析場景中，MV 能提供毫秒級查詢性能，但由于 MV 刷新存在一定延遲，可能無法包含最新數據。為了確保查詢結果的正確性，StarRocks 會將 MV 中已刷新的數據與 base 表中的最新數據進行 Union，確保返回給用戶的是完整、實時的查詢結果。

我們首先分析 MV 所有分區均已刷新的場景：

如圖所示，Query 與 MV 均為兩個簡單的 Inner Join，二者的主要區別在于謂詞范圍不同。由于 MV 結果集是 Query 結果集的子集，因此需構造補償謂詞，將其附加至 Query 中，并最終通過 Union 合并兩部分結果。

StarRocks 中的謂詞分類與補償邏輯，與微軟在《Optimizing Queries Using Materialized Views: A Practical, Scalable Solution》?一文中提出的方案保持一致。

接下來，我們分析 MV 分區部分已刷新的場景：

設定中，MV 與 Query 均為簡單的 group by count?查詢，且 MV 與 base 表各包含 4 個分區。假設 MV 的 P1 和 P2 分區已刷新，而 P3 和 P4 尚未刷新。此時，查詢的改寫邏輯將變為：分別對 MV 和 base 表執行查詢后再進行 Union 合并。

在具體執行計劃中，Union 的左子節點為對 MV 的掃描操作，右子節點為 Query 的執行計劃，區別在于 Scan 操作僅針對 MV 未刷新的分區。

最后，我們分析 Partitioned MV With Predicate 改寫的場景：

假設 base 表有兩個分區，其中 0201 分區對應的 MV 已完成刷新，而 0202 分區的 MV 尚未刷新。

MV 的定義為?select * from t where a > 20
Query 的定義為?select * from t where a > 10

結合前述兩種改寫場景，我們可以將改寫過程分為三步：

空間維度改寫：忽略時間維度，假設 MV 的所有分區已完成刷新。
在此基礎上，采用微軟論文中的方法進行改寫。
考慮 MV 的新鮮度和分區刷新的狀態，在第一步中的 “MV” 掃描操作上增加分區補償謂詞。

最終，將前兩步的結果進行整合，得到最終的查詢結果。

Cost 估計的挑戰及解決方案

Cost 估計的挑戰

過去幾年，在 cost estimation 方面，我們面臨了諸多挑戰，這些挑戰是所有 CBO 優化器普遍存在的問題，例如：

缺乏統計信息
抽樣統計信息收集不準確
抽樣統計信息估算誤差
即使統計信息準確，成本估計仍可能出錯（由于獨立性假設和無關假設不成立，或者多級 join 中誤差層層放大）
生產環境中常見的數據傾斜問題
最近一年部分用戶反饋的生產環境中，查詢計劃抖動的問題，這可能導致正常的小查詢變為大查詢，從而引發生產環境事故。

本文將主要介紹 Query Feedback、Adaptive Execution 和 SQL Plan Management。

在介紹這幾個高級功能之前，首先需要了解 StarRocks Statistics 相關的基本信息：

StarRocks 的單列統計信息包括基礎的 count、max、min、distinct，并支持 histogram。

StarRocks 的統計信息支持手動和自動收集，每種收集方式都提供全量和抽樣兩種選擇。

為了減少查詢計劃的耗時，統計信息會緩存于 FE 的內存中，優化器可以直接從內存中獲取列的統計信息。

StarRocks 默認的自動收集方式是：對小表進行全量收集，對大表進行抽樣收集。

統計信息收集的難點在于如何平衡資源消耗和準確度，同時避免統計信息收集任務對正常導入和查詢產生影響。

StarRocks 在以下四個方面優化了統計信息收集的準確度和性能：

Meta Scan：對于 count、min 和 max 的統計信息，StarRocks 通過 meta scan 進行優化，有效減少了資源消耗。
Table Sample：在抽樣時，StarRocks 會盡可能提高準確度，同時只掃描少量數據。
除了從減少掃描行數的角度降低統計信息收集的成本，StarRocks 還通過減少掃描的列數進一步降低統計信息收集的開銷。關于 table sample 和 predicate column 的優化將在后文詳細介紹。
減少統計信息收集對正常查詢和導入的影響：StarRocks 目前支持在單獨的 warehouse 中執行統計信息任務，確保統計信息收集作業不會干擾集群中的查詢和導入請求。

StarRocks 的 table sample 會遵循每個表的真實物理分布。從圖中可以看出，StarRocks 的表首先會根據 range 或 list 進行分區，之后根據 hash 或 random 方式進行分桶。每個 tablet 會根據數據大小被劃分為多個 segment，segment 是不可變的結構，內部的每一列會按每 64KB 劃分成多個 page，page 是最小的 I/O 單位。

在進行抽樣統計時，StarRocks 會從部分 tablet 中抽取部分 segment 的數據。

至于每個 segment 中讀取哪些 page 的數據，StarRocks 會根據數據分布特征選擇不同的抽樣算法。系統會先利用每個 page 的 zonemap 中的 max 和 min 值對 pages 進行排序，并評估數據的聚類程度：

如果數據聚類程度較高，StarRocks 會采用基于直方圖（histogram-based）的均勻抽樣算法（uniform sampling）。
如果數據聚類程度較低，則會采用 Bernoulli 抽樣算法。

此前提到的 Predicate Columns 的核心思想在于：在包含大量列的表中，只有少數關鍵列的統計信息會對優化器生成高質量執行計劃產生影響。在 OLAP 分析場景中，這些關鍵列通常是維度列，例如 filter columns、group by columns、distinct columns 和 join on columns。

因此，在列數較多的情況下，僅對這些維度或 Predicate Columns 進行統計信息收集，即可滿足大多數優化需求。

2.StarRocks Query Feedback

前文提到，Query Feedback 的設計初衷是為了解決由于各種原因導致的 cost 估計不準確問題。其核心思路是：利用真實的運行時信息修正優化器生成的執行計劃，從而在后續生成更優的計劃。

StarRocks 中，Query Feedback 的首個版本并不會直接更新統計信息，而是記錄了每類查詢對應的 tuning guide。

如圖所示，Query Feedback 包含兩個核心模塊：plan tuning analyzer 和 sql tuning advisor。

plan tuning analyzer 會結合查詢的實際運行信息和執行計劃，識別是否存在明確的 bad plan 。一旦識別出 bad plan，系統會進行記錄。
當優化器生成最終執行計劃時，sql tuning advisor 會檢查是否存在對應的 tuning guide；若有記錄，將應用其中推薦的更優執行計劃。

當前版本的 Query Feedback 可優化以下三類典型場景：

Join 的左右表順序
Join 的分布式執行策略
自適應的 Streaming 聚合策略：當檢測到第一階段的 Local 聚合效果良好時，可自動切換為全量聚合模式

上圖是一個 Query Feedback 的應用示例，用于修正 Join 左右表順序不當的問題。

左圖展示的是一個不合理的 Join 策略：行數為 5000 萬的大表位于右側，1114 行的小表位于左側。當優化器選擇使用大表構建哈希表時，執行效率顯著下降。

在右側的 Query Profile 中可以看到，左表的實際處理數據僅為 1119 行，這是由于 runtime filter 生效后將部分數據過濾掉，runtime filter 的機制將在后文介紹。

可以直觀看到，兩種不同執行計劃的查詢耗時存在數量級的差異。

上圖是 Query Feedback 的第二個應用示例，用于將錯誤的 Shuffle Join 調整為 Broadcast Join。

左側的查詢計劃中，左右兩個孩子都是 Exchange 操作，表明執行的是 Shuffle Join。然而，左表的行數僅為 11998 行，顯然 Broadcast Join 是更優的執行策略。

應用了 Query Feedback 調整后，Shuffle Join 被優化為 Broadcast Join，同時 Runtime Filter 也生效。

可以直觀看到，兩種不同執行計劃的查詢耗時存在數量級的差異。

3.StarRocks Adaptive Execution

接下來，我們了解 Adaptive Streaming Aggregate。對于簡單的?group by?查詢：select count(*) from table group by id，如果是非 colocate 表，StarRocks 會生成兩種分布式執行計劃。

第一種是分布式兩階段執行：在第一階段，StarRocks 會根據 id 列使用 hash 表進行聚合，并通過 hash shuffle 將相同 id 的數據發送到相同節點。第二階段會進行第二次 hash 聚合，并將最終結果返回客戶端。

第一階段進行一次 local 聚合的原因是為了減少 shuffle 網絡傳輸的數據量。這一假設適用于中低基數列，預計第一次聚合會帶來一定的聚合效果。

StarRocks group by 的第二種分布式執行計劃是一階段聚合，即在掃描數據后直接進行數據 shuffle，然后執行一次聚合。

顯然，一階段聚合適用于沒有聚合效果的 local 聚合場景，通常適用于高基數的 group by 列。

理論上，只要優化器能夠準確估計 group by 的基數，就可以選擇正確的一階段或二階段計劃。然而，對于多列 group by 的基數估計來說，這一任務非常具有挑戰性，因為多列通常不是獨立的，而是存在相關性。

因此，在 StarRocks 中，我們沒有在優化器層面直接解決這個問題，而是選擇在執行層通過自適應機制來解決。

StarRocks 的優化器傾向于生成分布式二階段聚合計劃，然后根據實際執行過程中獲得的聚合效果動態調整。

如圖所示，StarRocks 自適應聚合的原理如下：

在本地聚合過程中，每處理一批數據（例如 100 萬行），StarRocks 會首先利用 hash 表進行聚合。如果發現沒有聚合效果，系統就不會將數據繼續加入 hash 表，而是直接進行數據 shuffle，從而避免不必要的 hash 聚合。

接下來介紹一個自適應執行的案例：Adaptive Runtime Filters Selection。

首先簡要說明 runtime filter 的原理。在部分文獻中，這一機制也稱為?sideways information passing。

如圖所示，在等值 join 場景中，StarRocks 通過構建 hash 表時使用右表生成 Bloom Filter，并將其下推到左表的 Scan 節點，從而在 join 之前提前過濾掉不滿足條件的數據，減少 I/O、網絡傳輸和 CPU 消耗。

在復雜 SQL 查詢中，runtime filter 會有幾十倍的性能提升。過去 5 年，StarRocks 持續改進 runtime filter 的功能與效率，左側列出了其主要特性。

但在某些情況下，runtime filter 也可能帶來負優化。當 join 表數量較多或 join on 條件復雜時，會生成多個 runtime filter，會導致如下問題：

某些 runtime filter 無實際過濾效果，造成資源浪費；
應用順序不合理，優先應用選擇度高的過濾條件，而選擇度低的過濾條件被延后執行，也會造成不必要的 CPU 開銷。

有些數據庫可能依賴優化器對 runtime filter 的選擇度進行估算，并據此對多個過濾條件進行排序。而 StarRocks 選擇通過 Adaptive Execution 來應對這一問題。

如圖所示，StarRocks 會在處理一定數量的數據行后，動態計算每個 runtime filter 的實際選擇度，并據此自適應地調整過濾條件的應用策略。主要的調整原則包括：

只選擇 selectivity 較高的 filter
最多只選擇 3 個 filter
若某個 filter 的選擇度顯著優于其他條件，則只保留一個 filter。

4.SQL Plan Management

最后介紹的是 SQL Plan Management，這一功能目前正在開發中，已有第一版代碼合入。

之所以決定引入該功能，是因為過去一年中，一些用戶在生產環境中遇到執行計劃抖動的問題，導致原本的小查詢變為大查詢，從而引發生產事故。

SQL Plan Management 旨在解決兩個核心問題：

在系統升級后，避免因執行計劃變化導致查詢性能回退；
確保線上持續運行的重要業務查詢，其執行計劃穩定可靠，性能不會下降。

SQL Plan Management 的整體機制可分為兩個部分：

Baseline plan 的生成與保存
Baseline plan 的應用

在生成 Baseline plan 的過程中，主要包括以下三個步驟：

參數常量化處理：將 SQL 中的常量參數替換為特殊的 SPMFunctions，
生成執行計劃：基于參數化后的 SQL，生成對應的分布式 physical plan。
生成 Baseline SQL：將 physical plan 轉換為包含 hint 的 SQL。可以看到，這些 hint 中涉及的 shuffle 和 bucket 信息基本上確定了該 SQL 執行計劃的兩個關鍵點：join order 與 join 的分布式執行策略（在 StarRocks 中，包含 hint 的 join SQL 不會進行 reorder）。

使用 Baseline Plan 的流程分為四個步驟：

常量的參數化：將查詢中的常量替換為特殊的 SPMFunctions
獲取 Baseline SQL：根據參數化后的 SQL ，計算 Digest，并在 plan storage 中查找對應的 Baseline SQL。
將 Baseline SQL 中的 SPMFunctions 替換為輸入 SQL 中的常量。
按照正常的查詢處理流程處理帶有 hint 的 SQL。

FAQ

1.StarRocks 的 Join Reorder 算法

StarRocks 優化器實現了多種 Join Reorder 算法，根據不同的 Join 數量使用不同的算法：

Join 數量小于等于 4 時，使用 Join 結合律 + Join 交換律
Join 數量小于等于 10 時，使用左深樹 + 動態規劃算法 + 貪心算法
Join 數量小于等于 16 時，使用左深樹 + 貪心算法
Join 數量小于等于 50 時，使用左深樹
Join 數量大于 50 時，不進行 Join Reorder

2.如何優化 Join Reorder 和分布式策略的組合爆炸問題

1. 對 Join Reorder 的結果數量進行限制

左深樹和動態規劃算法只會產出一種 Join Reorder 結果
貪心算法只會取 Top K 個 Join Reorder 結果

2. 在探索搜索空間時，會基于 lower bound 和 upper bound 進行剪枝

3.Query Feedback 和 Plan Management 是否支持參數化

在第一版本中暫時不支持參數化，但計劃在今年實現該功能。其思路是將參數范圍切分為多個區間，并根據不同區間的參數值生成相應的 tuning guide 和 Baseline Plan。

總結

1. 優化器成本估算中的錯誤不可避免，執行器需要能夠根據運行時的真實統計信息做出自主決策，并提供及時反饋。因此，Cost-based 優化器需要與 Adaptive Execution 和 Query Feedback 緊密結合。

2. 在工程中，除了優化器本身，優化器的測試系統同樣至關重要。優化器需要通過正確性測試、性能測試和計劃質量測試等多方面的驗證。或許，整個數據庫開源生態可能還需要一個優秀的優化器測試系統和公開可復用的開源測試數據集。

3. Null 和 Nullable 的挑戰：Null 和 Nullable 在數據庫中既是一個復雜又讓人頭痛的問題。為了提升性能，執行器需要特別處理這些特殊值，尤其是在向量化執行器的環境下。同時，為了保證正確性，優化器和執行器都需要特別小心地處理 Null 和 Nullable。

4. 集成優化器比獨立優化器更強大：集成優化器可以比獨立優化器更加高效，因為它能夠獲取更多的上下文信息，從而進行更全面的優化。例如，全局低基數字典優化、Query Feedback 和 Adaptive Execution 等優化，都是依賴優化器與數據庫其他模塊的緊密合作。

本文僅覆蓋了 StarRocks 查詢優化器中的三個關鍵優化點。如果你還想了解更多背后的設計思路和實踐經驗，歡迎添加小助手，進入社區群一起探討～

直播回放：https://www.youtube.com/watch?v=hzMOXfTkg-4

PPT獲取：https://forum.mirrorship.cn/t/topic/18453

「輕松賺積分」

積分商城上線后，不少小伙伴反饋希望有更多樣、輕松的積分獲取方式。為此，我們特別準備了“輕松賺積分”活動，讓你更簡單地積累積分，快來看看吧～

參與方式：

單篇文章完成： 👍點贊 ?+轉發（技術群or朋友圈）+ ??在看（需全部完成）
將完整截圖發送至 StarRocks 小助手（有效截圖參考下方，小助手聯系方式見文末）

積分規則

每篇符合要求的文章可獲得20積分
同一用戶每日上限5篇（即100積分/日）
工作人員將在3個工作日內審核發放

重要說明：

活動期限：即日起至2025年12月31日
嚴禁刷量行為（如短時間集中轉發相同內容）
最終解釋權歸社區所有

積分商城注冊操作詳情，請參考：來領獎啦！StarRocks 社區 2025 布道師計劃正式開啟

有效截圖請參考：

關于 StarRocks?

StarRocks 是隸屬于 Linux Foundation 的開源?Lakehouse?引擎，采用 Apache License v2.0 許可證。StarRocks 全球社區蓬勃發展，聚集數萬活躍用戶，GitHub 星標數已突破 9800，貢獻者超過 450 人，并吸引數十家行業領先企業共建開源生態。

StarRocks Lakehouse 架構讓企業能基于一份數據，滿足 BI 報表、Ad-hoc?查詢、Customer-facing 分析等不同場景的數據分析需求，實現 "One Data，All Analytics" 的業務價值。StarRocks 已被全球超過 500 家市值 70 億元人民幣以上的頂尖企業選擇，包括中國民生銀行、沃爾瑪、攜程、騰訊、美的、理想汽車、Pinterest、Shopee 等，覆蓋金融、零售、在線旅游、游戲、制造等領域。