左边的tikv读写流量比右边高不少，感觉还是热点问题。 看下unified read pool的监控

用hint查tiflash的SQL也把执行计划打出来对比下

explain analyze 把执行计划打出来看看

1、看下store-5节点的磁盘读写延迟是否和其他节点相近，先排查磁盘没问题 2、iops明显高很多，有可能是其他服务在也在大量占用磁盘，用iotop查一下

1、密码不用写在-p后面，交互时再输入 2、deploy命令格式写错了，版本号漏了 tiup cluster deploy <cluster-name> <version> <topology.yaml> [flags]

看下这个有没有帮助：

pd-addr填一个pd地址就可以了

对，0是不限制 [image]

试试改 log.file. max-backups 和 log.file. max-days 这两个参数

dm组件里面就包含了dm-master和dm-worker

1、优化SQL减少内存占用 2、从业务角度对跑批任务做拆分

看下tikv节点状态，是不是有tikv挂了，提示有Region不可用

启动changefeed的命令发一下，可能是密码里有特殊字符需要做转码

日志文件名称带日期时分秒的都可以清理，这些是自动归档的日志。

DM的具体报错信息没看到，发一个完整的报错信息看看。 手动建表报错和tinyint没啥关系，是你default语法有问题，DM报错是和这个相关吗？

看下节点之间是不是有端口被防火墙限制住了

数据校验失败了，但是count又是对的，这种情况极有可能出现了索引和数据不一致。 用 admin check table xxx 查一下看看。

看起来是产生写入热点了，参考下这个处理方案： https://docs.pingcap.com/zh/tidb/dev/high-concurrency-best-practices