执行计划问题

[胡杨树旁]

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】

索引情况：baseCodeId 和version 均有单列索引，但是优化器选择的是version 的索引，/+ USE_INDEX(codedetail0_,idx_codedetail_basecodeid)/使用强制走索引之后发现：

用baseCodeId索引效果更好，这里不太清楚为啥会选择version的索引

[裤衩儿飞上天]

统计信息不准

[近墨者zyl]

查一下是不是用了SPM

[胡杨树旁]

在哪里看统计信息准不准？ 如果统计信息不准的话是不是收集一下统计信息就可以了

[胡杨树旁]

想问下，这个SPM 怎么查？

[裤衩儿飞上天]

estrows actrows ，你可以查下表的健康度。
做完表分析后看是执行计划是否会准确。
如果还不准确，就看看有没有绑定SPM

[胡杨树旁]

刚看了下，没有用到SPM

[Kongdom]

有没有可能是order by的原因？是按version做的排序

[胡杨树旁]

健康度74%,我应该先收集一下统计信息吧，我收集完毕看一下执行计划

[Jiawei (渔不是鱼)]

建个id+version+返回字段的联合索引是不是效果更好
前提如果返回字段很少 如果多的话前两个是不是会更好

[胡杨树旁]

选择version这个索引看着是有算子下推，只返回到tidb 一条数据，但是baseCodeId这个的索引，

为啥是先返回20条数据之后又做了limit 1

[胡杨树旁]

收集了统计信息，执行计划还是选择的version这个索引

[Kongdom]

应该是每个节点返回一条，然后在tidb排序取一条。

[胡杨树旁]

是可以创建联合索引，但是就是感觉很奇怪，为啥优化器会选择version的索引，明显baseCodeId的选择读更好呀

[Kongdom]

去掉order by version试试

[胡杨树旁]

去掉之后 走了(basecodeid) 索引

[胡杨树旁]

这个是啥意思呢？我没有太明白

这个地方为啥是返回一个20

[Kongdom]

因为是分布式的，所以从每个节点取回节点里的top1，然后在tidb里将每个节点返回的top1再做一次top1，取到最大的那一个。

[胡杨树旁]

那这个地方是不是可以这样理解，我每个tikv节点都取top1，一共是有20条数据，这里的
就是代表我tikv每个节点top1 加起来的总和

然后这20条数据返回到tidb_server 然后tidb_server再取top1

[Kongdom]

是的，不过应该是说region比较贴切一点。