新版本
执行计划:
1 #NSET2: [1, 1, 162]
2 #PRJT2: [1, 1, 162]; exp_num(2), is_atom(FALSE)
3 #SAGR2: [1, 1, 162]; grp_num(1), sfun_num(1), opt_num(0), distinct_flag[1]; slave_empty(0) keys(TWCR.c_SECTION_ID), dist_arg_opt[0]
4 #SORT3: [1, 1, 162]; key_num(1), partition_key_num(0), is_distinct(FALSE), is_adaptive(0), MEM_USED(0KB), DISK_USED(0KB)
5 #SLCT2: [1, 1, 162]; (TWCR.c_DB_STATUS = 0 AND TWCR.c_SECTION_ID = '24CE8BB1-A066-4FBF-A0AA-23A5F170B43B' AND TWCR.c_WORK_DATE = var1 AND exp11 = 1)
6 #CSCN2: [1, 227, 162]; INDEX33555471(t_uav_work_record20260526); btr_scan(1)
以上情况该怎么解决:用户业务大多都是同一类型的sql,目前查出来新版本执行出来的值都不对,无论是新部署的dm8.4还是升级后的dm8.4
方便时可以测试一下下面这个查询,看看结果是什么
SELECT "c_SECTION_ID",COUNT(DISTINCT "c_CAR_ID")
FROM "t_uav_work_record20260526"
WHERE "c_WORK_DATE" = '2026-05-26'
AND "c_DB_STATUS" = 0
AND ifNULL("c_RECORD_TYPE",1) = 1
AND "c_SECTION_ID" = '24CE8BB1-A066-4FBF-A0AA-23A5F170B43B'
GROUP BY "c_SECTION_ID"
对比新旧执行计划,能看出新执行计划中把原查询内层的聚合过程给优化掉了,我猜测是转换成了类似于上面查询的形式。
你原查询内层分组中字段可能会存在相同SECTIONID,不同 AREAID 存在相同CARID的可能,内层分组后这种重复CARID不会被DISTINCT掉,而上面我写的这个只有SECTIONID分组,通过DISTINCT去掉这种重复数据,可能结果值就变小了。
不过这只是一个猜测,是否符合现场情况需要实际测试才行。

去对比查下group_opt_flag参数 两个版本分别是几