该报错表示单条 SQL 达到 tidb_mem_quota_query，不等于 TiDB 进程物理内存耗尽。useCursorFetch=true 配合正数 fetchSize 仍可能在 TiDB 端缓存结果；可优先测试 setFetchSize(Integer.MIN_VALUE)。v8.3.0 以上如使用 Cursor Fetch，可测试 tidb_enable_lazy_cursor_fetch=ON，但受执行计划和事务限制。建议楼主补充 TiDB/Connector-J 版本、完整 SQL、EXPLAIN、内存额度及并发数。不要直接全局调大配额，并发会叠加内存风险；算子落盘也会增加磁盘…

TiDB 已有强制指定 TiFlash、查询级内存限制和自动落盘能力，但目前不能通过一个 Hint 同时设置“单条 SQL 的 TiFlash 总内存上限”。因此这是一个合理的功能增强诉求，现有证据不足以定性为产品缺陷。 适用版本： READ_FROM_STORAGE(TIFLASH[表名]) 可在语句级指定 TiFlash。 TiFlash 从 v7.0.0 起支持部分执行算子落盘。 从 v7.4.0 起，可通过以下会话/全局变量控制单条查询在每个 TiFlash 节点上的内存和落盘阈值： SET SESSION tiflash_mem_quota_query_per_node = …

重点区分三种情况： store 中 93 节点的 leader_count 明显更高，同时 hot write 也集中在该节点：更像写热点或 Leader 分布问题。 operator show region 有大量任务，Grafana 同期存在 Snapshot 流量：更像 Region 搬迁产生的网络流量。 Leader/Region 数量基本均衡且没有调度任务：需要结合端口、TiDB/TiKV 混合部署情况及业务 SQL 流量继续定位。 建议再补充： store、operator show、hot write 的输出。 三台服务器的完整组件部署关系。 TiKV 日志中重复出现的…

ADD COLUMN 官方说明 v7.5.6 默认开启 Metadata Lock。DDL 长时间不结束，更应该先检查是否被旧事务阻塞。如果增加字段后还要给 2 亿行历史数据赋业务值，建议拆成两个步骤： 先执行原生 ADD COLUMN。 再由应用按主键范围小批量回填，控制每批事务大小和并发。 这时真正需要评估的是后续 DML 回填速度和 TiKV 写入压力，而不是用旁路工具替代 ADD COLUMN。

对比一下前后 2 套 TiDB 集群的资源配置差异，另外重点关注一下 PD 这里面的磁盘类型以及读写速度，先确认一下是不是因为 BR 恢复数据量太大，PD 节点的磁盘瓶颈导致的。可以先看看 PD 和 tikv 的日志对比一下？ PD 和 TiKV 日志都要看看？

感兴趣可以发送简历至邮箱： yingkh@ziroom.com

@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 精度是不是正常的