SR 3.3.4 主键和明细模型采用临时分区替换功能后，分区数据select结果不准确

U_魔咒 · 2024年11月13日 06:23

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】SR表达式分区主键表数据查询异常，表达式分区字等于某个值的时候数据查询丢失，需要带上函数或者其他的方式才能进行查询，如trim函数，注意：数据中本身是没用空格的
【业务影响】select数据查询
【是否存算分离】存算一体
【StarRocks版本】例如：3.3.4
【集群规模】例如：1fe+5be
【机器信息】CPU虚拟核/内存/网卡，例如：48C/64G/万兆
【联系方式】StarRocks社区群1 石基-魔咒
【附件】

sql_1 ： select length(trim(calendar_year)),length(calendar_year),(calendar_year = ‘90446282865034035261’) as flag,calendar_year from sdp_financial_calendar_error where calendar_year = ‘90446282865034035261’ limit 2; – 查询结果不对

sql_2: select length(trim(calendar_year)),length(calendar_year),(calendar_year = ‘90446282865034035261’) as flag, calendar_year from sdp_financial_calendar_error where calendar_year = trim(‘90446282865034035261’) limit 2; --结果准确

sql_3：select length(trim(calendar_year)),length(calendar_year),(calendar_year = ‘90446282865034035261’) as flag, calendar_year from sdp_financial_calendar_error where trim(calendar_year) = ‘90446282865034035261’ limit 2; --正常查询

查询并不报错只是数据不对。

查询表建表语句

U_魔咒 · 2024年11月6日 01:07

该表前面做过基于分区字段delete操作如delete from sdp_financial_calendar_error where calendar_year = ‘9044628286503403526’, 有点像删除数据合并的时候影响的分区和字段值的映射关系，直接单独查询分区也是正常查询，如 select * from sdp_financial_calendar_error partition(pName); 但是这种场景这两天一直没复现出来，但是针对之前那个错误表重建后还能一直复现，删除的数据没删除，还导致其他分区的数据直接=查询数据异常

U_魔咒 · 2024年11月5日 07:27

异常查询sql在web界面历史sql查询记录中都查不到，并且从 fe.audit.log找到sql的执行记录中的queryId，也找不到对应的profile信息，sql没有任何执行profile信息

Star_Cao · 2024年11月5日 12:19

哪个版本，发一下explain + sql的执行计划

U_魔咒 · 2024年11月6日 02:07

SR版本3.3.4，
这是错误sql_1的explain信息: explain_error.txt (658 字节) 这个执行计划几乎为空, 并且错误sql没有执行的profile信息

这是正确结果sql_3的explain信息: explain_correct.txt (3.1 KB) 这个执行计划正确

数据结果

Star_Cao · 2024年11月6日 02:32

复现过程，及对应的建表、数据等，通过文本发出来

U_魔咒 · 2024年11月6日 03:11

这个问题比较诡异，目前最开始发现的这个表，通过重新创建一个表再将数据写入替换表后，这个正式表第二天基本上又会出现同类型错误，这个表也没做其他的什么操作，并且表也被重新create了，怕是又要重新新建一张表，将数据写入再swap with表才行

有重新恢复sdp_financial_calendar表，估计明天又会异常

查询正常了

执行计划

Star_Cao · 2024年11月6日 03:33

新表数据怎么导入的？下次导入的时候，将查询出现异常的字段，通过trim的方式处理一下。看一下是否还会出现异常

Star_Cao · 2024年11月6日 03:36

在fe.audit.log中确认一下，除了select之外，这张表还做了哪些操作

U_魔咒 · 2024年11月6日 03:48

最近三天除了select之外，还有如下操作:
删除分区如： alter table sdp_financial_calendar drop partition if exists p551760251683065856610
数据insert如 : INSERT INTO default_catalog.pc00003.sdp_financial_calendar SELECT calendar_day,calendar_year,calendar_id,day_of_week,day_of_month,week_scope,month_scope,quarte_scope,year_scope,week_of_year,week_of_month,month_of_quarte,calendar_month,calendar_quarte,update_date,tenant_id FROM hive.pc00003_mongodbbackup.sdp_financial_calendar

U_魔咒 · 2024年11月6日 03:49

表的数据里面没有空格，直接在select里面使用查询结果和查询值直接等于返回为true，另外trim和不去除字段length也是一致的

Star_Cao · 2024年11月6日 12:43

建议写一个定时任务检测一下这个表每天什么时候会出现这种情况，然后根据时间点排查操作。什么报错都没有，也没有异常的操作，稳定复现你描述的情况。这个本身是一个不合理的情况。

U_魔咒 · 2024年11月11日 03:35

@Star_Cao 老师，问题已经复现了，五分钟一次进行sql查询定位到时间点为凌晨: 00:20:01 ~ 00:25:01之间发生的
检测SQL: select length(trim(calendar_year)) as trim_len,length(calendar_year) as len,(calendar_year = ‘224459254763868160610’) as flag,calendar_year,now() as t_time from pc00003.sdp_financial_calendar where calendar_year = ‘224459254763868160610’ limit 1;