你可以尝试一下，我这边测试6.5是没有问题的

[image] 直接这样建就可以，但是要满足插入的数据格式严格满足要求 [image] 否则就会发现在对应分区找不到数据

如果确定是热点问题，可以通过 tidb中hot_region_history确定热点region，,table。或者热力图也行。 后续对表进行auto_random的打散

block cache修改之后可以观察下tikv detail的block cache size有没有下降。另外.3上的内存使用有到瓶颈吗 虽然看到.3上的组件是挺多的。其次你这张图片上面提示的info显示的什么信息

你目前排查到哪部了呢

可以参照这个帖子先看看

plan是指执行计划和tidb.log

先看tikv线程池中哪个线程池使用率高，大概率是unified read pool，如果是的话，去找TOPSQL，和扫key多的slowQuery。

这个版本的global kill都是默认开启的 可以把plan ，log上传上来 看看是哪个bug

这个issue：https://github.com/pingcap/tidb/issues/49285 触发条件 point_get/batch_point_get + 使用hint /+read_from_storage(tiflash)/ v6.5.7 fix

猫哥强👍🏻

tabledual应该是输出的有问题。如楼上猫哥说的 应该是v6版本小版本的bug

tiup deploy -p把密码加在这行，tiup也不会去验证的，只有换行后才会验证密码，产品设计上好像就是这样的

判断肯定有数据的依据是什么，每次传参是否是固定的了

看下plan后面的详情

这儿的cop，指的是tidb 下推到tikv执行的算子（例如table full scan，index scan）细分下的cop task。这些task 会发送 tikv unified read pool 中等待CPU调度执行。

SPM 满足你的需求：https://docs.pingcap.com/zh/tidb/stable/sql-plan-management/#执行计划绑定-sql-binding

最好是都能取heap看看 主要内存消耗在哪部分。tikv 的话主要是block cache看看是不是看设置的过大 单节点单机器部署的话一般设置为总内存45%。其次就是task 堆积 有大量running task会导致tikv memory陡增

配置文件里面好多中文字符双引号，是复制出来后有变动嘛