【 TiDB 使用环境】生产环境
【 TiDB 版本】
v6.5.3
【复现路径】做过哪些操作出现的问题
从5.4.3 升级到6.5.3
【遇到的问题：问题现象及影响】
机器负载正常，之前的SQL变慢，执行计划一样，但是rpc次数和rpc时间都变长了，整体时间从1秒多变成5秒多
老集群5.4.3：rpc_num: 7, rpc_time: 6.03s
新集群6.5.3：rpc_num: 303, rpc_time: 12.5s
rpc_num 增加很多，这个怎么优化？
SQL语句：
5.4.3的执行计划
6.5.3的执行计划
【资源配置】
【附件：截图/日志/监控】
两个集群的机器和配置发出来看一下，如果不同配置和集群情况，可能这类的差异会存在。
但是如果你希望优化之后变得更快 ，你可能需要提供更多的信息。
包括：【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
在 TiDB 中，rpc_num 是指执行 SQL 过程中涉及到的 RPC（Remote Procedure Call）调用次数。RPC 是用于不同节点之间进行通信和数据交换的机制。rpc_time 则表示 RPC 调用的总时间。
当 rpc_num 增加时，可能会导致性能下降，因为每个 RPC 调用都需要一定的时间开销。为了优化 rpc_num，您可以考虑以下几个方面：
tidb_distsql_scan_concurrency 参数来控制并发扫描的数量，从而减少 RPC 调用次数。您可以参考 TiDB 配置文档中的相关参数说明进行调整。EXPLAIN 命令来分析查询计划，查看是否存在潜在的性能问题，并进行相应的优化。服务器性能差异：
老集群相对好一些，12台服务器共728个cpu
新集群相对差一些，但是不多，12台服务器，共632个cpu
CPU 型号呢
6.5.3的机器有一半性能比较差，但是上面只运行了一个实例，其他机器都是运行两个实例，CPU没有达到瓶颈，没有业务的时候执行也是慢
这个参数改成64，试了一下没效果
不是看CPU瓶颈，像看看cpu本身的差异，我看另一个帖子里是5.4.3同步->6.5.3 ,然后你们业务切换到了这个6.5.3，是这个过程吧？ 原来没升级前有对比过SQL性能差异吗
是的，切换升级，对比过其他的，没对比这条SQL
现在就这一条SQL慢 还是所有的
现在这一条差距比较大， 其他的也有，6.5.3这个优化器好像有点问题，上午有一条SQL
也有问题，analyze 之后还是有问题，过了一段时候重新analyze 之后才好
现在除了这个还有一个SQL选择错误的索引，但是那个影响不大
cpupower frequency-info 这个操作系统命令结果看下
这个看不到结果，像看看是不是开启了CPU节能模式，前几天也有一个升级后整体变慢的，他是由于GC问题，不过他的执行计划里能明显看到key的数量差异，你这就比较小。可以参考下
系统同事看了一下CPU是高性能模式
5.4.3版本
scan_detail: {total_process_keys: 4558025, total_process_keys_size: 531379748, total_keys: 4558032
6.5.3版本
scan_detail: {total_process_keys: 4087169, total_process_keys_size: 717849981, total_keys: 4087429,
原集群多扫描了50W的key
我们主从的GC都是24小时
show table xxx regions 看下2个集群region数量差异有多少。
5.4.3 这个表的region：
23705
6.5.3 这个表的region：
25471
我的意思 对比你帖子里SQL这个表
就是这个表的，不是集群的
5.4这个只访问了7个region ,6.5的需要303个，建议可以对这个表做下compact,查出来region_id然后写脚本循环处理，会影响IO 时间也会比较长
tikv-ctl --host tikv_ip:20160 compact -r XXXX -c write -d kv --bottommost force --threads 4
tikv-ctl --host tikv_ip:20160 compact -r XXXX -c default-d kv --bottommost force --threads 4
