看起来是有点奇怪，稍等我们看下。

不行的原因应该是这个问题，需要 7.5.7 修复。。。等着吧。。。

好吧，那就发下新版本用 hint 干扰走 index range scan 后的 explain Analyze 看看。 看看能不能对比出来为啥新版本走索引为啥也慢。

https://docs.pingcap.com/zh/tidb/stable/system-variables/#tidb_opt_ordering_index_selectivity_threshold-从-v700-版本开始引入 可以试试调大这个的效果。

https://docs.pingcap.com/zh/tidb/stable/system-variables/#tidb_enable_historical_stats 看看这个是关闭的么，不是的话 关了试试。

发个 explain Analyze 和上面对比下。可能是 命中率或者一些算子并发新版本调整了。

看老版本 index scan 6 千万，估计新版本优化器判断回表代价高然后走的全表扫。 你试试新版本价格 hint 走索引的效率。

版本太低了 升级吧。

手动 Analyze 就是注意下如果是分区表的话，可以考虑做分区的 Analyze，不然大表 Analyze 成本还是比较高的。

服务器该换了。tidb 版本也升级下，新版本有 sst 文件损坏自我修复。 https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file/#background-error-recovery-window-从-v610-版本开始引入

block checksum mismatch: expected 3877266098, got 393113608 in /tidb1/tikv-20171/data/db/24011866.sst offset 3600964 size 10457 这个意思是指 rocksdb 检测内存中的 checksum 和本地文件 sst checksum 对不上。认为文件损坏了(或者说数据异常)。 修复方法你试试缩容这个节点然后扩容 tikv 节点来解决。 我遇到过一次类似情况是系统内存刷盘 内核 bug。。。。

这个不是第一次 panic 的地方，发下第一个异常的地方，或者提供下完整日志。

1、升级到 8.5.1 版本试试 2、可以看下是否有长 sql，information_schema.cluster_processlist 这个表做下 time 等过滤排序即可 3、可以看下 tidb runtime 监控，里面有 go gc 相关监控，如果认为是 go gc 不及时可以确定下。 4、go gc 相关可以考虑调整下：https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage/#其它 还有尝试关闭：https://docs.pingcap.com/zh/tidb/stable/system-variabl…

1、看下 gc 是否有异常 2、每个 tikv region 数量有没有很多。

那就观察一段时间吧。

结合以上回答，感觉可以考虑调整为 128MB https://docs.pingcap.com/zh/tidb/stable/tune-region-performance/#:~:text=使用%20region-split-size%20调整Region%20大小&text=Region%20大小的推荐范围,性能抖动。 取一个更安全范围。 调大注意这个即可：https://github.com/tikv/tikv/issues/17382 这个影响看起来还好。

不太行。。。除非你改 tiup 代码。。风险太大了。 不过 service 文件改下名我理解风险不算很大吧？ 或者 cp 一个新的？

补充下，6.5 一下用 binlog，用 cdc 至少 6.5 以上的版本。

https://github.com/tikv/tikv/pull/18379 这个是相关 PR 修复版本： [image]