别的SQL也是这种情况吗，再201上执行会慢？
大部分的sql都这样，这个业务是从mysql刚割接到tidb的，大部分的查询都比mysql上要慢，这种应该怎么去排查和优化。
三节点混布的话，可以参考一下这里
https://docs.pingcap.com/zh/tidb/stable/three-nodes-hybrid-deployment
但是个人觉得，三节点混布是要做好资源隔离才行
现在相当于是2个问题：1、 同样SQL 201节点比其他的慢，感觉跟升级有点关系，如果重启不好使 试试缩容后再扩容回来 。2、 从mysql迁过来的SQL变慢，这个要看变慢的SQL具体执行计划是不是有问题，只能这样分析了 ，tidb存算分离架构相同SQL比mysql慢也算正常，具体还要从执行计划入手分析
好的，非常感谢悉心的指导 
混合部署就是按这个教程来的
1 个赞
3节点混部的话，建议pd和tikv部署在不同的磁盘，例如挂载两个/data1和/data2，分别部署，另外可以通过numa来进行cpu和内存的资源隔离，如果只有两个numa节点，建议tidb绑numa_node: “0”，tikv绑numa_node: “1”
另外这种环境中，3个tidb节点，有一个节点特别慢，可以通过grafana的tikv-details-cluster的leader监控看一下是不是leader都集中在其他两个tidb节点所在的主机
换个查询条件试试？因为0.08和0.03的绝对值差别其实不大，这个SQL查询数据量很小，可能你这个查询条件里的region基本是在其他两个节点上，少了一部分网络传输耗时
https://docs.pingcap.com/zh/tidb/v6.5/follower-read
或者按照这个教程，试下set tidb_replica_read='follower'，再看下是不是变成另外一个节点速度很慢
MySQL到TiDB的迁移，如果想按照最佳实践，其实主键大部分都应该做变化。因为MySQL上很多业务默认都会使用自增主键，这对TiDB并不友好，很容易出现读写热点的。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。