tiflash计算结果错误,tikv计算正确,原来是自动cast有关

sql:逻辑如下,已做脱敏处理,所以看起来怪怪的。
说明:
1)主表是t_order,t_order的id是order_id(未超高int的取值范围),类int unsign,其他三个表是通过order_id与该表关联,类型 int。4个表都在tiflash。
2)尝试过重建tiflash的所有表,一样被转换为decial导致结果错误
3)尝试过把 t_order_exxt_old.order_id从int改为bigint,一样被转换为decial导致结果错误

select
COUNT(DISTINCT a.order_id)
from
t_ocwprice a # order_id int
inner join t_log b on a.order_id=b.order_id # order_id 类型 int
inner join t_order c on a.order_id=c.id # c.id 类型 int unsigned
inner join t_order_exxt_old d on c.id=d.order_id # 执行计划发现:cast(t_order_exxt_old.order_id, decimal(20,0))->Column#224,结果错误,比实际少很多。
#inner join t_order_exxt_old d on c.id=cast( d.order_id as UNSIGNED ) # d.order_id 类型 int ,手工做cast 为 unsigned,计算结果正确。所以我推断是tilash类型转换错误导致计算结果错误。这里没看出为什么需要转换未decimal类型??
where b.ctime>UNIX_TIMESTAMP(20240301)
and (b.bmonth=0 or b.bmonth=202403)
and c.btime>=UNIX_TIMESTAMP(20240301);

—这个bug与表设计不严谨有关,不过没找到相关资料,所以这个bug 官方有发现了么, 有修复希望?

测试发现,这个bug触发,a,b,然后c,最后d表是最后处理的才会触发decimal的类型转换 (见下截图,脱敏需要,不后面的info内容,info看到的转换:cast(t_order_exxt_old.order_id, decimal (20,0))->Column#224),如果d表数据比较小,执行计划先做ab,然后d,最后c处理,不会发生类型转换,结果正确。

类int unsign

所有表都能改成一样的类型不

逻辑上是可以的。不过表大,t_order_exxt_old的主键是order_id,tidb不支持改主键int为unsigned ,改这个需要停服务。

我在内网帮你问问

让他简化一下给个一两行跑错的 case