monkeyboy_tech的博客

StarRocks索引存储结构摘要 StarRocks支持多种索引机制，各索引的存储位置和层级有所不同： 主键索引存储在persistent_index/目录的.pkindex文件中，是Tablet级全局索引；前缀索引和ZoneMap索引共存于segment_xxx.idx文件，是Segment级附属索引；Ordinal索引内嵌于.idx文件；Bloom Filter和Bitmap索引分别存储在独立的col_xxx.bloom和col_xxx.bitmap文件中。所有索引均可持久化，查询时可加载到内存缓存加

本文对比了Starrocks 3.5中开启和关闭点查（short circuit）功能时的查询性能差异。测试使用包含主键条件的查询语句，结果显示开启点查后查询总时间从14ms降至6ms。主要优化体现在：1）优化器仅执行RBO规则处理；2）调度步骤简化，跳过完整的PipelineDriver调度流程；3）执行时间从6.773ms缩短至857.455us，直接通过节点获取数据。点查功能通过减少优化步骤和简化执行流程显著提升了简单主键查询的性能。

文章摘要：本文介绍了SQL计算存储引擎的核心概念与优化方法。计算存储引擎分为计算（SQL解析、优化、执行）和存储（数据格式、获取）两部分。对比分析了Spark和Flink的任务调度模式（StageByStage与AllAtOnce），并详细阐述了SQL计算流程：从SQL解析到物理计划转换，包括RBO和CBO优化策略。在数据存储方面，区分了无存储系统（依赖底层文件过滤）和存算一体（支持索引）两种引擎的差异，特别强调了点查场景下调度优化的必要性。文章还提出了通过减少数据量、优化shuffle等方法来提升SQL执

本文介绍了Starrocks 3.5.5中TRACE命令的使用方式，支持TIMES/VALUES/LOGS/ALL等模式，并可指定BASE/MV/OPTIMIZER等模块。在ConnectProcessor.handleQuery中通过Tracers.init初始化指定模块，仅记录选定模块的指标信息（如OPTIMIZER模块的任务执行时间），避免保留所有模块数据导致FE内存过高引发OOM。这种设计通过模块化跟踪机制有效控制了内存使用。

本文分析了Starrocks中SQL性能分析的四种方法：Query Profile、EXPLAIN ANALYZE、ANALYZE PROFILE和trace。Query Profile提供最详细的执行指标，包括BE端信息但重启后丢失；EXPLAIN ANALYZE展示简化执行计划；ANALYZE PROFILE提供更丰富的执行指标；trace则专注于特定规则耗时。通过解析SQL语法树和执行流程，文章详细说明了各方法的实现机制，其中Query Profile通过FE-BE交互收集运行时数据，而EXPLAIN

本文分析了Starrocks 3.3.5中的点查(ShortCircuit)优化机制。点查通过跳过复杂的优化器和调度流程，直接向BE节点请求数据，相比常规查询节省了DAG构建、任务部署等时间。文章指出，在行存模式下点查只需通过PK获取单行数据，而列存模式则需要从不同列块中获取并组装数据，因此效率较低。调度机制方面，Starrocks默认采用Pipline调度，并行度参数随引擎模式切换而变化。代码分析显示，点查直接进入ShortCircuit路径，而常规查询还需经历prepareExec和deliverExe

本文基于StarRocks 3.3.5版本，分析了全局字典优化中涉及的两个关键规则：AddDecodeNodeForDictStringRule和LowCardinalityRewriteRule。该优化主要针对低基数字符串列，将其改写为整型列以提高查询性能。规则通过自底向上方式遍历物理计划树，在Scan、Filter、Agg等操作中应用字典优化，并在必要时插入decode节点还原原始字符串。文章详细解读了AddDecodeNodeForDictStringRule的实现逻辑，包括优化开关检查、表类型判断、

RoaringBitmap是高效压缩位图，简称RBM，它的原理是将 32bit int（无符号的）类型数据 划分为 2^16 个桶，即2^16=65536个桶，每个桶内用container来存放一个数值的低16位

本文基于Starrocks 3.3.5版本分析了物化视图的原子性更新机制。研究显示，Starrocks通过Insert Overwrite方式实现物化视图更新：首先创建临时分区写入数据，最后通过加锁操作原子性地替换分区。分析核心流程发现，在doCommit阶段会对表加写锁（LockType.WRITE），确保分区替换操作的原子性，而数据写入阶段不加锁以保证性能。这种设计既保证了数据一致性（不存在读取中间状态），又维持了高QPS场景下的稳定响应时间（RT）。元数据操作仅在最终替换时短暂加锁，使整个更新过程高效

本文分析了Starrocks 3.3.5版本中算子代价计算机制，重点关注StatisticsCalculator类对三种核心算子的统计信息估算方法： Scan算子：从CachedStatisticStorage获取表行数和列统计信息，处理分区剪枝，并通过谓词分析进一步优化统计估算。 Filter算子：直接继承子节点的统计信息，不进行额外计算。 Projection算子：基于子节点统计信息，通过表达式分析估算新生成列的统计值。 研究表明，Starrocks采用自顶向下的统计信息估算方法，大部分统计值都是通过近

本文分析了Starrocks 3.3.5版本中统计信息的收集机制。统计信息通过周期性运行SQL语句（以分区为维度）进行收集，并存储在_statistics_.column_statistics表和GlobalStateMgr.CachedStatisticStorage中，供后续基于CBO的代价计算使用。统计信息的收集由StatisticAutoCollector类管理，默认调度周期为5分钟。收集过程包括调度时间检查、统计表状态检查、初始化默认任务和运行采集任务。任务运行时会根据配置和表健康度决定是否进行全

本文总结了大数据场景下实时写入更新策略的演进，重点分析了COW、MOR和Delete+Insert三种技术策略。Starrocks的主键表通过Delete+Insert策略优化了实时更新和查询效率，避免了MOR策略中的读放大问题。在写入时，Starrocks利用主键索引和DelVector标记删除数据，更新操作则转换为Delete+Insert，确保数据一致性。读取时，仅需查询主键索引，避免了历史数据的合并操作，提升了查询性能。此外，谓词和索引的下推进一步减少了数据扫描量。总体而言，Starrocks的主键

本文基于Starrocks 3.3.5版本，探讨了如何在FE端实现短路径查询以加速点查速度。用户需将enable_short_circuit设置为true以启用该功能。通过ShortCircuitPlanner.checkSupportShortCircuitRead方法判断SQL是否支持短路径查询，该方法首先检查enable_short_circuit是否启用，然后通过LogicalPlanChecker判断SQL操作是否支持短路径。目前，仅支持Scan、Project、Filter和Limit操作。对于

其中 balanceClusterDisk balanceClusterTablet balanceBackendDisk balanceBackendTablet 分别对应上述的1 2 3 4 四点。最近在研究了一下 Starrocks的tablet的Rebalance的能力，这里进行记录一下。其中里面设计到的移动都是以 tablet Replica（副本）为单位进行移动的，,而最终的信息是来源于 BE和 FE进行交互的。本文基于 StarRocks 3.3.5。的统计信息，这个是来自于。

写这个的主要作用是梳理一下Starrocks的索引效率以及使用场景。

方法中, 具体的实现，可以细看 PartitionPruneRule对应的方法，也就是在这个规则里会对涉及到的谓词来过滤出对应的分区，很显然因为。至于 PartitionPruneRule 则会在“Optimizer” 阶段完成 ，也就是。函数不支持常量折叠，也就是不支持在计划解析和优化阶段来计算结果。以上的 都在 “Transformer” 阶段完成的。是常量，所以能够裁剪到对应的分区中去，而。在优化算子阶段就已经计算出来了,为。在计划优化阶段就可以计算出结果。函数的 只选择了一个分区的数据。

job 放入要执行的队列中，之后SchemaChangeHandler 以 alter_scheduler_interval_millisecond （10000ms）的轮询间隔从队列中取出要执行的任务，并调用。SchemaChangeHandler.process 会把当前的。来改变数据的分布状态,具体的执行过程是怎么样的呢？

经过分析我发现我们这边的分区是以月维度划分的，而且bucket的个数为2，这样每次写入数据的时候，就会把一个月的的数据的索引加载到内存中，这样就会导致BE的内存占用越来越大，除此之外，我们的业务场景就是会 更新 以往 的历史数据，且这样类似的任务有很多。我们的表结构是主键表。在Flink Yaml CDC 任务往 Starrocks写数据的过程中，突然遇到了。本文基于 StarRocks 3.3.5。可以通过如下命令查看 索引所占用的内存。所以我们进行了bucket调整，内存占用节约了5GB。

最近在做一些 StarRocks 相关的指标监控的时候，看到了FE master的CPU使用率相对其他FE节点是比较高的，且 呈现周期性的变化（周期为8分钟），于此同时FE master节点的GC频率相对于其他节点高出很多倍，于是我们利用arthas采集了大约15分钟CPU的火焰图。所以说在这种要收集的分区信息很多的情况下，HashMap的初始化，就很消耗CPU。这里会对里面涉及到的所有对象进行内存的评估，用来后续的内存使用指标显示。这种方法收集每个分区中某些字段的信息,这里后续会详细说。

大家都知道对于Starrocks来说FE是分master和follower的，而只有master节点才能对元数据进行写操作。,也就是会重定向到FEmaster节点。这其中的原因在网上是搜不到的，所以大家只知道。本文基于StarRocks3.1.7。

然而在查询的时候, Starrocks会做语法解析，以及基于CBO的优化，在这期间会统计涉及到的表的分区信息统计，而此时恰好遇到了后台线程的分区删除，导致了。阶段，这个阶段由于默认情况下是基于CBO的优化，所以会统计涉及的表所扫描的数据量,最终会走到。StarRocks 对分区带有TTL的表，会后台启动线程轮询的去删除分区，轮询的间隔受到。方法，进而生成物理执行计划，而在生成物理执行计划的阶段，会经过。这个后台线程进行分区的删除。对于这种带有TTL的分区表来说，会有。中就会删除正在进行查询迭代的。

其中涉及到的 变量为 consistency_check_end_time consistency_check_start_time 以及 MAX_JOB_NUM。把任务提交到后端的backend中去执行,主要代码在。AgentBatchTask.run方法中。本文基于Starrocks 3.1.7。

如果是失败任务的话，还会记录到failHistory中，并会重新进行Compaction的任务的延迟提交（延迟间隔为LOOP_INTERVAL_MS*10，其中LOOP_INTERVAL_MS 为200ms）中，并会重新进行Compaction的任务的延迟提交（延迟间隔为LOOP_INTERVAL_MS*2，其中LOOP_INTERVAL_MS 为200ms）注意： 这个命令只是修改了当前内存中的变量的值，如果需要永久的修改，需要配置到。处理完正在运行的Compaction任务后，会构建当前的。

通过本文的分析大致可以了解到在Starrocks的FE端是如何进行Command的交互以及数据流走向，其他的命令也是可以举一反三。和Spark以及hive等但是解析一样，StarRocks也是采用的Anltr4进行语法的解析，对应的java数据结构，但是一条SQL从客户端发送过来，是怎么一个数据流呢？操作的时候，就会根据执行的长短进行超时处理了。整体的数据流就结束了，待在同一个连接中进行。获取设置的超时时间，如果超时，则调用。中了，后续的流程和之前的一致。这种情况的解析，是通过。就会在语法层面解析为。