从Query Plan到Profile：StarRocks查询性能调优实战指南

1. 为什么你的查询跑得慢从看懂执行计划开始很多刚开始用StarRocks的朋友最头疼的就是遇到慢查询。明明数据量不大机器配置也不差怎么一个查询就要跑几十秒甚至几分钟这时候你可能会去翻日志看监控但往往感觉无从下手。我刚开始用的时候也是这样后来发现解决问题的钥匙其实就在两个地方Query Plan查询计划和Query Profile查询档案。简单来说Plan是“作战计划”告诉你StarRocks打算怎么打这场仗Profile是“战后报告”告诉你这场仗实际是怎么打的哪里卡壳了。今天我就带你走一遍完整的性能调优实战流程从看懂Plan里的“暗号”到用Profile验证“战况”最后手把手教你调整优化。首先你得知道怎么拿到这两份关键文件。在StarRocks里每个查询都有一个唯一的QueryID。拿到它你就拿到了分析问题的入场券。最直接的方式就是在执行SQL前先打开Profile开关SET enable_profile true;然后执行你的慢SQL。执行完后用SHOW PROFILELIST;就能看到最近的查询记录找到对应的QueryID。至于Query Plan不需要等查询执行直接用EXPLAIN your_sql_statement;就能看到。听起来很简单对吧但关键是怎么看。Plan里一堆术语像avgRowSize、cardinality、preaggregationProfile里更是密密麻麻的时间线和指标。别急我们一步步来。我习惯把调优分成三步先看Plan预判问题再跑Profile验证问题最后动手优化解决问题。这是一个完整的闭环缺一不可。接下来我们就深入Plan的世界看看那些关键指标到底在告诉你什么。2. 解剖Query Plan预判性能瓶颈的“藏宝图”当你执行EXPLAIN命令后会看到一份结构化的文本输出。新手一看可能就懵了觉得像天书。别怕我们把它拆开看。一份典型的Plan会分成若干个PLAN FRAGMENT你可以把它理解成执行流水线上的一个“阶段”或“工作组”。数据在这些Fragment之间流动最终产生结果。我们的分析重点就落在每个Fragment里的那些算子节点上特别是最底层的扫描节点比如OlapScanNode和上层的聚合、连接节点。2.1 扫描节点的关键指标数据读取的“体检报告”扫描节点是你查询的起点它的效率直接决定了上游算子的“口粮”供应是否充足。这里有三个指标你必须盯紧avgRowSize(平均行大小)这个值告诉你从存储引擎扫描出来的每一行数据平均有多大单位是字节。我踩过一个坑一个表里有个VARCHAR(65535)的备注字段但实际90%的记录这个字段都是空的。查询时虽然用不上这个字段但avgRowSize依然巨大导致扫描效率极低。如果这个值异常大比如几十KB你就要怀疑是不是表设计有问题或者不该被选中的宽字段被扫描了。可以考虑使用更紧凑的数据类型或者通过物化视图Rollup只投影必要的列。cardinality(基数)这个数字代表查询优化器预估这次扫描会返回多少行数据。注意是“预估”它不一定等于实际行数。优化器根据统计信息来猜这个数。如果它猜得离谱比如实际1亿行它估了1万行那后续为这个预估数据量分配的内存、网络资源可能完全不对导致性能灾难。看到cardinality第一反应是这个估计准吗preaggregation(预聚合)这个状态可能是ON或OFF。这是StarRocks的一个性能利器。如果为ON意味着在扫描数据块Tablet时可以直接利用聚合索引比如Sum、Min、Max等进行预计算大大减少需要向上游传递的数据量。如果它为OFF并且你的查询包含聚合操作那就要亮红灯了这通常是因为你的查询条件或分组字段无法命中物化视图的预聚合条件。preaggregation: OFF是导致全量数据扫描和后续聚合压力的常见元凶。来看一个实际的Plan片段我们分析一下0:OlapScanNode TABLE: sales_records PREAGGREGATION: ON partitions1/1 rollup: sales_records_mv tabletRatio16/16 cardinality1000000 avgRowSize8.0这个扫描看起来挺健康预聚合开启命中了名为sales_records_mv的物化视图扫描了全部16个tablet数据分片预估扫描100万行每行平均8字节。如果这里preaggregation是OFF哪怕cardinality只有10万我也得去检查我的物化视图是不是没建对或者查询写法有问题。2.2 理解算子与数据流抓住“拖后腿”的环节扫描节点之后数据会流向聚合AGGREGATE、连接JOIN、排序SORT等算子。在Plan中你要关注算子的类型和数据重分布操作。聚合算子注意看是update serialize局部聚合还是merge finalize最终合并。一个良好的聚合计划通常是两阶段先在各个BE节点上做局部聚合减少数据量再通过网络交换EXCHANGE汇总到一个节点做最终合并。如果Plan里只有一个庞大的最终聚合可能意味着没有下推。连接算子关注连接类型HASH JOIN,MERGE JOIN,NESTED LOOP JOIN和左右子节点的cardinality。如果一个大表和一个极小表连接优化器应该选择Broadcast Join广播连接让小表复制到所有节点去和大表关联。如果它错误地选择了Shuffle Join需要网络重分区网络开销就会激增。EXCHANGE节点这是网络数据传输的标志。EXCHANGE意味着数据需要在不同BE节点间移动。它的类型很重要BROADCAST广播小表数据复制到所有节点。HASH_PARTITIONED按哈希值重分区常用于Shuffle Join或分组聚合。UNPARTITIONED汇总到单个节点比如最终结果收集。网络传输是分布式查询的主要开销之一。在Plan里如果看到一个EXCHANGE节点后面跟着巨大的cardinality预估你就要警惕这里可能成为瓶颈。理想的状态是通过preaggregation和合理的Join方式让需要EXCHANGE的数据量降到最低。通过分析Plan我们就像拿到了一张“藏宝图”上面标出了可能埋着性能“地雷”的地方预聚合是否开启、基数估计是否准确、网络传输的数据量是否过大。但这张图是“计划”实际执行会不会有偏差这就需要我们进入实战用Query Profile来验证了。3. 深入Query Profile验证运行时性能的“显微镜”如果说Query Plan是蓝图那么Query Profile就是施工现场的实时监控录像。它记录了查询执行过程中每一个算子实际消耗的时间、处理的数据行数、内存使用情况等。当查询跑完或者作为运行中的长查询通过Runtime Profile查看Profile能告诉你Plan的预估到底准不准以及时间到底花在了哪里。3.1 启用与查看Profile打开监控面板默认情况下为了性能考虑StarRocks不会为所有查询生成Profile。我们需要按需开启。除了前面提到的SET enable_profile true;对于生产环境我更推荐设置一个阈值只对慢查询自动抓取Profile避免开销-- 只对执行时间超过30秒的查询收集详细Profile SET global big_query_profile_threshold 30s;对于正在运行的、疑似卡住的长查询可以启用运行时Profile定期获取快照SET runtime_profile_report_interval 10; -- 每10秒上报一次查询结束后使用SHOW PROFILELIST;找到你的QueryID然后用最强大的分析命令ANALYZE PROFILE FROM 你的QueryID;这个命令会以清晰的树形结构展示整个查询的Profile信息比看原始文本直观太多了。3.2 解读Profile核心指标找到时间“小偷”Profile信息很丰富我们聚焦几个最关键的OperatorTotalTime这是每个算子的总耗时是定位瓶颈最直接的指标。通常耗时最长的那个算子就是主要瓶颈。比如一个OlapScanNode花了总时间的70%那问题很可能出在数据扫描上。PushRowNum/PullRowNum算子实际处理的行数。这是验证Plan中cardinality预估是否准确的黄金标准如果Plan预估扫描100万行但Profile里PushRowNum显示1亿行那就能立刻断定优化器的统计信息过时了导致生成了一个糟糕的计划。你需要立刻去更新表统计信息ANALYZE TABLE your_table;。ExchangeTime数据网络传输耗时。如果在EXCHANGE节点上这个值特别高印证了我们在Plan阶段对网络开销的担忧。可能需要考虑调整Join策略或者检查数据分布Distribution是否合理。PeakMemoryUsage峰值内存使用量。如果这个值接近或超过BE节点的内存限制可能会导致查询因内存不足OOM而失败或者触发落盘Spill to Disk后者会带来巨大的磁盘IO开销使查询变慢数个数量级。我们来模拟分析一个Profile片段。假设一个聚合查询很慢ANALYZE PROFILE显示- Fragment 1: - AGGREGATE (merge finalize): OperatorTotalTime: 2.5s - EXCHANGE: OperatorTotalTime: 15.8s, ExchangeTime: 15.5s - AGGREGATE (update serialize): OperatorTotalTime: 1.2s, PushRowNum: 50,000,000 - OlapScanNode: OperatorTotalTime: 3.1s, PushRowNum: 500,000,000, preaggregation: OFF解读最耗时的环节是EXCHANGE节点占了近16秒其中15.5秒是纯网络传输时间。这说明有大量数据在网络中穿梭。为什么有这么多数据要传输看上游OlapScanNode扫描了5亿行但preaggregation是OFF所以它把5亿行原始数据全吐给了聚合算子。幸运的是第一层聚合update serialize将数据从5亿行聚合到了5千万行减少了90%。但5千万行数据通过网络传输EXCHANGE仍然代价巨大。最终在第二层聚合merge finalize只需要处理5千万行耗时很短。结论一目了然瓶颈在于扫描节点未能启用预聚合导致海量原始数据被加载和传输。优化方向就是为什么预聚合没开启如何让它开启这样我们就从Profile的现象回溯到了Plan中预判的问题点完成了验证。4. 实战调优工作流从诊断到开方经过前两轮的分析我们已经形成了“Plan分析 - Profile验证”的认知闭环。现在我把这套流程总结成一个可重复使用的实战调优工作流并附上常见的“药方”。4.1 调优四步法第一步捕获与初步诊断用EXPLAIN获取慢查询的Plan。重点检查preaggregation是否ONcardinality预估是否合理是否存在可能产生大量数据EXCHANGE的环节启用Profile执行查询或对已完成的查询使用历史Profile。第二步Profile深度验证使用ANALYZE PROFILE查看树形结构。锁定OperatorTotalTime最高的一个或几个算子。核对PushRowNum与Plan中的cardinality判断统计信息是否准确。查看瓶颈算子的上游理解为什么会产生这么多数据。第三步针对性优化根据定位到的问题采取相应措施。下面是一些典型场景场景Apreaggregation: OFF检查物化视图查询的聚合列和分组列是否在某个物化视图中用DESC table_name ALL;查看所有物化视图。如果没有考虑创建。检查查询写法是否对聚合列使用了函数如sum(cast(column as bigint))导致无法命中尝试改写。检查数据更新如果是基表刚发生大批量更新/导入物化视图可能未刷新。手动刷新或检查刷新策略。场景Bcardinality预估严重失准更新统计信息立即对相关表执行ANALYZE TABLE table_name WITH SAMPLE;。对于大表可以先采样分析。检查Join顺序优化器可能因为基数估计错误而选择了糟糕的Join顺序。可以使用/* leading(t1 t2 t3) */这种Hint来手动指定Join顺序。场景CEXCHANGE节点耗时巨大优化Join策略如果是大小表Join且未走Broadcast可以尝试使用Hint强制广播/* broadcast_join(small_table) */。优化数据分布对于频繁需要Shuffle Join的大表检查它们的分布键DISTRIBUTED BY是否合理能否改为相同分布方式以实现本地JoinColocate Join。增加聚合下推在Scan之后尽早进行聚合减少传输量。检查是否可以通过创建更合适的物化视图来实现。场景D单节点聚合或排序内存不足PeakMemoryUsage高增加并行度如果AGGREGATE或SORT算子耗时集中在merge finalize阶段可以尝试调大并行度让工作分摊到更多节点SET parallel_fragment_exec_instance_num 8;需在Session中设置。启用Spill对于明知会超内存的查询提前设置允许落盘避免OOM失败SET spill_mode auto;。第四步验证优化效果应用优化措施后重复第一步和第二步。对比优化前后的Plan和Profile确认瓶颈点的耗时是否显著下降数据流是否更合理。4.2 一个完整的案例慢聚合查询优化假设有一个销售明细表sales我们经常按product_id和date汇总销售额。原始查询SELECT product_id, date, SUM(amount) FROM sales WHERE date 2023-01-01 GROUP BY product_id, date;1. 分析PlanEXPLAIN显示OlapScanNode的preaggregation: OFF,cardinality预估1亿行。2. 分析ProfileANALYZE PROFILE显示OlapScanNode实际输出10亿行EXCHANGE传输了10亿行数据耗时最长。3. 优化检查发现没有合适的物化视图。于是创建一个CREATE MATERIALIZED VIEW sales_mv AS SELECT product_id, date, SUM(amount) FROM sales GROUP BY product_id, date;4. 验证创建完成后再次执行查询。新的Plan显示preaggregation: ON并且rollup: sales_mv。新的Profile显示OlapScanNode直接输出聚合后的结果可能只有几百万行EXCHANGE传输数据量锐减总查询时间从分钟级降到秒级。这套“望闻问切”的流程就是StarRocks查询性能调优的核心。它不需要你盲目猜测而是基于坚实的运行时数据进行分析。刚开始可能会觉得有点复杂但只要你亲手跟着做几次把Plan和Profile对照着看很快就会形成直觉。记住调优的本质就是减少不必要的数据移动和计算让数据尽可能在离存储最近的地方、以最精简的形式被处理。而Query Plan和Profile就是你达成这个目标最得力的左膀右臂。