【 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 执行计划已更新，间上图
能加上表别名么？哪个字段是哪个表的，分不出来。
已更新别名
放在后面的时候没有走索引了。使用hint写法，强制走索引试试
a表的主键为REC_ID, 强制使用主键索引都不行，还是全表扫描
select /*+ USE_INDEX(a, PRIMARY) */ a.f1_10110 …
搞不好还真是个bug，等别人看看吧。不过我们一般都是把 等号 in exists这种放在前面，不等于 not in not exists 这种放后面，默认认为条件越靠前的越先筛选。
确实好奇怪，，试试hint提示，能不能将执行计划调整一致。另外，每个子查询都单独执行以下，看看执行计划的统计信息有没有区别
涉及的表analyze分析下再看看呢
涉及的3张表全部手动analyze了，问题依旧
问了下优化器相关老师：
semi join 现在还不支持 reorder，之后在完善 outer join reorder 的同时会同时处理 semi join 了。
相关问题就会消失。
1 个赞
这么看还是应该规范写法，优先将能走索引的条件放在前面
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。