为了更快的定位您的问题，请提供以下信息，谢谢
【详述】2.5.7版本两张同样的表，一张是分区表，另外一张是非分区表，同样的查询语句，分区表报内存超过资源组限制，并且线上集群内存全部占满，非分区表内存毫无波动，详细的建表语句、查询sql、profile请查看附件内容。
【be配置】32核 128G 33台be
【StarRocks版本】例如：2.5.7
分区表的话tablet的数量较多可能占用的内存要多一些。可以基于以下建议调整试试看
建议：
1、如果分区表比如2023-08-01之后还没有数据的话，可以使用动态分区，不必预创建这么多分区；
2、分区表的查询时，可以把对应表的查询条件换成分区键pdate而非pt列，能够使用分区裁剪过滤掉较多的数据。否则相当于全扫所有分区。
你好，非分区表也是全表扫描就不会出现这个问题
均为全表扫的情况下，分区表的tablet数量是非分区表的几十上百倍，join的效率是要差于非分区表的，资源消耗也相对更多。分区表设计的目的就是通过分区裁剪过滤掉大多数不需要的数据，如果不能过滤的话，建议还是使用非分区表
请问下这个问题还能优化下吗，对于用户来讲这种分区和非分区的界定是很模糊的，有些场景下适合使用分区裁剪，但是我要全量分析的时候又不会使用分区裁剪，那总不能只满足其中一种场景吧
你建表的分区键是pdate，where条件里是pt，自然没法走分区裁剪的。
可以考虑的优化点：
1、把其中重复出现的SQL片段提出来，以with t_share as 的形式共用
2、关于dwd_gio_custom_event_1hour_orc_syn_2与dim_role_new_all_2（t1）表的join，试下t1 join [broadcast] dwd_gio_custom_event_1hour_orc_syn_2，通过hint的形式调整左右表顺序试试看
您好，我可以更改这个SQL让其走分区裁剪也可以优化SQL，但是我的问题还是一样的，我一个分区表即便不走分区裁剪，在我的理解范围内顶多是扫描数据的时间有差异而不是内存使用方面相差这么大
执行计划里表的join顺序变了，扫描时间差别不大，主要是那张大表变成了右表，走broadcast join的方式
