@tidb小白 升级下 TiDB 内核版本到 v8.5.5 看一下先。

这个报错是 ssh 执行命令失败，需要看下两个：1. 单独 sh -x run.sh 是否可以执行成功，判断是不是 tidb sever 启动不了 2. tiup 中控机 ssh 登陆 tidb sever 目标节点然后执行，看看是否成功，判断中控机是否能通过 ssh 互信配置是否正确。

抓一个 clinic 看一下吧 使用 PingCAP Clinic 诊断集群

@rubynle 嗯，发一下 tidb 的监控看板吧，不行收集一个 clinic 整体看看，有可能是 grouting 的 gc 回收问题。最简单的验证方式就是扩容 tidb sever， dashboard 截图 tidb sever 的实例的 CPU 不是很均衡，tidb sever CPU 高是个别现象还是都有这个问题。

携手奔赴下一个十年！

这个是参数配置，启动 reload 就可以把/

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

这个版本 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