这个说明了啥？

看过，都是一些整表的查询，， 可能是我表太大了，其实也说不太通，我的条件字段是有索引的，手动查询数据都是挺快的，不知道为啥这个这么慢

这个minio是正在使用的每天 br备份不同的库表数据，同一个用户密码一样的endpoint

不用远程存储，即使是存到本地硬盘上，都有问题。 [tidb@b67 ~]$ ~/tidb-toolkit/dumpling -u root -p 'xxxxx!pE' -P 4000 -h 192.168.241.85 -T bsppr.xpost --where "update_time < '2023-03-10 00:00:00'" -o /opt/dumpling/before-2023-03-01/ Release version: v7.1.5 Git commit hash: caa60c0917a886933a525d25e17057faac5b4da2 Git bra…

[image] 他这个是说用错了endpoint用成了console地址，但我用的是没问题的，因为我这个endpoint现在用在了br备份上，正常使用挺长时间了没有问题的~ 其他：因为br没法满足备份匹配条件的表数据，所以才想用dumpling备份条件数据的

这是执行命令后 连接的tidb的日志报错 [2024/11/12 16:37:46.391 +08:00] [INFO] [set.go:309] ["load snapshot info schema"] [conn=8441874356203684681] [SnapshotTS=453876296284110872] [2024/11/12 16:37:46.396 +08:00] [INFO] [set.go:309] ["load snapshot info schema"] [conn=8441874356203684683] [SnapshotTS=45387629628411…

我想说我这命令没问题吧？ 我好像不备份到minio，备份到本地也卡着，导不出数据。 我这个表数据量很大80亿左右，dumpling不支持导这么大数据的表吗？

没错的，我这不是s3，我这是备份到minio的 endpoint是生产的地址，内网IP 加hosts的

网络是通的，都是内网通讯，内网没限制

是的。

[image] 请求频率是没啥变化的

response time 是哪个？

是的，这个字段也有索引，最后用这个字段分区删着 速度稳定了，但删除速度没有变快 不像用postid这样时间差距很大。

最终结论可能是：tiup/cluster没有升级到最新版本的问题。 官方文档在7.1.5升级中建议满足版本即可，但在7.5后就没再写了，应该是这些组件越新越好吧，向下兼容。

配置一样的tso是排除数据问题吗？ 没法配置成和测试一样的tso

那我这batch ddl 该怎么删合理呀

batch on postid limit 50000 delete from xpost where posttime < ‘2022-09-6 00:00:00’;

窗口函数删历史数据比这样高吗？ 我是看群里军军大佬说现在版本推荐用batch ddl删的