登录到机器上,执行sudo dmesg -T,看下有没有对应内存之类的报错
那台机器的dmesg信息有么,先排除下内存,cpu和磁盘的问题
如果业务没什么明显变化可以重点关注两个情况
1.看dashboard慢sql,是否有执行计划不对的地方
2.看analyze的情况,调整下analyze的时间,如果cpu立马下来,就是analyze的问题
是要保持一致的,不然挂一台机器有可能损失两个副本了,你这个磁盘使用率百分比应该是很接近的吧,如果是这样的话其实没啥差
tikv打label了么,同一台机器的label是一致的话应该不会有太大差别
联合索引的话前面也要是等值,试下强制hint字段1的索引,能正常走么
期间的这些慢查询可以看下执行计划与正常快速时候的执行计划是否一致
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
你们机器是不是有管控,把你的公钥给刷没了,如果是这样的话,就拷贝一份公钥过去,或者你正常输用户密码也行,而且之前的用户是root,还是tidb
嗯呢,我看看后续能不能尽量用聚簇表吧,实际测试了聚簇和非聚簇,写入性能也有较大差距
做了ip透传么,原来pd的u节点和现在的节点是一致的不,如果不是的话切一下pd的u节点看看
这应该是pd故障了,pd的cluster id变了,正常可以用pd-recover来修复,但是你这个测试环境,直接重新弄一份吧
那看起来8是正常的了,我的下推就是关的,7.5.6暂时没有环境,后续我测试下吧
对,count(*)和count(1)是一样的,count(id)试了7.5.1和7.5.4都是回表