整体 CPU 平均负载是怎么看到的？发一下截图？

@seiang 看一下这个建议，我觉得可以升级到最新的小版本，修复 TiCDC bug 看看效果。

紧急修复：优先排查 TiDB 表结构（字段类型是否为 BIGINT）和 auto_random 起始值（是否超出 Long 范围），这是解决 “ID 过大” 的直接原因； 适配优化：配置 MyBatis-Plus 的 TiDB 方言，确保 ID 获取逻辑正常； 长期方案：若需 “顺序 ID + 易迁移”，推荐改用 MyBatis-Plus 的 ASSIGN_ID（雪花算法），彻底摆脱对 TiDB auto_random 的依赖，同时满足传统自增 ID 的使用习惯。

欢迎自测，TiDB 自测效果还不错，8c16g 资源下面对比相同 Cost 的 MongoDB、ES 以及 Milvus 等还是不错的，基于 HNSW 召回率 95% 以上。感兴趣可以下载 v8.5.3 自测或者 TiDB Cloud 申请 Free Tier 使用 Severless + AI 方案 https://www.pingcap.com/tidb/cloud/。另外最近发布了 TiDB-X 感兴趣可以调研参阅下：TiDB X: Introducing A New Foundation for Distributed SQL

你这个描述，让我感觉有问题，但是不知道问题出在哪里。如果 RG 没有生效，可能要看看具体的 Resource Control 的 Dashboard 面板。

你是在尝试解决这问题嘛？https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility

Slack @米波五兄弟 来这里看看有没有 TiKV 的社区专家可以帮助到你

你补充的真好 我就说没有遇见过类似问题，可以把这个标签增加一个 TiKV 或者 Raw TiKV 模式了。

@TiDBer_Z7S7Jqgo 按照这个官网的来吧，最好再测试环境练习测试一下，搞一个 sop 再生产变更。这个 PD Recover 风险比较高，要在测试环境做完一个 SOP。

可能要检查一下 存储完整性，看看是否之前出现服务器掉电或者存储异常，这个问题不是常规逻辑问题，可能是 mvcc 版本一致性问题，最好通过对应的 region 检查一下 table 的状态，可以通过 admin check table 检查 table 数据完整性等问题。

PD recover 肯定要做的，你这就一个 PD 服务，这个恢复需要依赖 TiKV 和 PD 的日志来重建 PD 集群，这次重建集群可以考虑把 PD 和 TiDB 放在一个云主机上面，PD 本身不会占用太多资源。

看了一下 tidb-65.log 日志，看起来下载 v8.5.3 版本滚动升级以后 key 的解析存在问题，确认一下 v8.5.3 和 v8.5.2 的 docker 的编译方式，是否存在差异，比如 v8.5.3 的编译的架构 x86/arm 有问题，或者参数配置对比一下看看是否有差异。

可以提供一下 tidb 重启以后得日志看一下，理论上不会存在集群启动了，但是用户相关账号权限丢失情况。除非数据盘已经被清理，重新挂载了。

那就是 服务器 异常掉电情况，如果只有 1 副本情况，理论上不会出现恢复故障。你看看磁盘情况怎么样？

服务器是怎么重启的？重启前后有没有差变化？ tiup display 看一下拓扑吧

统计信息 检查一下自动收集策略，是否在某个时间 dml 大量操作导致统计信息触发，导致执行计划问题。另外如果是有分区表，可以把统计信息提前导入然后锁住不收集。执行计划 如果确定是典型海量 update 业务场景的查询，total key 和 process key 命中率低，可以看看要不要开启 IME 配置，提高内存命中率。

参数配置问题，这个参数前后版本应该发生配置变化了，删掉重新配置看看

这个业务启动都有那些 SQL 执行看看比较低效？另外业务启动完以后，读写请求并发处理都正常嘛？

root 执行增加➕x 看看报错是啥