之前好像就有碰到过类似的case，程序链接里面有单独设置不同的sql_MODE

留痕等个结论

数据量小直接insert 方便，大的话dumpling + lightning

TiDB 在迁移时不需要做分区表，分区键，底层key-value 自动划分region，这一点比起OB在迁移时要选好分区键要方便的多 同时TiDB扩缩容非常的灵活，可以选择扩容1个2个，N个 tidbserver ,tikv等。但是OB 生产环境扩容OBSERVER的话需要每个Zone都扩容一台。

你可以尝试一下，我这边测试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后面的详情