万兆网络， 缓存都开的

那就不对了，auto_analyze我是定时任务，半夜才跑 这个sql是全天都有

[image] 这个在升级的时候发现bug，已经关了。 auto_nalayze 和ddl 有关系？

[image] 都是251内存的机器，30%-40%的使用率

这是个内存表，走不了索引也走不了tiflash，一直这么跑着消耗集群资源 [image]

ddl都是半夜执行 [image] 现在仍然很多， 这应该是后台sql没优化好 [image]

有别的慢查询，但不多。 慢查询页面首屏大部分都是这个 集群没什么压力 [image]

开源 我能想到得就这些， 好像dors商业版支持tidb。

我能想到得 就是 你再做一个tidb（压力不大，直接换成mysql） 存储所有边缘得tidb数据 是不是aws啊，用s3挂载备份恢复也快

全量离线导入不就行了，记录个时间戳，cdc再接

另外，上千张表 不是都要跑AP吧，你可以简单得跑tiflash, 复杂得 再入doris，这样同步得表就少了。 还有第四点，等tidb9, tidb9会发布新的ticdc，可以二次开发自定义下游

1/ 现在flinkcdc和 SeaTunnel 对tidb得支持仅限于v6版本,我看flink2.1 支持jdbc了，你可以测试下 2.1 改代码双写 2.2 ticdc --kafka — doris （没有revolution） 2.3 ticdc – kafka —flink – paimon --doris catalog （支持revolution） 3/ 自己实现flink cdc connector

[image] 从7.5开始已经不支持binlog了

好的，反正通过tikv 慢慢删完数据了。 等到8.5.4 升级的时候重启下

描述写了，通过SET tiflash REPLICA 0，SET tiflash REPLICA 2，重新添加tiflash副本，仍然报错 这个表 在set期间 没有表结构的变更 表结构也没有96字段 Columns (95) Create Table CREATE TABLE `leader_relate_link` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '物理ID', `tenant_id` int NOT NULL COMMENT ' 团长id', `person_user_id` int …

解决了。 1 SHOW STATS_HISTOGRAMS WHERE Update_time < ‘2025-11-01 00:00:00’; 将升级8.5 时间之前的表查出来，重新analyze 一遍 2 mysql.stats_histograms的数据清理掉

使用全局索引

8.5 内存设置还有别的参数？ 7.5的集群 内存能用到50多G, [image] 8.5 到40G就上不去了 [image]