OB版本升级后,查询语句不会默认走索引,旧版本可以

【 使用环境 】生产环境
【 OB or 其他组件 】Oceanbase
【 使用版本 】4.2.1.6
【问题描述】使用select语句查询ob,同一条sql,表结构也相同,但是在3.1.1版本上可以默认走索引,4.2.1不行
【SQL语句】select * from tableA where a >= xx and a <= yy and b =! dd; , 其中a是主键也有自己的索引,b是主键
【复现路径】查询相关sql执行计划如下
【附件及日志】4.2.1版本执行计划如下


3.1.1版本同sql执行如下

sql实际查询行数55w

OceanBase 社区已接收您的帖子,正在跟进中。

看过前一个帖子,扩展信息那里打码太多了,比较难看出问题

您好,您需要先看表的条件的数据分布情况,最好表结构,where条件数据量都要贴出来或者看一下
然后需要做一个统计信息收集一下,很多情况就是统计信息不准导致的。

还需要考虑下:如果一个表 100W行数据,您一次性拿出来50W行数据,而且还是 * 拿出所有列的话,不走索引走全表扫描才是 正确的执行计划。
走索引反而不是正确的执行计划。

如果区间很小比如仅仅会出来 10条数据的话,走索引可能是最快的。
随着数据量的变化,执行计划一直在变化的

ob支持并行。如果是单表的话,表内并行应该很快。

嗯嗯 是的 不过我这边在4.2.1版本查询约1w条数据时候,执行计划预估150w,还是不会走索引

那就说明你的执行计划明显不准。收集下执行计划吧。上面的老师也提到了。

通过官方悬赏问答群跟进处理目前结果:
1.3.x执行计划显示走索引


2. 4.2.1执行计划显示表扫,选a索引的代价要比主键索引要高

同步信息:单条sql4.2.1的sql效能没有降低
3.手动绑定走索引的执行计划

判断出由于传入参数值的不透这个sql选a索引的代价要比主键索引要高。
结论:批量执行时候4.2.1的sql效能降低,大概逻辑就是初次给的条件查询在代价模型下估出来是走全表的计划好过走索引, 比如这个过滤条件刚好要回表很多行,这个是避免不了的,但对于整个作业不同的参数值这两个计划的性能差异就出来了。可以手动绑定outline修改执行计划统一修改为走索引的执行计划