tidb 升级吧，4.0 太老了。新版本确实有相关优化。 升级之后用 dumpling 备份出来吧

内部查了下，等等吧。估计是测试 pr 有点问题，延期了。 [image]

1、可以调大 region 大小 2、tikv duration 会上升，pd region 心跳压力回答 3、可以，可以调整到 128MB 或者 256MB 4、调整心跳 5、可以比较健康

pd 有一些 rules check、region 心跳等日常工作。 因此一般没有压力的时候 0.5vc-1.5vc 是正常的。 如果 region 数量非常多(上百万)，tidb-server 也很多(一些定期刷 region cache 等)，配置了比较复杂的 placment rules 或者开启了一些 scatter 特性，空闲时 cpu 会更多。都很正常。

set session tidb_enable_paging=off; 后即可，应该是新特性会导致 cop cache 命中很低。

explain Analyze 执行计划看看呢。

看起来是已知问题。新版本没问题感觉可以考虑升级了。

好吧，如果是无法在线改的原因，那么这个 Warning 其实应该优化下。

https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices/ 可以完整的看下这篇文章。

看这个结果 感觉是 leader 调度过多。limit 了。

tidb 到 tikv 的 20180 端口是通的么？

用新版本 sync diff 可以的话就用新版本 sync diff 吧。

上下游 tidb 搜索一下 types 1067 error code 看看有没有内容。 没有的话应该是 sync diff 本身的问题，可以试试用最新版本的 sync diff 跑跑看。报错上来看可能和 sql_mode 有关联，估计需要改下 sql_mode 配置。不过 sync diff 我没看到相关配置，可能要在 tidb 上 global 修改。

优化器没管这种实际可以当 count(1) 的 count(col) 的优化问题 现在也一样。。。

有时间试试 plan replayer 或者裸导统计信息到一个 8.5 上，加个 tiflash replica 看看会不会有同样的错。 可能是一个已经修复过的问题。

额 好像预期的。。。。要优化。。。

QPS 多少

看下分区的 region 分布。如果集中 1 个节点就试试 scatter。https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md

我理解当前是在 sync 同步阶段了。看起来是拉 binlog 拉不到了？上游 MySQL 日志流程多久的？