看日志不是 Operator 内部触发的，从 k8s 层面着手查下吧，oom kill node 调度之类的

看下 operator 日志

历史包袱吧将就着用

如果对 mysql8.0 兼容有需求，就上 v7.5 https://docs.pingcap.com/zh/tidb/stable/system-variables#default_collation_for_utf8mb4-从-v740-版本开始引入

提个 issue 哇，提供复现步骤

主要看具体性能要求，业务能接受分区裁剪来优化最好

整理一下问题如果是 “tikv 已经部署，但是没有挂载 nfs 盘，怎么重新挂载？” ， 直接用 additionalVolumes&additionalVolumeMounts 挂载即可

对比 pd 有 leader ， tikv store 有 region leader tidb 有 gc owner 等，状态性不强

多次执行 analyze table partition 是否都这么慢，可以在 v7.5 试一下 这个问题对应的 issue ANALYZE TABLE execution time depending on number of partitions · Issue #35142 · pingcap/tidb · GitHub 可以看最后的 revise pr statistics: support merge global topn in concurrency by Yisaer · Pull Request #38358 · pingcap/tidb · GitHub 增加了 h…

如果 set tiflash replica 可以并行，那需要解决很多潜在问题，比如 set tiflash replica 的过程中触发 drop table 等

这种表设计，数据库能做的只是在传输时压缩下数据大小，效果如何只能试试看，这么宽的表估计资源额外开销都很大 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