学习了，原来CPU也是关键因素

异地最好也搭建容灾的集群使用ticdc同步吧

24小时就好了

表面看这是一个空指针解引用 故障，应该属于程序异常，估计代码中存在未处理的 nil 指针访问，可能是TiDB 自身的 bug 或内存状态异常

会不会是重启了owner角色的ticc.要切换角色，新的owner角色可能需要向tiKV请求变更日志，tikv变得异常繁忙

estRows和实际的执行返回的row相差大吗？一般执行计划不准确会导致估计行和实际返回行相差较远，统计信息的采样比是多少？

先确定统计信息是不是正确的，执行计划里面的估计行和实际行对比看看差异大不大？如果不大，就不是统计信息问题，比较棘手。要么改写语句，要么使用hits，但用hits也有风险的，理论上优化器选择的是最优的。

编辑看看显示的是什么指标

可以控制并行度看看

重启报错影响使用吗？只是报错，能正常启动对吧

为啥要调整内存使用率，如果没有性能问题，应该是正常现象吧。

PD所在的节点资源消耗情况如何？可能是网络延迟、资源耗费高导致

我也遇到了，80%左右就报了，我是扩容重启就恢复了

对的，我昨天也想到了，后面一直在同步8台机器，今天早上可以看到数据了

个人觉得最好移除tiflash，再加入。加入时会重新同步数据

数据库目前有多大，理论上，tidb内存应该尽量缓存数据库的数据，即是pagecache。如果数据库比较小，这个利用率也不会太高

延迟高说明语句执行时间变长了。可能情况较多，但就是语句变慢了，查看慢语句看看那个时段运行的语句有多少？有没有堵塞等等

用户定义函数和存储过程