starrocks优化的核心方向
要做好starrocks优化,得先明白它的“脾气”，就像照顾一个挑食的小朋友，得知道它喜欢什么、讨厌什么，才能让它“吃嘛嘛香”，starrocks作为一款OLAP数据库，优化的核心方向主要有三个：**数据模型设计**、**查询语句编写**和**集群配置调优**，这三个方向就像三角形的三个顶点，少一个都站不稳。
数据模型设计是基础,就像盖房子的地基，如果地基没打好，后面再怎么装修都可能出问题，比如选对模型类型，Aggregate模型适合做统计分析，每次写入会自动聚合数据，查询时就不用再算一遍；Duplicate模型适合存原始数据，想怎么查就怎么查，灵活度高；Unique模型则适合有更新需求的场景，能保证数据唯一性，之前帮一个电商客户做优化，他们一开始用Duplicate模型存订单数据，查询月销量时要扫全表，慢得像蜗牛，后来改成Aggregate模型，按日期和商品ID聚合，查询速度直接快了10倍，客户当场就给我发了红包。
查询语句编写也很关键,好的SQL能让数据库少走很多弯路，就像玩迷宫，选对路线就能直达终点，选错了就只能绕来绕去，比如避免用SELECT *，只查需要的字段；合理用WHERE条件过滤数据，别让数据库做无用功；JOIN表时注意顺序，把小表放前面，大表放后面，减少中间结果集，有次我同事写了个查询，把5张表全JOIN在一起，还没用任何过滤条件，结果跑了20分钟都没出结果，后来我帮他加了个时间范围过滤，再调整了JOIN顺序，3分钟就出来了，他直呼“大神”。
集群配置调优是“锦上添花”，硬件资源和参数设置得合理，数据库才能发挥最大实力，比如内存分配，给查询节点多留点内存，别让它“饿肚子”；调整并行度，让多个查询能同时跑，就像多开几个窗口办事，效率高，之前公司服务器内存不够，查询老是OOM，后来把mem_limit参数从2G调到4G，同时把并行查询数从5降到3，一下子就稳定了，再也没出现过“罢工”情况。
影响starrocks性能的关键因素
想让starrocks跑得快,得知道哪些因素会“拖后腿”，就像开车，轮胎没气、发动机积碳都会影响速度，starrocks也一样，有几个关键因素会直接影响性能。
第一个是**数据量**，数据量太大，就像背着100斤石头跑步，肯定快不了，如果单表数据超过1亿行，查询时扫描全表会非常慢，有个客户存了5年的用户行为数据，足足5亿行，查询最近一天的数据都要5分钟，后来我们帮他按天分区，只查当天分区，速度立刻降到30秒，就像把大石头换成了小石子，轻松多了。
第二个是**数据分布**，数据分布不均匀，就像排队时大家都挤在一个窗口，其他窗口空着，效率低，比如分桶键选得不好，导致某个分桶数据量特别大，查询时这个分桶所在的节点就会压力山大，其他节点却闲着，之前遇到过一个案例，分桶键用了用户ID，结果某个网红用户的粉丝数据全集中在一个分桶，查询时这个节点CPU直接飙到100%，后来换成按地区分桶，数据一下子就均匀了，节点负载也平衡了。
第三个是**查询复杂度**，查询语句写得太复杂，就像绕迷宫，转来转去找不到出口，比如嵌套子查询太多、用了大量聚合函数、关联表过多等，都会让数据库“头疼”，我见过最夸张的一个查询，套了5层子查询，还在用SELECT *，跑了1个小时都没结果，后来我把它拆成3个步骤，先聚合中间结果，再关联查询，10分钟就搞定了。
第四个是**硬件资源**，CPU、内存、磁盘IO，哪个跟不上都会影响性能，就像电脑配置低，玩大型游戏肯定卡，之前有个客户用机械硬盘存数据，查询时磁盘IO老是100%，后来换成SSD，速度直接提升了5倍，就像从自行车换成了电动车，嗖嗖的。
第五个是**配置参数**，参数没调好，就像给运动员穿了不合脚的鞋，跑得再快也容易摔跤，比如parallel_fragment_exec_instance_num（并行执行实例数）设太高，会导致CPU资源争抢；mem_limit设太低，查询时容易内存溢出，有次帮客户调参，把parallel_fragment_exec_instance_num从8降到4，CPU使用率从90%降到60%，查询平均耗时也从20秒降到12秒，效果立竿见影。
starrocks优化的实战步骤
优化starrocks不能瞎试,得有章法，就像解数学题，一步一步来才能出答案，我之前帮一个做物流的客户优化过查询性能，从慢到快，就用了这几个步骤，效果特别好。
第一步,**问题定位**，得先知道哪里慢，不能上来就改，客户当时反馈“报表查询慢”，我先让他把慢查询语句发给我，再看了下starrocks的监控面板，发现查询耗时主要在“Scan”阶段，而且某个分区的数据量特别大，就像医生看病，先做检查，找到病因再说。
第二步,**分析原因**，找到了慢的地方，再分析为啥慢，我看了下那个慢查询，发现它查的是“近一年物流订单数据”，但表是按季度分区的，也就是说要扫4个大分区，每个分区都有几千万数据，而且SQL里用了“GROUP BY 省份, 城市”，但表上没建对应的物化视图，每次都要实时计算，这就像你要找一本书，结果书没分类，还得一本本翻，能不慢吗？
第三步,**制定方案**，知道了原因，就该想办法解决了，我当时定了三个方案：一是把分区粒度从季度改成月，减少每次扫描的数据量；二是针对“按省份、城市聚合”的查询，建一个物化视图，提前算好结果；三是优化SQL，把不需要的字段删掉，只查需要的列，就像给房间大扫除，先整理分类，再把没用的扔掉，最后摆整齐。
第四步,**实施优化**，方案定好了，就动手改，先改分区，把历史数据按月份重新分区，花了一下午时间；然后建物化视图，用CREATE MATERIALIZED VIEW语句，指定按省份、城市聚合，存月度数据；最后让客户把SQL里的SELECT *改成具体字段，改完之后，我让客户跑了下查询，从原来的5分钟降到了30秒，客户当场拍桌子：“就这？早知道这么简单我自己也能搞！”（他自己肯定搞不定，哈哈）。
第五步,**效果验证**，优化完不能不管了，得看看效果稳不稳定，我让客户观察了一周，每天跑几次查询，记录耗时，发现基本稳定在25-35秒之间，比之前快了10倍，还看了下集群负载，CPU和内存使用率都降了不少，再也没有出现过查询堆积的情况，就像考完试要检查答案，确保没问题才算过关。
starrocks与同类工具优化对比
现在OLAP工具挺多的,ClickHouse、Doris、Presto这些，和starrocks比，优化起来各有各的“套路”，了解它们的区别，才能更好地用starrocks。
先说说**ClickHouse**，ClickHouse就像个“短跑冠军”，单表查询速度超快，尤其是向量化执行做得好，但它的优化更侧重“硬优化”，比如用合适的引擎（MergeTree系列）、建合适的分区和排序键，对SQL的要求比较高，复杂查询容易“卡壳”，starrocks呢，更像个“全能选手”，优化点更全面，支持实时更新（Unique模型），复杂查询（多表JOIN、子查询）优化得更好，对新手更友好，比如我之前用ClickHouse查多表关联数据，SQL稍微复杂点就跑不出来，换成starrocks，稍微调下JOIN顺序，就顺利出结果了，感觉像从开手动挡换成了自动挡。
再看**Doris**，Doris和starrocks师出同门，优化思路比较像，但starrocks在细节上更“贴心”，比如数据导入，starrocks支持Broker Load、Stream Load等多种方式，导入速度快，还能自动处理数据倾斜；Doris虽然也支持，但配置起来更麻烦，优化查询时，starrocks的CBO（代价优化器）更智能，能自动选择最优执行计划，Doris有时需要手动hint，上次帮客户对比，同样的SQL，starrocks比Doris快了20%，客户直接把Doris换成了starrocks。
还有**Presto**，Presto是“多面手”，能连各种数据源，但它本身不存数据，优化更多依赖底层存储（比如Hive）和查询语句，starrocks是“自闭环”，数据存在自己的存储引擎里，优化能从存储到查询一条龙，比如优化数据分布，starrocks可以通过分桶键直接控制，Presto得依赖Hive的分桶，灵活性差很多，我之前用Presto查Hive数据，因为Hive分桶不均，查询慢得要死，换成starrocks自己存数据，分桶调好，速度直接翻倍。
starrocks的优化优势在于**平衡了性能和易用性**，不像ClickHouse那么“挑SQL”，也不像Presto那么依赖外部存储，自己就能把数据存好、查好，如果你是新手，想快速上手，又要兼顾复杂场景，选starrocks准没错。
starrocks优化常见误区
优化starrocks时,很多人容易踩坑，就像走路没看路，一不小心就崴脚，我总结了几个常见误区，大家避开这些“坑”，优化效果能事半功倍。
第一个误区：**索引建得越多越好**，有人觉得索引是“万能药”，不管什么字段都建索引，结果写入速度慢得像蜗牛，其实索引就像给书加目录，目录太多，书反而变厚，翻起来更麻烦，starrocks里，只有查询频繁的过滤字段才适合建索引，比如订单日期、用户ID；不常用的字段建索引，只会浪费存储空间，拖慢写入，之前有个客户给一张表建了10个索引，写入数据时，原本5分钟能写完，结果花了20分钟，后来删了7个没用的索引，写入速度立刻恢复了。
第二个误区：**分区粒度越小越好**，有人觉得分区越细，查询扫的数据越少，就把分区粒度设成“按小时”，结果表有几千个分区，元数据管理都成问题，查询时反而更慢，分区就像分抽屉，每个抽屉放太多东西不好找，抽屉太多找抽屉也麻烦，一般建议按天或按周分区，除非数据量特别大（比如每天上亿行），才考虑按小时分区，我之前帮一个客户把“按小时”分区改成“按天”，分区数量从几千个降到几百个，查询时元数据加载时间从10秒降到2秒。
第三个误区：**只优化查询不优化数据模型**，有人天天调SQL，却不管数据模型合不合理，就像给破车换轮胎，轮胎再好，车架不行也跑不快，比如用Duplicate模型存统计数据，每次查询都要聚合，不如直接用Aggregate模型，写入时就聚合好，我见过一个客户，用Duplicate模型存商品销量，查询月销量时要扫全表聚合，后来改成Aggregate模型，按商品ID和月份聚合，查询速度快了10倍，之前调SQL调了半个月都没这么明显效果。
第四个误区：**忽略数据倾斜**，数据倾斜就像跷跷板，一边重一边轻，肯定不平衡，有人分桶键选得不好，导致某个分桶数据量特别大，查询时这个分桶所在的节点CPU跑满，其他节点没事干，比如用“用户ID”做分桶键，结果某个大V用户的数据全集中在一个分桶，查询时就卡在这里，后来换成“地区+用户ID”做分桶键，数据一下子就均匀了，节点负载也平衡了。
第五个误区：**参数调得越激进越好**，有人觉得把并行度、内存这些参数调得越高越好，结果CPU、内存资源争抢，反而变慢，就像开快车，油门踩到底，容易翻车，比如把parallel_fragment_exec_instance_num（并行执行实例数）设成16，结果每个查询都占满CPU，多个查询同时跑就互相抢资源，平均耗时反而变长，后来调到8，CPU使用率稳定在70%左右，查询反而更快更稳定。
starrocks配置优化技巧
starrocks的配置参数就像汽车的仪表盘,调好了能让它跑得更稳更快，我整理了几个关键参数的优化技巧，都是实战中总结出来的，亲测有效。
第一个参数：**mem_limit**，这个参数控制单个查询能使用的最大内存，就像给每个查询发“粮票”，不能让一个查询把内存全吃完，默认是2G，如果查询数据量大、复杂度高，2G可能不够，容易OOM（内存溢出），我一般根据服务器内存调整，比如服务器有32G内存，分给starrocks 20G，那mem_limit可以设成4G，同时把并行查询数控制在5个以内，避免内存不够用，之前有个客户mem_limit设成1G，跑个大查询直接OOM，改成4G后就没事了。
第二个参数：**parallel_fragment_exec_instance_num**，这个参数控制每个查询的并行执行实例数，就像多少个人一起干活，人多了可能抢工具，人少了干得慢，默认是4，建议根据CPU核心数调整，比如16核CPU，设成8比较合适，既能充分利用CPU，又不会太拥挤，我之前把这个参数从4调到8，CPU使用率从50%升到70%，查询平均耗时从15秒降到10秒，效果很明显。
第三个参数：**exec_mem_limit**，这个参数是每个exec节点的内存限制，和mem_limit类似，但更细粒度，如果某个查询的某个exec节点内存用得特别多，可以调大这个参数，比如跑大表JOIN时，中间结果集大，exec_mem_limit设小了会报错，调大到2G就能解决，不过也别太大，避免浪费内存。
第四个参数：**disable_colocate_join**，默认是false，启用Colocate Join（同构JOIN），能加速同分布表的JOIN，如果两个表的分桶键和分桶数一样，用Colocate Join能减少数据 shuffle，速度更快，但如果分桶不一致，就会失效，反而可能变慢，这时可以把这个参数设为true，禁用Colocate Join，让优化器选其他JOIN方式，之前有两个表分桶键不一样，用Colocate Join跑了5分钟，禁用后用普通JOIN，3分钟就出来了。
第五个参数：**vectorized_execution_enabled**，默认是true，启用向量化执行，能大幅提升查询速度，向量化执行就像批量处理，一次处理一批数据，比一条一条处理快得多，千万别把这个参数设为false，除非有特殊情况，我见过有人误把它关了，查询速度直接慢了3倍，后来打开才恢复正常。
调参数时要注意,别一次改太多，改一个参数就测试一下效果，像给病人换药，一种一种试，才知道哪个有效，而且要根据实际业务场景调，比如查询以简单聚合为主，和以复杂JOIN为主，参数调法肯定不一样。
starrocks数据建模优化方法
数据模型就像给数据“搭骨架”，骨架搭得好，查询起来就轻松，starrocks有三种主要模型：Aggregate、Duplicate、Unique，每种模型有不同的优化方法，选对模型、建好模型，性能直接上一个台阶。
先说**Aggregate模型**，这种模型适合统计分析场景，比如存销量、点击量等，写入时会自动按主键聚合，查询时直接取聚合结果，不用再算，优化Aggregate模型，关键是选对**聚合键**和**指标列**，聚合键要选查询时分组的字段，日期、商品ID”；指标列选要统计的字段，销量、金额”，并选对聚合函数（SUM、COUNT、MAX等），之前帮一个零售客户建表，聚合键设为“日期、门店ID”，指标列设为“销售额（SUM）、订单数（COUNT）”，查询月销售额时，直接从模型里取数据，比查原始表快了20倍。
然后是**Duplicate模型**，这种模型适合存原始数据，比如日志、明细数据，不做聚合，查询时灵活度高，优化