执行计划长啥样？ 什么版本啊？

这个版本 delete 释放空间速度比较慢，因为 compaction 就是异步执行的，alter table compact 功能 v6 版本以后才会有，建议开始先升级吧。v8 效果不错，亲测～

@TiDBer_GJS9zKkq 该提问的兄弟回复了，你说的我也同意。现在相片都非常大，都是 16MB 左右。能用和好用，也要看实际场景，解决什么问题吧。

[image] 存视频就算了，图片应该还好

Titan 引擎应该可以的

是要用 blob 存储吗？图像数据大概是什么样的？单张图片多大？ 字符串类型

@TiDBer_JRxiljos 是的，先确认一下 TiDB 精度是不是正常的

整体 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 有问题，或者参数配置对比一下看看是否有差异。