这种表设计，数据库能做的只是在传输时压缩下数据大小，效果如何只能试试看，这么宽的表估计资源额外开销都很大 https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#grpc-compression-type https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#grpc-compression-type

清空游览器缓存再试下 tiup cluster display 看一下 UI 在哪个 PD 重启试试，如果是 leader 先 transfer

Runaway 还没 GA，估计在 v8.1 GA，可以提个 github issue 或等 v8.1 GA 后试下

Tiflash – Task Scheduler – Active and Waiting Queries Count 看一下 task 是否均衡？

副本数都是 2 么？ SELECT * FROM information_schema.tiflash_replica;

虽然 GA 了，但 bug 太多不建议现在使用

和 mysql 一样的逻辑，需要先 select 后判断是 insert 还是 update，相比单纯 insert/update cpu 高是正常的

pd leader 切换触发阈值很短 https://docs.pingcap.com/zh/tidb/stable/pd-configuration-file#lease ，实际需要额外加上 leader 退出 & 新 leader 初始化 的时间，也可以试下新版本有没有优化

为啥要用 v2

执行计划不一样，低版本慎用

看 slow query 里

低版本 ngmonitor 有问题会不清理历史数据，建议升级下吧，具体的要搜下 github issue 看下，比如我知道的有一个 conprof consume too much disk space and gc doesn't release disk space. · Issue #120 · pingcap/ng-monitoring · GitHub

换成 csv 试试？

投稿邮箱亮了

支持。

以 v1.5.2 为例，代码逻辑为： 读取 secretName 对应 secret， tidb-operator/pkg/backup/util/util.go at master · pingcap/tidb-operator · GitHub 读取后添加进 env， tidb-operator/pkg/backup/backup/backup_manager.go at v1.5.2 · pingcap/tidb-operator · GitHub 最后统一设置到 pod env， tidb-operator/pkg/backup/backup/backup_manager.go a…

update 没专门 blog，大致是类似这一段描述 [image]