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 列。

3.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

结合前述两种改写场景，我们可以将改写过程分为三步：

1. 空间维度改写：忽略时间维度，假设 MV 的所有分区已完成刷新。
2. 在此基础上，采用微软论文中的方法进行改写。
3. 考虑 MV 的新鲜度和分区刷新的状态，在第一步中的 “MV” 扫描操作上增加分区补偿谓词。

最终，将前两步的结果进行整合，得到最终的查询结果。

Cost 估计的挑战及解决方案

1.Cost 估计的挑战

过去几年，在 cost estimation 方面，我们面临了诸多挑战，这些挑战是所有 CBO 优化器普遍存在的问题，例如：

• 缺乏统计信
• 息抽样统计信息收集不准确
• 抽样统计信息估算误差
• 即使统计信息准确，成本估计仍可能出错（由于独立性假设和无关假设不成立，或者多级 join 中误差层层放大）
• 生产环境中常见的数据倾斜问题
• 最近一年部分用户反馈的生产环境中，查询计划抖动的问题，这可能导致正常的小查询变为大查询，从而引发生产环境事故。

本文将主要介绍 Query Feedback、Adaptive Execution 和 SQL Plan Management。

在介绍这几个高级功能之前，首先需要了解 StarRocks Statistics 相关的基本信息：

StarRocks 的单列统计信息包括基础的 count、max、min、distinct，并支持 histogram。

StarRocks 的统计信息支持手动和自动收集，每种收集方式都提供全量和抽样两种选择。

为了减少查询计划的耗时，统计信息会缓存于 FE 的内存中，优化器可以直接从内存中获取列的统计信息。

StarRocks 默认的自动收集方式是：对小表进行全量收集，对大表进行抽样收集。

统计信息收集的难点在于如何平衡资源消耗和准确度，同时避免统计信息收集任务对正常导入和查询产生影响。

StarRocks 在以下四个方面优化了统计信息收集的准确度和性能：
1. Meta Scan：对于 count、min 和 max 的统计信息，StarRocks 通过 meta scan 进行优化，有效减少了资源消耗。

2. Table Sample：在抽样时，StarRocks 会尽可能提高准确度，同时只扫描少量数据。
3. 除了从减少扫描行数的角度降低统计信息收集的成本，StarRocks 还通过减少扫描的列数进一步降低统计信息收集的开销。关于 table sample 和 predicate column 的优化将在后文详细介绍。
4. 减少统计信息收集对正常查询和导入的影响：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 和 分布式策略的组合爆炸问题

• 对 Join Reorder 的结果数量进行限制
  左深树和动态规划算法 只会产出一种 Join Reorder 结果
  贪心算法只会取 Top K 个 Join Reorder 结果

• 在探索搜索空间时，会基于 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 等，覆盖金融、零售、在线旅游、游戏、制造等领域。