背景本文基于Starrocks 3.3.5在之前的Starrocks 的 ShortCircuit短路径中我们谈到过基于点查的这种ShortCircuit短路径在优化器上不会经过复杂的优化更不会经过memo的CBO优化这一点也是为什么点查会快。而且在之前的文章中也没说看到有规则判断点查必须是要求行存实际中在Starrocks中列存和行列存储都是可以进行点查操作的每个引擎不一样当然效果也就不一样.结论任何一个SQL计算存储引擎有两个组件必然是有的一个是 调度模块另一个是 SQL优化模块一个SQL被优化优化了以后当然还有其他流程就会由调度模块进行task的调度这样才能进行实实在在的运行。而且这里的调度分两种一种是 Pipline调度一种是MPP调度(Fragment执行模式),对于Starrocks来说默认是前者也就是 Pipeline调度,而且调度的模式不一样任务并行度的设置也不一样当设置 set enable_pipeline_engine true(默认) 时影响并行度的参数是 pipeline_dop 当设置 set enable_pipeline_engine false 时影响并行度的参数是 parallel_fragment_exec_instance_num而对于点查来说直接跳过调度层级由于是查询几乎不会有其他的计算直接再BE获取数据即可。而如果是行存的话直接通过PK获取一行数据如果是列存的话通过PK因为一行数据是存储崽不通的列chunkColumn Chunk中所以会通过多轮的数据获取之后再组装成一行数据所以消耗的时间就多了。分析先说说数据流StmtExecutor.execute || \/ StatementPlanner.plan || \/ handleQueryStmt || \/ DefaultCoordinator.startScheduling这里的startScheduling方法就是fragemnt任务的调度Override public void startScheduling(boolean needDeploy) throws Exception { try (Timer timer Tracers.watchScope(Tracers.Module.SCHEDULER, Pending)) { QueryQueueManager.getInstance().maybeWait(connectContext, this); } if (isShortCircuit) { execShortCircuit(); return; } try (Timer timer Tracers.watchScope(Tracers.Module.SCHEDULER, Prepare)) { prepareExec(); } try (Timer timer Tracers.watchScope(Tracers.Module.SCHEDULER, Deploy)) { deliverExecFragments(needDeploy); } // Prevent explain scheduler from waiting until the profile timeout. if (!needDeploy) { queryProfile.finishAllInstances(Status.OK); } }可以看到 如果是短路径的话也就是点查直接进入到execShortCircuit方法从而调用ShortCircuitHybridExecutor.exec方法这里就直接向BE请求数据了反观如果不是短路径则还会经过prepareExecdeliverExecFragments两个阶段,这里包括DAG的构建(将逻辑执行计划转换为可部署的物理执行计划)fragment的具体Deploy具体哪个BE上分配哪些Task以及等待部署成功等等这些都是要需要时间的。所以说如果一个query过来的话不是点查但是SQL查询比较简单的话也许真正查询的时间少但是在调度Fragment的时间却比较多。