ps -eo state | sort | uniq -c 查看下，D 是否很多，如果多，应该是卡刷盘 如果 R 比较多，应该是在排队 tidb-server 监控，goroutine 看看多不多。

[image] 完整文本堆栈日志可以提供下么？

初步推测集群还是有问题，监控上能看到 down peer。

这个截图看起来是 cpu 不高，但是 load 很高？

看服务器挺长时间没重启了。要不要试试重启看看效果。

结合源码解读，AI 总结： 一、StatefulSet vs Deployment：TiDB 为什么用 StatefulSet？ 核心区别 特性 StatefulSet Deployment Pod 标识 固定序号 tidb-0, tidb-1, tidb-2 随机后缀 tidb-7f8b9c-xxxx 网络标识 稳定 DNS tidb-0.tidb-headless.ns.svc Pod 重建后 DNS 变化 存储卷 每个 Pod 绑定独立 PVC 所有 Pod 共享 PVC 模板 扩缩顺序 有序：0→1→2，缩容 2→1→0 并发，无序 滚动更新 按序号逆…

可能环境不一样，但是个人推荐升级试试。本身 711 版本比较老了，第三位拉高点没坏处。

711 版本啊。推荐升级！！！ * 7.1.6: 2024-11-21

模型是质谱，用的 loop 跑出来的。后续 loop 这个产品 tidb 官方会发布。内部在用的。

Raw kv 基本无技术支持 以下是 AI 分析： 社区问题分析 问题链接: TiDB 社区论坛 - 无 SQL 请求，API v1 + txn KV 是否需要部署 TiDB 进行 GC 提问者环境: TiDB v8.5.6，只使用 TiKV Go Client 的 Txn 请求，TiKV 配置为 API v1，无 SQL 请求。 问题 1：API v1 的 txn KV 是否必须采用 MVCC 存储？ 是的，必须采用 MVCC 存储。 API v1 和 API v2 在 txn 模式下都使用 MVCC 实现，这是 TiKV 事务机制的基础。两者的区别在于 raw 模式： …

checkpoint 高但是 resolved 不高，代表瓶颈大概率在 cdc 解析 tikv log 上。 可能得原因是 ddl、热点啥的。 你 clinic 收个延迟搞得时候的监控我看看：https://docs.pingcap.com/zh/tidb/stable/clinic-introduction/ 上传到中国区

发下对应时间，cdc lag 监控 [image] https://docs.pingcap.com/zh/tidb/stable/monitor-ticdc/ 先发下这里的看看。

会话控制 tidb_isolation_read_engines 配置，不用修改很多，修改连接串即可，例如：sessionVariables=wait_timeout=3600 这个写到 jdbc 数据库 url 里面即可。 然后需要走 tiflash 让开发代码里面写 hint 走 tiflash。

会，可能会导致查询 region 过多，task 比较多，对比 region 集中来说，扫的任务变多了，会慢一些。

用 tidb 自己的 AUTO_RANDOM https://docs.pingcap.com/zh/tidb/stable/auto-random/ 或者改造 Snowflake ID — 低位放时间戳 // 传统 Snowflake（高位时间戳 → 有序写入 → 热点） | 41-bit timestamp (高) | 10-bit worker | 12-bit seq | // 改造版（低位时间戳 → 随机散列分布 → 无热点） | 12-bit seq | 10-bit worker | 41-bit timestamp (低) | 只要够随机就行。

搜索了下，可能是服务器时钟回调。 重启集群试试。。。

完整报错有么？

最好能保证

tidb 默认就是按照 label 自动调度的。 你先提供下上面命令信息，是不是安装配置有问题。