只是换了个条件的位置,执行计划就大变了,这个是bug吗?

【 TiDB 使用环境】生产环境
【 TiDB 版本】v7.1.3
【复现路径】
【遇到的问题:问题现象及影响】

只是更换了两个条件的位置,其他内容完全一样,执行计划就大不一样了,有点颠覆我的认知了

【附件:截图/日志/监控】

1 个赞

主要是你的条件里面是子查询,相当于要和别的表进行关联吧,类似你select * from a join b join c和select * from a join c join b了,你实际执行下analyze explain看下一样不,哪个更快?

带上analyze,这样的才是真实的执行计划

真实的执行计划和预估执行完全相同,前者妙出,后者需要5-10s
explain analyze 执行计划已更新,间上图

能加上表别名么?哪个字段是哪个表的,分不出来。

已更新别名

:joy:放在后面的时候没有走索引了。使用hint写法,强制走索引试试

a表的主键为REC_ID, 强制使用主键索引都不行,还是全表扫描
select /*+ USE_INDEX(a, PRIMARY) */ a.f1_10110 …

:thinking:搞不好还真是个bug,等别人看看吧。不过我们一般都是把 等号 in exists这种放在前面,不等于 not in not exists 这种放后面,默认认为条件越靠前的越先筛选。

确实好奇怪,,试试hint提示,能不能将执行计划调整一致。另外,每个子查询都单独执行以下,看看执行计划的统计信息有没有区别

涉及的表analyze分析下再看看呢

涉及的3张表全部手动analyze了,问题依旧

问了下优化器相关老师:
semi join 现在还不支持 reorder,之后在完善 outer join reorder 的同时会同时处理 semi join 了。
相关问题就会消失。

1 个赞

:thinking:这么看还是应该规范写法,优先将能走索引的条件放在前面

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。