使用时间函数分区裁剪失效

💬 StarRocks 用户问答 性能相关
#1

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】查询SQL分区裁剪失效
【背景】目前发现在使用时间函数，或者一些特定写法时，分区裁剪会失效
【业务影响】查询数据量从单分区膨胀成全分区
【是否存算分离】
【StarRocks版本】2.5.20
【集群规模】例如：3fe +5be（独立部署）
【机器信息】Be配置16C,64GB

explain
SELECT * FROM ods.ods_hd_h2_t_sale_d_dip
WHERE dt = date_format((add_months (‘2024-06-28’, -12)),’%Y-%m-%d %H:%m:%s’)

 PREAGGREGATION: ON
 PREDICATES: CAST(86: dt AS DATETIME) = CAST(date_format(add_months('2024-06-28 00:00:00', -12), '%Y-%m-%d %H:%m:%s') AS DATETIME)
 partitions=907/913

explain
SELECT * FROM ods.ods_hd_h2_t_sale_d_dip
WHERE dt = date_trunc(‘day’,‘2023-12-02’)

 PREAGGREGATION: ON
 PREDICATES: 86: dt = '2023-12-02'
 partitions=1/913

explain
SELECT * FROM ods.ods_hd_h2_t_sale_d_dip
WHERE dt = date_trunc(‘day’,date_format((add_months (‘2024-06-28’, -12)),’%Y-%m-%d %H:%m:%s’))

 PREAGGREGATION: ON
 PREDICATES: CAST(86: dt AS DATETIME) = date_trunc('day', CAST(date_format(add_months('2024-06-28 00:00:00', -12), '%Y-%m-%d %H:%m:%s') AS DATETIME))
 partitions=907/913
#2

ods.ods_hd_h2_t_sale_d_dip是什么表？

#3

明细分区表，分区是date类型，目前发现明细分区表，都会裁剪失效，和单张表本身无关

这是可以可以参考的建表语句
CREATE TABLE ods_hd_h2_t_sale_d_dip (
saleno varchar(65535) NULL COMMENT “销售单号”,
rowno decimal(20, 0) NULL COMMENT “行号”,
busno decimal(10, 0) NULL COMMENT “业务机构编号”,
accdate varchar(65535) NULL COMMENT “会计日”,
dt date NULL COMMENT “分区键”
) ENGINE=OLAP
DUPLICATE KEY(saleno, rowno)
COMMENT “XX”
PARTITION BY RANGE(dt)
PARTITION p20220103 VALUES [(“2022-01-03”), (“2022-01-04”)),
PARTITION p20220104 VALUES [(“2022-01-04”), (“2022-01-05”)),
DISTRIBUTED BY HASH(saleno, rowno) BUCKETS 6
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”,
“enable_persistent_index” = “false”,
“compression” = “LZ4”
);

#4

把后面函数换算成 %Y-%m-%d的格式试试

#5

date_trunc(‘day’,date_format((add_months (‘2024-06-28’, -12)),’%Y-%m-%d’))

PREDICATES: CAST(86: dt AS DATETIME) = date_trunc(‘day’, CAST(date_format(add_months(‘2024-06-28 00:00:00’, -12), ‘%Y-%m-%d’) AS DATETIME))
partitions=910/916

还是不行，但是测试发现v3.1.13，explain显示，两种写法都支持

#6

请问下，跟上面的sql类似，有几种写法，看执行计划，感觉也是没有走分区裁剪的，能不能帮确认下。tableA的分区字段是source_day,tableA有500个日期的分区
写法一：select t1.* from tableA t1 where source_day in(select distinct str_to_date(substr(source,1,8),’%Y-%m-%d’) as source_day from tableB)
执行计划显示，partitions:172/500，实际子查询的结果应该是只有几天的日期
写法二：create table tableC as select distinct str_to_date(substr(source,1,8),’%Y-%m-%d’) as source_day from tableB;
select t1.* from tableA t1 join tableC t2 on t1.source_day=t2.source_day;
执行计划也一样显示，partitions:172/500
写法三：select count(*) from tableA
执行计划显示，查询的分区数也是172/500
这三种场景下，分区裁剪是否真的生效了

#7

我这边自己测试下来，子查询应该也是不生效的，具体你可以看戏profile，你的写法三也是172/500的话，那我理解就是全表了，估计就172个分区有数据？总共500个分区？

#8

172/500是没有触发分区裁剪，命中了全表，该表只有172个分区有数据。

#9

总的分区数是500，应该不是172个分区有数据，只是执行计划自己预估的，实际的子查询中的结果命中的话，应该只有几个分区，这种sql不知道怎么能优化

#10

总的分区数是500，应该不是172个分区有数据，只是执行计划自己预估的，实际的子查询中的结果命中的话，应该只有几个分区，这种sql不知道怎么能优化，能指导下嘛

京ICP备2022026421号-1